lucas.gaspareto_
/
// ───────────────────────case · eon-studio───────────────────────
← todos os cases

// case · eon-studio

EON Studio — Design System (4P Capital)

Design system que virou backbone de três produtos e um time de doze devs. Tokens, componentes em shadcn, documentação viva — e um processo de contribuição que não depende de mim.

role Design Systems Leadtype B2B · SaaS · Infrastructureyear 2025empresa 4p-capital
0produtos sustentados
0devs consumindo
+0componentes em rotação
// system map
EON Studio
tokens
primitivos
componentes
padrões
docs
4 camadas · 1 fonte de verdade

Contexto

Três produtos B2B — plataforma de incorporação, site institucional, SaaS interno — mantidos por um time crescente. Cada um nasceu com sua própria paleta, tipografia e convenção de componente. Dívida visual crescia mais rápido do que conseguíamos pagar feature-a-feature.

Decisão

Parei de corrigir inconsistências pontuais e propus uma infraestrutura única. Princípio 3 aplicado: respeite o sistema ou substitua, nunca improvise. A pergunta deixou de ser "essa tela tá correta?" e virou "esse token existe no sistema?".

Entrega

Quatro camadas organizadas em uma árvore única:

  1. Tokens — cor, spacing, radius, motion, tipo. Valores primitivos.
  2. Primitivos — wrappers tipados sobre shadcn (Button, Input, Dialog, Tooltip, etc).
  3. Componentes — composições com intenção de produto (DocumentCard, UnitList, StageStepper).
  4. Padrões — receitas citáveis (formulário com validação, lista filtrada, detalhe com sidebar).

Cada camada tem docs MDX com exemplos executáveis e contraexemplos ("não faça isso porque..."). Governança: qualquer dev propõe via PR; mudança de token aciona review obrigatório.

Aprendizado

O medo inicial era "design system vai virar gargalo meu". O desenho foi deliberadamente no sentido oposto: o sistema precisa ser consumível sem eu estar na sala. Dois anos depois, o processo roda com contribuições recorrentes de devs e com minhas reviews concentradas em decisões não-óbvias.