Melhores ferramentas de design system para times pequenos

Resumo

Se o seu time tem menos de cinco pessoas, quase certamente você não tem um problema de ferramenta. Tem um problema de origem: as telas estão sendo feitas por caminhos diferentes. Nesse caso, a ferramenta certa é a que você não vai precisar manter.

As seis abaixo resolvem coisas diferentes, e a maior parte da frustração com design system vem de escolher uma que resolve um problema que você não tem.

O que uma ferramenta de design system precisa fazer

Um design system tem quatro partes, e quase nenhuma ferramenta cobre as quatro:

1. os tokens, que são as decisões: cor, escala tipográfica, espaçamento, raio de canto;
2. os componentes, que são os tokens aplicados numa peça reutilizável;
3. a documentação, que diz quando usar cada peça e, mais importante, quando não usar;
4. a sincronia, que é o que mantém o design e o código dizendo a mesma coisa depois da terceira semana.

A quarta é onde os design systems morrem. As três primeiras se fazem num sprint. A quarta é para sempre.

As categorias, e para quem cada uma serve

Oficina de componentes

Storybook. Você desenvolve o componente isolado do app, vê todos os estados dele lado a lado, e a documentação fica ao lado do componente rodando. É a única categoria em que a documentação não envelhece sozinha, porque ela é o próprio código.

Para quem: time com desenvolvedor front-end dedicado. Se ninguém no time escreve React ou equivalente, isso não é para você.

Ferramenta de design

Figma. É onde o design system nasce na maior parte dos times: os componentes, as variantes, as variáveis de cor e espaçamento. Não é uma ferramenta de design system, é uma ferramenta de design que ganhou recursos suficientes para virar uma.

Para quem: todo mundo que tem designer. A questão nunca é se você usa Figma, é o que você usa além dele.

Site de documentação

zeroheight e Supernova. Pegam o que está no Figma e no código e publicam como um site de documentação navegável, com governança, versão e aprovação.

Para quem: organização com mais de um time de produto, onde as pessoas que consomem o design system não conhecem quem o escreveu. Abaixo desse tamanho, é infraestrutura para um problema que ainda não existe.

Passagem de design para código

Zeplin. Organiza a entrega do design ao desenvolvimento: especificação, medidas, assets, o que mudou desde a última versão.

Para quem: times onde design e desenvolvimento são pessoas diferentes com rituais diferentes. Se o mesmo par de pessoas faz as duas coisas, essa camada só adiciona um passo.

Construtor de site com sistema embutido

Framer. Você monta o site com componentes e estilos compartilhados, e o resultado publicado já é o site. A consistência sai por construção, porque não existe uma segunda implementação para divergir da primeira. Guarde esse mecanismo: ele é o mais interessante desta página inteira, e volta no fim aplicado a outro tipo de produto.

Para quem: site de marketing, portfólio, landing page. Não serve para aplicação com dados e login, e é justamente aí que o mecanismo fica sem dono.

Comparação

O custo total: a licença é a parte barata

Todas as seis têm plano gratuito ou barato para time pequeno, e é por isso que a decisão parece fácil quando você está escolhendo. Os preços mudam com frequência e estão nos links no fim desta página.

O custo que ninguém coloca na planilha é o outro:

Alguém precisa manter. Um design system sem dono apodrece em um trimestre. Alguém revisa os componentes, resolve as exceções, atualiza a documentação, briga com o time que criou o décimo botão. Isso é uma fração real de uma pessoa, toda semana.

Duas verdades divergem. O componente no Figma e o componente no código são duas implementações da mesma ideia, e elas divergem. Sempre. Ferramenta de sincronia ajuda e não resolve, porque o que diverge não é o valor da cor, é a decisão sobre um estado que só existe no código.

A adoção não é automática. Um design system que existe e não é usado é pior que nenhum, porque agora você tem duas formas de fazer a mesma coisa e um documento dizendo que só uma é válida.

Para um time de duas ou três pessoas, esse custo é comparável ao de construir as telas. É a razão de tanta gente montar um design system, usar por dois meses e abandonar.

Quando você precisa de design system, e quando precisa só de consistência

Essa é a distinção que a maioria das listas não faz, e ela é o que decide se você vai gastar bem ou mal.

Você precisa de um design system de verdade quando várias pessoas constroem interface em paralelo, em bases de código ou produtos diferentes, e precisam de um contrato compartilhado. O design system é esse contrato. Sem ele, cada time inventa o seu.

Você precisa só de consistência quando o problema é que as suas telas não se parecem umas com as outras. Nesse caso a causa não é falta de contrato, é excesso de origens: cada tela foi feita numa hora, de um jeito, por uma decisão tomada na hora.

E consistência tem uma solução mais barata que contrato: origem única.

Consistência por construção, sem a manutenção

É aqui que a gente entra, e vale dizer de saída que somos parte interessada. O argumento é verificável, então julgue por ele.

É o mesmo mecanismo do Framer, aplicado ao tipo de produto que ele não atende. Quando o app inteiro é gerado a partir da mesma biblioteca, a deriva visual não chega a nascer. Não porque alguém está vigiando, mas porque não existe uma segunda forma de fazer um botão.

Na Fabapp, o app gerado consome 57 componentes prontos, de tabela com paginação a seletor de data, campo de telefone com máscara por país, upload de imagem, gráfico e diálogo de confirmação. Eles são a mesma peça em todas as telas do app, com os mesmos tokens de tema. A lista completa do que a plataforma entrega está em recursos.

Duas consequências que interessam a quem já sofreu com design system:

O sistema recusa o que foge da biblioteca. Antes de o app compilar, uma verificação estática rejeita um componente que não existe e uma propriedade inventada. Um design system em documento depende de alguém ler; este depende de o código passar.

O tema é uma decisão só. Cor, tipografia e raio saem de um conjunto de tokens aplicado ao app inteiro. Trocar a cor primária é uma mudança, não uma varredura.

E, para quem se preocupa com a saída: os componentes ficam no código do seu app, editáveis, e o código sai em ZIP ou push para o GitHub a partir do plano Builder. Você não está trocando manutenção de design system por dependência de plataforma.

Onde isso não serve. Se o seu problema é coordenar quatro times de produto em bases de código que já existem, nada disso te ajuda: você precisa do contrato compartilhado, e a lista acima é onde procurar. Origem única resolve deriva, não resolve governança.

Trocar de ferramenta, e o que sobra

Se você já tem alguma coisa montada, duas notas antes de migrar.

Os tokens migram, os componentes não. Cor, espaçamento e tipografia são dados e viajam bem entre ferramentas. Componentes carregam decisões de implementação e são reescritos, não movidos. Planeje pela segunda parte.

A documentação é a que se perde. O texto explicando por que o botão terciário existe não está em formato nenhum que se exporte. Se ele importa, copie antes de cancelar a assinatura.

Construa a interface consistente que o seu produto precisa

Se o que te trouxe até aqui foi um produto que parece feito por cinco pessoas diferentes, vale testar o caminho mais barato antes do mais completo: descrever o app que você quer e ver quanto de consistência sai de graça quando todas as telas vêm da mesma origem.

Na Fabapp, o plano Free não pede cartão.