Um design system para a próxima tela não sair diferente

Um ERP denso, sobre uma base incompleta

Um produto SaaS B2B de gestão, com muitas entidades relacionadas, cálculos, validações e impedimentos. O designer não recebe wireframe: recebe regra de negócio, muitas vezes escrita para desenvolvedor.

Havia uma biblioteca parcial, criada por um designer anterior sobre uma estrutura baseada em Tailwind, com alguns componentes. Faltavam estados, padrões de tela, regras de escrita e documentação, e tudo o que ficava fora dela ainda era decidido tela a tela, enquanto o time precisava entregar funcionalidade.

Os detalhes do produto ficam de fora por confidencialidade. Este case mostra o sistema.

Expandir a base sem parar a esteira

Expandir o sistema e alimentar a demanda ao mesmo tempo produzia três problemas encadeados.

Deriva de layout

Cada tela era montada seção por seção, então duas telas do mesmo tipo saíam diferentes: card em outra posição, botão com rótulo genérico, cor fora do token.

Nenhum contrato com o desenvolvimento

Sem estados, nomes de propriedade e tokens definidos, o handoff virava interpretação, e a divergência só aparecia na revisão.

Custo que crescia com a escala

Sem padrão, cada nova tela dependia de decisões manuais, e o custo de desenhar subia em vez de cair.

As regras que seguram a consistência

A decisão estruturante veio antes dos componentes: tratar o sistema como infraestrutura legível por máquina. Cor, componentes, navegação, tabelas, nomenclatura e o mapa de RGB para nome de variable foram escritos em arquivos versionados, para que o trabalho no Figma seguisse regra explícita, não instrução solta.

Padronizar o conjunto de telas, não a tela isolada

Toda funcionalidade tem seis telas previsíveis, listagem, listagem vazia, adicionar ou editar, validação, sucesso e menu, e cinco modais padrão, de confirmar exclusão a exclusão impedida. Os casos ingratos, como excluir um registro com dependência, passam a ser desenhados sempre.

Clonar templates validados em vez de montar do zero

Foi a regra que resolveu a deriva. As demandas foram classificadas em três estruturas de tela, cada uma com playbook e template de referência.

Um gate de validação antes de entregar

Nenhuma tela é apresentada sem passar pelo checklist, que reprova a entrega antes de ela chegar ao time.

Status visível no próprio arquivo

Cada componente e cada tela carrega uma tag de progresso, e produto e engenharia sabem o que está pronto sem perguntar.

RtD pronto para desenvolvimento  WiP em andamento  Blocked dependência pendente  Template base, não implementar

O que foi descartado

• Estilos de pintura saíram do arquivo, o que tornou obrigatório vincular cor por variable.
• Improviso de componente foi proibido: se algo não existe no Style Guide, aponta-se a alternativa mais próxima ou abre-se demanda para o sistema.
• Redimensionar instâncias sem auto layout foi vetado, porque quebrava o posicionamento interno.

De base parcial a sistema completo

É um sistema para uso interno, então o impacto se mede em consistência, previsibilidade e velocidade, não em conversão.

• Cobertura integral: 65 páginas no Style Guide, 54 de 54 itens e 23 de 23 componentes documentados no último registro de métricas.
• Zero cor hardcoded e zero fonte manual nas telas que passam pelo gate, por construção.
• Deriva de layout resolvida na origem, ao trocar montagem por clone de template validado.
• Escopo previsível por funcionalidade: seis telas e cinco modais, sem discussão sobre o que desenhar.
• Handoff com contrato explícito: estados nomeados, propriedades documentadas, tokens em vez de valores e tag de status.
• Onboarding reduzido a ler um playbook. Uma pessoa nova, ou um agente, produz tela aderente pelo mesmo caminho.

De base de um produto a design system da empresa

O sistema nasceu para um produto, mas com estrutura de sistema: tokens em escala, componentes com propriedades declaradas, documentação com formato fixo e regras em arquivo. Isso viabiliza o passo seguinte, um design system único para todos os produtos da empresa.

Telas vindas de outro fluxo já adotaram o mesmo sistema em vez de seguir um padrão próprio. Cada produto que entra na fundação reduz o custo de manter consistência.

O que este projeto prova

Construir um design system não é escolher paleta e tipografia. É decidir quais estados existem, quais telas uma funcionalidade sempre tem, como um erro é comunicado e como tudo isso é verificado antes de chegar ao desenvolvimento.

Consistência só se sustenta quando as regras são executáveis. Documento de boas práticas não impede que a próxima tela saia diferente. Regra em arquivo, template para clonar e checklist que reprova a entrega, sim.

A IA não substituiu decisão de design. Quais tokens existem, quais estados são obrigatórios, qual o conjunto de telas e como é uma página de documentação foram decisões de design, tomadas por pessoas. A IA executou essas decisões com repetibilidade, num volume que não seria viável à mão.

Ficha técnica

Projeto

Design system de um produto SaaS B2B: tokens, biblioteca de componentes, padrões de tela e documentação

Empresa

Turn2C. Detalhes do produto omitidos por confidencialidade

Tipo de projeto

Design system e processo de design com IA

Ano

2026

Papel no projeto

Design system expandido a partir de uma biblioteca parcial, em conjunto com outro designer do time: fundação visual, biblioteca de componentes, padrões de tela, normas de escrita, documentação e definição do processo de trabalho com IA, em colaboração com produto e engenharia

Status

Real