Houston, o design system da Eduzz
Um ecossistema de produtos que parecia de empresas diferentes, e o sistema que passou a ser o ponto de apoio de quem projeta e desenvolve.
- Cliente
- Eduzz
- Ano
- 2024
- Papel
- Product Designer no time de Design System
- Disciplinas
- Design System, UI Design, Acessibilidade, Documentação
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 time alinhou 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:
- Tokens globais: cores, tipografia, espaçamento, raios e sombras compartilhados por todos os produtos.
- 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.
- Componentes: botões, formulários, feedback, navegação, cada um com uso, anatomia, código e acessibilidade documentados.
- 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.
