← Voltar aos projetos

// 001

SaaS de Apoio a Compras Públicas

Design Systems Information Architecture Acessibilidade Potencializado por IA GovTech · B2G

Um SaaS de apoio a compras públicas no Brasil, com quinze anos de mercado, rodava em telas de produção sem nenhum design system — uma modernização havia muito no roadmap, nunca construída. De forma independente, depois dos meus anos no domínio, construí o sistema que aquele roadmap apenas prometia e fiz com que governasse toda superfície — em todo o conjunto de features da fase interna.

Função Independente · designer único
Cronograma 2024 — 2026
Escopo DS + 15 features
Setor Compras Públicas

// Construído · autodirigido Biblioteca de design no Figma · pipeline de tokens · 30 ADRs · dossiê de Discovery público

// Divulgação Projeto de portfólio independente. O cliente e o produto não são nomeados. Construído a partir de informação pública e conhecimento do domínio, depois do meu tempo no setor. As telas detalhadas do redesign são mostradas sob solicitação; o método, o domínio e o dossiê de Discovery estão abertos abaixo.

Área Restrita Superfícies do redesign · mostradas sob solicitação
SaaS de Apoio a Compras Públicas
_VISÃO GERAL

O que estava quebrado

As telas de produção rodavam sem nenhum sistema compartilhado — cor sem semântica, densidade sem ar, uma grade de colunas desalinhadas, filtros disfarçados de abas. Cada tela com seu próprio conjunto de regras. Uma modernização ficou anos no roadmap e nunca foi construída.

O que fizemos

Reconstruir com design à frente e fundação primeiro — uma fundação de coleções de tokens e os componentes a que elas se ligam, com Refactoring-UI como lente embutida e cada decisão material registrada como um ADR. Depois, amplitude: o conjunto de features realocado em um application shell de verdade, os tokens exportados como um pipeline alimentando um site de documentação viva.

O que mudou

Aí ele passou a governar tudo. O design se manteve coerente em cada feature — prova de que era um sistema, não um conjunto de soluções pontuais — uma só disciplina alcançando toda superfície de uma vez.

Nenhum sistema a herdar — quinze anos de telas, cada uma com suas próprias regras. Então construí um.

O PLANO AS TELAS ✕

O plano · as telas · nunca construído

// Escala da plataforma Números públicos · mapeados por completo no Discovery
374M Base de preços de referência
4.500 Instituições atendidas
14.000 Usuários ativos
15+ Anos de mercado
// Contexto do operador 1366×768 · 8h/dia

O domínio das compras públicas, a cadeia de nove artefatos da fase interna, as três personas de operador, o método de precificação com quatro fontes e o achado sobre propagação de erro estão mapeados no dossiê de Discovery — publicado na íntegra. Este caso continua de onde ele para: no design system.

[ Abrir o dossiê de Discovery → ]

Domínio · personas · o método de quatro fontes · o achado sobre propagação de erro

_DESIGN SYSTEM // 01

Um token, toda superfície

O sistema que o roadmap só chegou a planejar, eu construí — e fiz com que governasse cada uma. Um token semântico resolve para um primitivo e se liga a um componente; a partir daí ele governa cada superfície que o usa — muda o token, toda superfície acompanha. Esta é a inversão de nunca construído, desenhada.

Um token · toda superfície · agora conectados

Um sistema que não governa é decoração. Então construí um que governa.

// 02

O sistema, imposto

Um design system são só palavras até suas regras sobreviverem ao contato com código, tempo e outras pessoas. Três mecanismos mantêm este honesto — um pipeline que se exporta sozinho, um método que registra cada bifurcação do caminho, e um antes-e-depois mensurável.

// A · Pipeline

Do canvas ao código, automaticamente

Um pipeline automatizado lê a exportação de variáveis do Figma, verifica paridade de contagem e colisões de slug, e grava o sistema em JSON, CSS e configuração Tailwind em uma única passagem. Zero tradução manual.

// B · Método

O loop que mantém o sistema honesto

30+ ADRs — Architecture Decision Records — registrados ao longo de dois anos. Cada bifurcação do caminho passou por este ciclo: nunca improvisada, nunca reaberta.

01 02 03 04 Conflito Uma bifurcação surge Trade-off ou impacto transversal Conselho Lentes diversas Workshop com N agentes + pesquisa ADR Decisão registrada Justificativa + alternativas + consequências Aplicar Construir de acordo Sem reabrir; observar e aprender Método 30 ADRs
// C · Prova

De nenhum sistema a um governado

Oito mudanças mensuráveis das telas legadas para o sistema que construí. O tachado é o legado; o verde-água é o que construí.

Métrica Telas legadas O sistema que construí Veredito
Tokens de cor apenas primitivos, sem camada semântica206 em 7 coleções · encadeados por aliasindexado
Hex fixo no código 25+ nas telas 0 · auditado eliminado
Componentes 12 parciais · cards ad-hoc 50 · padrão uniforme de doc-block catalogado
Biblioteca de patterns— 8 documentados · página 12 documentado
Modo escuro declarado, não validado visualmente WCAG AA em ambos os modos · auditoria de contraste automatizadavalidado
Densidade 1 padrão · sem alternância 3 níveis · compacto · normal · confortávelem níveis
Documentação viva — tokens/index.html · orientada a dados viva
Exportação de códigoCSS escrito à mão pipeline automatizado → JSON · CSS · Tailwindautomatizado

