Houston Design System

Criei do zero o Houston Design System da Eduzz — tokens, componentes e o padrão de construção dos times de produto.

Entregajulho 2022
ClienteEduzz
PapelUI Designer
Duração12 meses

Contexto

A Eduzz é uma plataforma completa para monetização de conhecimento, com produtos que cobrem da criação de cursos online (Nutror) à gestão de negócios (Orbita), venda de ingressos (Blinket), checkout (Checkout Sun) e comunidade (Space).

O portfólio cresceu rápido e o design não acompanhou com estrutura. Para quem vende produto digital, uma experiência fragmentada entre plataformas não é ruído estético: é problema de confiança. Dar fundação ao design virou condição para escalar sem multiplicar o caos.

Problema

Cada produto tomava decisões de design isoladamente. Sem uma fonte da verdade, cada entrega recomeçava do zero.

A base era o Material Design do Google, direto no código, sem tokens nem reuso entre times.

  • Componentes codados à mão, gerando variações mesmo dentro de um mesmo produto.
  • Iconografia divergente entre plataformas, sem critério.
  • Usuário sentia estar em produtos diferentes da mesma empresa.
  • Negócio arcava com retrabalho constante e escala travada.

Processo

Nas primeiras fases, as decisões foram tomadas em conjunto com a liderança de design. A partir da arquitetura, atuei como UI Designer, focado na construção do próprio design system: cabia a mim decidir a estrutura e validar cada contribuição.

Diagnóstico

Antes de criar componentes, mapeei o estado de cada produto: o que já existia e onde só havia hardcode. Isso guiou por onde começar.

Princípios

Defini os princípios (simplicidade, consistência, evidência) e organizei o sistema em camadas: tokens, componentes, documentação.

Fundação

Defini cor, espaçamento e tipografia que sustentam os tokens. Também decidi criar uma biblioteca de ícones própria.

Componentes

Desenhei os componentes pela ordem de impacto no produto: primeiro os mais usados no dia a dia, depois os de maior complexidade técnica.

Handoff

Cada componente pronto passava por handoff estruturado ao time de dev: comportamento, estados e uso documentados antes de qualquer código.

Teste

Depois de codado, a equipe de design testava cada componente: comportamento e estados. Ajustes antes da publicação.

Solução

A resposta foi um sistema em camadas — tokens, componentes, documentação, iconografia e navegação — sustentando coerência em toda a plataforma.

Arquitetura em camadas

Mapa da documentação do Houston, organizada em quatro grandes camadas.

a. Foundations

  • a1. About Houston DS
  • a2. Architecture
  • a3. Tokens
  • a4. Grid

b. Libraries

  • b1. Icons
  • b2. Illustrations
  • b3. Core components
  • b4. Templates
  • b5. Help components
  • b6. Team components

c. Handoff

  • c1. Core components
  • c2. Team components

d. Others

  • d1. Zeroheight
  • d2. Github

Tokens como fundação

Cada produto tinha suas próprias variações de cor, tipografia e espaçamento — algumas deliberadas, outras hardcode acumulado. Organizar essa base foi um dos trabalhos mais complexos do projeto: genérica o bastante para servir a todos, específica o bastante para preservar a identidade de cada um.

Tokens não aparecem em tela, e o time queria ver componentes primeiro. Priorizei mesmo assim: sem essa fundação, cada ajuste de cor ou tipografia viraria busca-e-substitui em dezenas de arquivos.

  • Cor
  • Tipografia
  • Espaçamento (squish e stack)
  • Borda
  • Sombra
  • Opacidade

50+ componentes

Segui a ordem de atomic design: átomos primeiro — botão, campo, ícone —, depois moléculas que os combinam e só então organismos mais complexos.

Governança da iconografia

Com vários designers contribuindo, padronizar exigia processo. Criei um manual de iconografia no Notion — grid, traço e proporção — e conduzi um workshop de imersão.

Ver o recorte do manual de iconografia →

Biblioteca de ilustração

Banco de ilustrações curado, customizado na cor de cada produto. Usado em telas de erro, empty states e outros momentos de apoio, como onboarding.

Guia de redação

Cada produto escrevia erro, sucesso ou tooltip à sua maneira. O guia de redação estendeu à palavra a mesma governança dos ícones: tom de voz da marca e um padrão de microcopy por tipo de componente — mensagens de erro e sucesso, botões, labels, tooltips, toasts, dialogs.

Documentação

Toda a documentação de design vivia no Zeroheight — regras de uso, anatomia, conteúdo. Cada componente só estava "pronto" quando publicado no Github e documentado no Zeroheight.

Figma
Github
Notion
Zeroheight

Disseminação e adoção

Adoção não vem junto com a documentação. Foi preciso levar o sistema até o time: ensinar o uso e acompanhar a aplicação no dia a dia.

Workshops com o time de design, documentação acessível e presença ativa nas revisões para validar a aplicação dos padrões.

No Figma, o onboarding foi prático: mostrei como consumir os componentes da biblioteca e como criar team components quando um produto tinha uma necessidade que o core não cobria.

Resultados

Apesar dos resultados que vinha entregando, a nova diretoria da empresa optou por descontinuar o Houston, adotando outro caminho. Durante as iterações com os designers e desenvolvedores que usavam o sistema, chegamos a números que valem registrar:

  • 7 Produtos adotaram o sistema
  • −30% Tempo de handoff
  • −25% Tasks de prototipação
  • +30% Desenvolvimento de telas
  • 2 dias Front-end para uma POC

Produto crescendo sem fundação de design?

Me conta o contexto — design system, tokens ou a primeira biblioteca de componentes. O diagnóstico vem antes do escopo.

Envie uma mensagem