Você entra num produto com anos de interface inconsistente e nenhum design system. Por onde você começa?

Comece com uma auditoria e um business case, não com uma reconstrução. Inventarie os componentes que de fato existem em produção, conte as variantes, e quantifique o custo em tempo de engenharia e em bugs. Depois arrume primeiro a superfície de maior tráfego e maior dor, e extraia fundações compartilhadas do trabalho real: cor, tipografia, espaçamento, e depois os dois ou três componentes mais usados.

Eu não abriria com uma proposta de redesign, porque ninguém tem motivo nenhum para confiar em mim ainda. O primeiro mês é auditoria. Eu tiro print de cada tela e puxo o CSS real com um engenheiro, e o resultado costuma ser chocante de um jeito útil: num produto a gente tinha quatorze tons de cinza e nove tratamentos de botão, quatro dos quais eram o mesmo design implementado quatro vezes separadas. Aquele artefato faz a persuasão por mim, muito melhor que um manifesto sobre consistência. Depois eu ponho um número nisso: quanto tempo um formulário novo leva para ser construído hoje versus com componentes compartilhados, mais as falhas de acessibilidade que a gente teria que corrigir de qualquer jeito. Aí eu escolho um fluxo de alto tráfego, de preferência um que já está no roadmap, e faço direito, extraindo tokens de cor, tipografia e espaçamento pelo caminho. Componentes reais saem de trabalho real, não de um designer sentado sozinho construindo uma biblioteca que ninguém pediu. E um engenheiro é co-dono desde o primeiro dia, porque um sistema que só existe no Figma é um mood board.