Cosmonauta — Design System White Label da Stations
Reestruturei o design system legado da Stations para um ecossistema mobile White Label com mais de 80 apps. Migração para Atomic Design, semântica de tokens (light/dark), cultura de Design Ops e a ponte do Figma ao Storybook com a engenharia.
Time-to-market −50%Como dar consistência e velocidade a mais de 80 apps White Label — onde até as cores são restritas por rivalidades de marca — sem depender de componentes 'Frankenstein'?
A Stations opera apps mobile White Label em verticais que vão de saúde e academias ao segmento esportivo — mais de 80 produtos ativos. O desafio era manter consistência visual e velocidade de entrega num cenário multiempresa altamente customizável. Assumi a reestruturação do design system legado, que operava sem semântica e com componentes sobrecarregados, rumo a uma base sólida em Atomic Design, documentada de ponta a ponta e unificada entre Design e Engenharia.
Componentes 'Frankenstein'
Os componentes legados tentavam resolver tudo: um único cartão acumulava imagem, texto, badges e boletos numa estrutura rígida. Sem autonomia, os desenvolvedores recriavam soluções manuais em Tailwind, quebrando a consistência — e cada fluxo levava duas semanas para entregar.

De 40 para mais de 80 componentes
Destrinchei os componentes complexos em átomos, moléculas e organismos. O sistema saltou de 40 para mais de 80 componentes enxutos e combináveis — incluindo um Home Layout Builder de seções modulares para montar telas iniciais inteiras.

Semântica de cores que troca de marca
Implementei tokens estruturados (primária, secundária, terciária) com light e dark mode nativos. O app muda de cor dinamicamente conforme a marca do cliente — e respeita restrições críticas, como um clube que não pode herdar as cores do rival.

Status, rastreabilidade e checklists
Documentei o processo no Figma com uma Status Bar de quatro fases (Pesquisa, Criação, Handoff e Produção) e um Card de Status por fluxo — com módulo, última atualização e observações ligadas às tarefas do Jira, garantindo rastreabilidade. Para avançar de fase, o designer preenche um checklist obrigatório de conclusão, evitando etapas puladas antes da revisão da liderança.

Do Figma ao Storybook
Tirei o design system do isolamento do Figma e o publiquei no Storybook via NPM. Para validar a transição, rodei uma pesquisa de satisfação com o time de desenvolvimento e iterei a partir do feedback.

Checklists de avanço de status
- PesquisaÉ um problema de mercado denso?
- BenchmarkAnálise de referências de mercado
- DefiniçãoValidação de problema e nicho interno
- Uso de tokensCores, tipografia, espaçamento
- Uso de Design SystemCores, radius, ícones, spacing
- UI WritingRevisão de todo o texto
- Impacto em produtos-alvoComo um produto afeta o outro
- Validação de produtoTeste e feedback com clientes
- Product critiqueValidar com a squad de produto
- Validação técnicaLiderança de produto e design
- EspecificaçãoRefinos de UI para os devs
- Tokens, fontes e raiosDouble-check do que vai para o código
- Estados de exceçãoTelas de erro e casos-limite
- Estados de carregamentoLoading e skeletons

Fluxos críticos padronizados, base pronta para escalar
Unifiquei os fluxos de pagamento (faturas, ingressos, planos) e as telas de confirmação, tirando peso do código do app. O resultado é um ecossistema limpo e documentado no Storybook — estruturado, inclusive, para no futuro ser consumido por IA no backoffice na geração automatizada de telas base.
- Componente que tenta resolver tudo não resolve nada — Atomic Design devolve clareza e autonomia ao time.
- Design system só vira produto quando sai do Figma: Storybook e Design Ops fecham o ciclo com a engenharia.
- Semântica de tokens destrava escala comercial — até onde a marca impõe restrições de cor.