Propor amplo, entregar enxuto
O Problema
Na PariPassu, atuando como uma das duas designers em dois produtos, propus um conjunto de componentes novos maior do que o time precisava, tentando antecipar edge cases entre Rastreador e CliCQ. Em poucas semanas ficou claro que parte das variantes nunca era usada. Adicionavam carga cognitiva sem retorno real, e a sensação de inchaço atrasava a adoção.
O Que Tentei
Minha abordagem foi completista: 'Vamos antecipar todos os casos e construir tudo de uma vez.' Mapeei vários estados de botão, variantes de card, tipos de input e edge cases com base em exercícios de design thinking, templates anteriores e padrões de DS maduros de empresas maiores.
Por Que Falhou
A premissa estava errada. A PariPassu era uma foodtech ágil servindo rastreabilidade e inspeção de qualidade. As necessidades reais de curto prazo eram uma fração do que eu havia desenhado. 'Devo usar CardStandard, CardCompact ou CardMinimal?' Sem resolver problemas reais, eu estava desenhando para futuros hipotéticos em vez de validar demanda atual.
A Lição
Design systems crescem com o produto, não na frente dele. Os melhores DS que vi em empresas maiores (Bridge, Multidrop) não saíram completos no dia 1; começaram enxutos e escalaram conforme padrões surgiam no uso real. Ficar enxuto significava: (1) engenharia entendia cada componente porque usava todos. (2) Iterávamos mais rápido, menos decisões, PRs mais rápidos. (3) Quando padrões novos surgiam, eram adicionados de forma deliberada.
O Resultado
Junto com a outra designer, podei a proposta para os componentes que o time realmente usava, mantive documentação focada neles e fiz pareamento com devs para ajustar tokens. A poda colaborativa facilitou a adoção e fez com que componentes novos fossem adicionados só quando o uso real exigia.
Impacto
Handoff design-engenharia mais rápido, menos paralisia de decisão e um sistema que refletia como o produto estava sendo construído, não como eu achava que deveria ser.