15 de março de 2024

Como construir um design system que o time de produto realmente usa

Por Vitor Botelho, Product Designer

A maioria dos design systems morre por abandono, não por falta de componentes. O problema não é técnico. É de adoção.

Como construir um design system que o time de produto realmente usa

O problema que ninguém nomeia

Todo mundo quer um design system. Poucos times mantêm um vivo por mais de seis meses.

O sintoma clássico: a biblioteca de componentes cresce, fica pesada demais para o uso diário, e os designers começam a trabalhar ao redor dela. Doze meses depois você tem dois produtos: o oficial, e o que o time realmente entrega.

Isso não é uma falha de execução. É uma falha de premissa.

A premissa errada

A premissa errada é: "vamos construir todos os componentes e a adoção vai seguir".

Não funciona assim. Adoção não é consequência de completude. É consequência de utilidade percebida. Se o design system não resolve os problemas reais que o time de produto enfrenta hoje, ele é ignorado. Educadamente, mas completamente.

O que funciona

Construa de fora para dentro. Comece com os problemas concretos que o time está enfrentando agora, não com os componentes que "deveriam existir" na teoria.

Na prática, isso significa:

1. Auditoria antes de criar

Antes de criar um único componente novo, documente o que já existe. Você vai encontrar quatro versões do mesmo botão e três variantes do mesmo card. Esse inventário é o seu backlog real.

2. Componentes de alto retorno primeiro

Quais componentes aparecem em mais de cinco telas? Comece por eles. Um botão bem feito tem mais impacto do que vinte componentes de casos extremos.

3. Documentação como produto

Documentação não é acessório. É o produto. Um componente sem documentação clara é um componente que não existe para a maior parte do time.

4. Ciclo de feedback curto

Revisão semanal com as pessoas que usam o sistema. O que está bloqueando? O que está errado? O que está faltando? Sem esse ciclo, você está construindo no vazio.

A métrica que importa

Não é o número de componentes. Não é a cobertura da biblioteca.

É esta: quando um designer precisa construir uma nova tela, que porcentagem do trabalho o design system já resolve?

Se a resposta for abaixo de sessenta por cento, o sistema ainda não é maduro o suficiente para retornar o investimento.

Esse número cresce com o tempo, se você iterar com disciplina.