Todo time que adota um design system passa pela mesma euforia inicial: menos retrabalho, mais consistência, decisões de UI resolvidas de uma vez por todas. E por um tempo, funciona. O problema aparece depois, quando o sistema deixa de ser uma ferramenta e vira um álibi.
O sintoma
Alguém pergunta por que um fluxo específico usa um modal em vez de uma página inteira, e a resposta é "porque é o padrão do design system". Ninguém lembra por que o padrão existe, só que ele existe. A pergunta original, o que é melhor para quem está usando isso agora, nunca chega a ser feita.
Um sistema bem feito acelera a decisão certa. Um sistema mal usado substitui a decisão pela obediência.
A causa real
Design systems são criados pra resolver um problema de escala: muitos times, pouco tempo, necessidade de consistência visual. Mas a maioria dos produtos não tem esse problema o tempo todo: tem ele em algumas partes e não em outras. Quando o sistema é tratado como lei em vez de ferramenta, ele passa a governar até os casos em que deveria ser questionado.
Alguns sinais de que isso está acontecendo no seu time:
- Reviews de design viram checagem de conformidade, não discussão sobre o problema do usuário.
- Ninguém sabe quem pode propor uma exceção, ou tem medo de propor.
- O componente existe, mas ele claramente não resolve o caso de uso em questão.
O que fazer
Tratar o sistema como ponto de partida, não como veredito final. Documentar não só o padrão, mas o motivo dele existir, pra quando alguém precisar decidir se aquele motivo ainda se aplica. E, o mais importante: manter um caminho simples pra propor e validar uma exceção, sem que isso vire uma batalha.
Um design system devolve tempo ao time. O objetivo é ter mais espaço pra pensar nos problemas difíceis, não um motivo a mais pra não pensar neles.
Comentários
Entre com sua conta pra participar da discussão.
Entrar →Nenhum comentário ainda. Seja o primeiro.