Comparação apenas em nível de sistema; as telas individuais de cada feature não são mostradas aqui.

// SISTEMA EM ESCALA [FIG.05.04] FAMÍLIA = CABEÇALHO uma faixa, um tom — o portador da identidade. LARANJA = MARCA identifica o carro-chefe. não executa ação. STATUS = TOKEN cada estado é puxado de uma tabelinha só. VERDE-ÁGUA = AÇÃO se age, é verde-água. sem exceções. [FIG.05.04.b] — MESMAS REGRAS · FAMÍLIAS DIFERENTES 15 FEATURES × 7 FAMÍLIAS · AS MESMAS 4 REGRAS · ZERO EXCEÇÕES
_A11Y & DENSIDADE // 03

Três pisos que seguram

O operador submete documentos de compliance em um notebook de uso governamental, geralmente depois que a fila fecha. O sistema precisa ser legível, defensável em auditoria e discreto sob pressão de tempo. Densidade que respeita a mão apressada, contraste verificado em cada par de tokens nos dois modos, e um layout dimensionado para a tela que o operador de fato tem.

// A · Densidade

Dimensionado para a mão apressada

Normal é o padrão. Compacto amplia o piso para power users; Confortável para operadores de primeira viagem e monitores 4K secundários. A linha de formulário base nunca fica abaixo do piso de legibilidade de 17 px, e o texto de apoio permanece de primeira classe em todo nível — nunca um tooltip.

28pxCompacto
36pxNormal · padrão
44pxConfortável

ADR-007 · Workflow Stepper aposentado em todo lugar; a etapa de aprovação vive fora da plataforma (SEI), então o produto nunca finge o contrário.

// B · Contraste

Acima do piso AA em todo par

Oito pares de token de primeiro plano/fundo, nos dois modos, roteirizados na mesma passagem de CI que grava o CSS. A linha AA 4,5:1 é o piso; o par mais claro a supera com folga.

// C · A tela do operador

1366 × 768, uso governamental

C-04. A navegação de módulos fica na topbar para preservar a largura total para conteúdo denso; a borda esquerda é reservada para a filter rail por feature. C-03. A avaliação de compliance é por linha, sob a IN SEGES/ME 65/2021 · Art. 6º — três fontes de preço independentes ou a linha bloqueia. Não existe um “corrigir todos os selecionados” legal.

O operador é o primeiro auditor — as mesmas três palavras.

VIEWPORT 1366 × 768 · notebook de uso governamental nav na topbar · largura total filter rail 3 fontes · por linha · IN 65/2021 · Art. 6º
Acesso Restrito
// 04

Por Dentro do Redesign

Oito superfícies ficam restritas. O sistema alcança todas elas — as telas detalhadas do redesign são mostradas sob solicitação. Quinze features redesenhadas em sete famílias de compras públicas; o sistema, o método, o ofício e o domínio estão abertos acima e no dossiê referenciado abaixo.

Conteúdo Classificado

O Carro-Chefe de Precificação e Cotação

Autorização: Apenas Entrevista
Conteúdo Classificado

O Piloto de Pesquisa de Preços

Autorização: Apenas Entrevista
Restrito

Os Ambientes de Autoria

Autorização: Apenas Entrevista
Restrito

O Cluster de Triagem de Fornecedores

Autorização: Apenas Entrevista
Conteúdo Classificado

As Superfícies de Mapeamento

Autorização: Apenas Entrevista
Acesso Negado

O Relatório de Preços com Validade Jurídica

Autorização: Apenas Entrevista
Restrito

O Módulo de Gestão de Contratos

Autorização: Apenas Entrevista
Conteúdo Classificado

As Superfícies Auxiliares

Autorização: Apenas Entrevista

15 features · 7 famílias de compras públicas · 206 tokens de design system · 50 componentes. O sistema, o método e o ofício estão acima; as features ficam restritas.

_REFLEXÃO // 05

Um design system é governança disfarçada de ornamento.

Os tokens, os componentes, o site de documentação — isso se lê como ofício. O que de fato são é regra, escrita numa forma que o próximo designer consegue reencenar. O sistema que construí governa toda superfície não porque era mais bonito que a alternativa, mas porque era aplicado mais cedo: no canvas com variáveis, no build com verificações de paridade, no ADR com decisões registradas.

O tribunal de contas federal fala três palavras: motivação · rastreabilidade · justificativa. A mesma disciplina que torna um preço de compra pública defensável perante o controle federal é a que torna uma tela coerente: todo valor com origem rastreada, toda decisão registrada, toda bifurcação resolvida antes de ir ao ar. As duas são trabalho. Nenhuma é gosto pessoal.