DS4FUN
O primeiro design system da Pay4Fun. Tokens iguais no Figma e no código, componentes testados e governança automática: a CI barra o desvio e um auditor confere os frames do Figma.
- Papel
- Lead Design Ops e arquiteto do sistema
- Time
- 5 pessoas: eu, 2 designers e 2 devs front-end
- Escopo
- Tokens, biblioteca de componentes, governança e handoff
- Empresa
- Pay4Fun
NotaTelas de produto da Pay4Fun omitidas: as imagens mostram só a documentação do design system. Números agregados do repositório.
Resultados
- −40%de pedidos de esclarecimento técnico no handoff entre design e engenharia
- 225variáveis CSS geradas dos tokens via Style Dictionary, no padrão DTCG
Demo interativa
Audite um frame contra o design system
Um frame com cinco violações plantadas. Escolha um achado para ver onde ele está, corrija e acompanhe a nota subir.
Design system fictício: grade de 4 px · toque ≥ 44 px · texto ≥ 4,5:1 · cor por token
Nota de conformidade
64/100
100 − 10 × 3 erros − 3 × 2 alertas = 64
Cada erro tira 10 pontos; cada alerta, 3.
Por categoria
- Cor1 erro
- Tipografiaok
- Espaçamento1 alerta
- Raiook
- Componentesok
- Nomenclatura1 alerta
- Estilosok
- Contraste WCAG1 erro
- Heurísticas1 erro
Achados
5 abertos
- Cor fora do token: #4F6BED solto no fundo do botão.Como corrigir: Usar o token cor.acao.primaria (#2346D9).
- Texto de ajuda com contraste de 2,9:1. O mínimo AA é 4,5:1.Como corrigir: Usar cor.texto.secundario (#5B606B), com 6,3:1.
- Botão com 36 px de altura: alvo de toque abaixo de 44 px.Como corrigir: Trocar pela instância Botão/Grande, com 48 px.
- Dois espaçamentos de 13 px, fora da grade de 4.Como corrigir: 12 px entre campo e ajuda, 16 px antes do botão.
- Camada com nome genérico: “Rectangle 12”.Como corrigir: Renomear para Campo/Valor.
Design system fictício. A ferramenta real audita frames do Figma e também avalia o handoff em 5 pilares: estados, regras, escopo, acessibilidade e performance.
O problema
As telas saíam com desvios visuais, e o handoff dependia de longas explicações.
Os devs recriavam telas porque os tokens do Figma e do CSS não batiam. Cada entrega pedia alinhamento manual, e a consistência se perdia a cada sprint.
Decisões
Tokens semânticos nos dois temas
O dev usa surface.base em vez de neutral/200. No Figma são cerca de 80 variáveis por modo (53 de cor e 27 numéricas), nos temas claro e escuro. Trocar de tema não pede retrabalho.
Ampliar imagemAs mesmas variáveis no código
No código, 118 primitivos e 107 semânticos, mais 10 estilos de texto, geram 225 variáveis CSS via Style Dictionary, no padrão DTCG. Tema e audiência são eixos separados.
Ampliar imagemPlayground no lugar de PDF
Em vez de um PDF longo, um playground: tipo, estado e tamanho do botão, com o código gerado ao vivo. O dev testa e copia na hora.
Ampliar imagemDesvio registrado com motivo
A CI bloqueia componente sem story e aponta divergência entre Figma e código. Quando o desvio é intencional, ele entra num registro com o motivo: são 16 hoje, a maioria por WCAG ou pelo modo escuro.
Auditor de frames do Figma
Criei o ds_auditor, em React e TypeScript. Ele lê frames do Figma e dá uma nota de 0 a 100 em 9 categorias, de cor e tipografia a contraste WCAG e alvo de toque de 44 px. Também confere o handoff: estados, regras, escopo, acessibilidade e performance.
Padrões montados, além de componentes
Documentei padrões montados, como a Data Table com seleção múltipla, ações por linha e paginação. O time monta fluxos reais sem reinventar a composição.
Ampliar imagem
Processo
Atrasos nas sprints
Mapeei os atrasos das sprints: os devs recriavam telas porque os tokens do Figma e do CSS não batiam.
Tokens iguais nos dois lados
Uma estrutura de tokens semânticos, igual nos dois lados, cortaria a conversa de handoff.
Ajuste no modo escuro
No Storybook com os devs, tokens amplos demais geravam dúvida no modo escuro. Criei tokens funcionais explícitos.
Governança automática
Pipeline com Style Dictionary, CI que barra desvio e o ds_auditor conferindo os frames do Figma.