Houston Design System

Fundei o Houston Design System e ele foi adotado por todos os produtos da Eduzz. Enquanto esteve em operação, o impacto atravessou a cadeia de entrega inteira: até 30% menos tempo de handoff e um MVP novo saindo de uma semana para dois dias.

EntregaA definir
ClienteEduzz
PapelFundador · Product Designer
DuraçãoA definir

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

Não havia estrutura formalizada quando o projeto começou. Nas primeiras fases — diagnóstico e princípios —, as decisões foram tomadas em conjunto com a liderança de design. A partir da arquitetura, atuei como Designer Ops, 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 e arquitetura

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, em vez de um set pronto.

Design de 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 do componente

Depois de codado, a equipe de design testava cada componente: comportamento, estados, aderência à spec. 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 — puramente ilustrativo, pra situar o que vem a seguir.

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 documentados

Segui a ordem padrão de mercado (atomic design): átomos primeiro — botão, campo, ícone —, depois moléculas que os combinam e só então organismos mais complexos. Priorização por impacto em produto dentro de cada camada.

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, com uma checklist que cada ícone passava antes de entrar na biblioteca. Foram 163 ícones com identidade coerente entre todos os produtos.

Ver o recorte do manual de iconografia →

Biblioteca de ilustração

Um conjunto de ilustrações para estados vazios, onboarding e feedback, com o mesmo cuidado de consistência aplicado aos ícones — para que nenhum produto precisasse recorrer a estilos externos.

Guia de redação

Além de componentes visuais, o Houston precisava de consistência na escrita — microcopy, mensagens de erro e tom de voz. Criei um guia de redação com regras práticas para orientar designers e desenvolvedores na hora de escrever para a interface.

Documentação

Toda a documentação vivia no Notion — regras de uso, anatomia, checklists. Cada componente só estava "pronto" quando publicado. Documentar e treinar alongava o prazo por componente, mas evitava o custo pior: um sistema usado errado, que reintroduz a inconsistência que ele existia para eliminar.

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.

Conduzi workshops com os designers, mantive a documentação acessível em desktop e mobile e acompanhei as 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, sem manter um time dedicado à manutenção. 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 MVP

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