Design systems que sobrevivem à entrega
A maioria dos design systems morre três meses depois do lançamento. Normalmente por excesso de ambição, não por falta dela.
Já herdámos bibliotecas com quatrocentos componentes onde a equipa usava sete. O problema não era qualidade — era que ninguém conseguia encontrar nada e, mais importante, ninguém sabia quando era permitido criar algo novo.
Comece pelos tokens, não pelos componentes
Cor, escala tipográfica, espaçamento e raio. Quatro grupos, valores contados, nomes semânticos e não descritivos. "surface-muted" sobrevive a um rebranding; "cinza-claro-2" não.
Documente a decisão, não o componente
O código já mostra as props. O que falta na documentação é sempre a mesma coisa: quando usar este componente e quando não usar. Duas frases por componente resolvem mais discussões do que uma página de exemplos.
- Um dono nomeado, com tempo alocado — não "a equipa".
- Um canal onde se pede um componente novo e se recebe resposta.
- Uma revisão trimestral que remove o que não é usado.
- Versionamento visível, para que ninguém tenha medo de actualizar.
Um design system não é uma biblioteca. É um acordo — e os acordos precisam de manutenção.
Partilhar
Deixe um comentário