Houston,odesignsystemdaEduzz

O contexto

A Eduzz não é um produto, é um ecossistema: checkout, área de membros, painel do produtor, ferramentas de marketing, apps. Cada um nasceu num momento diferente, com um time diferente, e carregava as próprias escolhas de botão, cor, espaçamento e tom.

Para quem usa, isso aparece como uma sensação difusa de que “cada parte funciona de um jeito”. Para quem constrói, aparece como retrabalho: o mesmo componente desenhado e implementado várias vezes, cada vez um pouco diferente.

A dor

Três sintomas se repetiam:

• Lentidão para lançar. Cada feature nova começava do zero na interface.
• Manutenção cara. Mudar um padrão significava caçar o mesmo elemento em vários produtos.
• Decisões sem referência. Produto, design e engenharia discutiam a mesma dúvida várias vezes, porque não havia um lugar para consultar a resposta.

O estudo

Antes de desenhar componente, o projeto começou alinhando com o time da Eduzz para que o sistema existia. Os objetivos viraram a primeira página da documentação e o critério para decidir o que entrava ou não no Houston:

O nome veio da própria cultura da empresa. A Eduzz já usava uma temática espacial nos nomes de produtos e no mascote; um sistema que existe para dar suporte a quem está construindo só podia se chamar como o centro de controle mais famoso do mundo.

A solução

O sistema foi organizado em camadas:

1. Tokens globais: cores, tipografia, espaçamento, raios e sombras compartilhados por todos os produtos.
2. Tokens de marca: cada produto do ecossistema tem sua paleta, mas herda a mesma estrutura. Isso permite ter identidades distintas sem quebrar a consistência.
3. Componentes: botões, formulários, feedback, navegação, cada um com uso, anatomia, código e acessibilidade documentados.
4. Conteúdo: diretrizes de escrita e tom.

A página de cada componente segue a mesma estrutura, com abas de Design, Uso, Código, Acessibilidade e Como testar. Assim, quem chega de design ou de engenharia encontra a mesma fonte da verdade.

No Figma, a biblioteca espelhava a documentação: tipografia, componentes e ícones organizados para serem consumidos pelos times de produto.

O que mudou

Os times de produto ganharam um ponto de partida comum. Uma dúvida de interface passou a ter endereço (a documentação), e uma mudança de padrão passou a acontecer num lugar só e se propagar para os produtos.

O que eu levo desse projeto

Design system é produto interno, e o usuário dele é o time. A parte mais importante não foi o componente mais bonito, foi a documentação com as mesmas abas para design e engenharia. Um sistema que ninguém consulta não padroniza nada.

Essa lição ficou mais atual quando passei a construir com agentes de IA. Agente não adivinha padrão, segue o que está escrito. Token com nome e regra de uso documentada servem para os dois: para o time e para o agente.