Introduzindo um Design System onde não existia nenhum

Identifiquei a ausência de padrões frontend, propus um Design System, construí-o do zero e ensinei o time a adotá-lo.

impactoDesenvolvimento frontend padronizadoComponentes duplicados reduzidosTornou-se referência frontend

Contexto

O frontend da AQTech tinha crescido funcionalidade por funcionalidade. Cada desenvolvedor resolvia problemas de UI localmente: três date pickers, quatro variantes de botão, espaçamento inconsistente, nenhum vocabulário compartilhado entre design e código.

Eu era estagiária. Ninguém pediu um Design System, porque o custo era invisível: era pago em pequenos incrementos em cada funcionalidade.

Problema

Duplicação era o sintoma visível; o problema real era fadiga de decisão. Toda funcionalidade exigia redecidir paddings, cores, estados de erro e APIs de componente. Reviews discutiam pixels em vez de lógica. Onboarding significava absorver folclore.

Restrições

—Sem tempo dedicado, então o sistema tinha que ser construído junto com o trabalho de funcionalidades.

—Sem ownership de designer: a fonte da verdade precisava viver em código.

—Vuetify já estava no stack; o sistema precisava envolvê-lo, não lutar contra ele.

—Como estagiária, eu não tinha autoridade para mandar em nada. A adoção precisava ser voluntária.

Alternativas Consideradas

—Adotar os padrões do Vuetify em tudo. Rejeitada: os padrões não codificavam nossos padrões de domínio (dados densos de engenharia, hierarquias de ativos), e essa lacuna era onde a duplicação crescia.

—Um guia de estilo escrito sem código. Rejeitada: documentação que exige disciplina perde para prazos.

—Uma biblioteca de componentes envolvendo o Vuetify com nossos tokens, padrões e docs. Escolhida.

Decisão

Construir o Design System como o caminho de menor resistência: importar o componente do sistema tinha que ser estritamente menos trabalho do que escrever um local.

Todo componente vinha com docs de uso e exemplos prontos para copiar e colar. Migrei as telas de maior tráfego eu mesma primeiro, para que o sistema provasse seu valor antes de pedir a alguém para adotá-lo.

Trade-offs

—Envolver o Vuetify significava herdar suas restrições e ciclo de upgrade. Aceito por velocidade.

—Construir junto com o trabalho de funcionalidades significava cobertura lenta e incremental. Aceito, porque forçou o sistema a crescer a partir de necessidades reais em vez de especulação.

—Adoção voluntária é mais lenta do que mandato. Aceito, e é por isso que os padrões sobreviveram depois que saí.

Implementação

Biblioteca de componentes em TypeScript sobre Vue 3 envolvendo o Vuetify, pareada com uma biblioteca de componentes no Figma mantida sincronizada com o código: design tokens, padrões de formulário, presets de densidade de dados e padrões de acessibilidade embutidos. A documentação vivia ao lado do código e toda página de componente respondia "quando eu uso isso em vez de X".

Estratégia de adoção: migrar as telas de maior visibilidade primeiro, fazer pareamento com cada desenvolvedor em seu primeiro uso, e tratar todo "o sistema não consegue fazer X" como um bug do sistema, não do desenvolvedor.

Impacto

—Desenvolvimento frontend padronizado; componentes duplicados pararam de aparecer em review.

—Novas funcionalidades passaram a partir de composição em vez de construção.

—Tornei-me a referência frontend do time, e os padrões permaneceram depois que saí.

—A experiência produziu um princípio duradouro: um Design System só tem sucesso quando a adoção se torna o caminho mais fácil.

Lições Aprendidas

Autoridade não é pré-requisito para padrões; evidência é. Migrar telas reais antes de pedir adoção convertia céticos melhor do que qualquer argumento.

Os melhores padrões de engenharia são adotados voluntariamente; o sistema precisa vencer a alternativa em esforço, não em princípio.

Evidência

Capacidades reivindicadas e demonstradas: Design Systems (construí um do zero), Liderança Técnica (adoção sem autoridade), Developer Experience (mentalidade de adoção como produto), Engenharia Frontend (os próprios componentes), Acessibilidade (padrões embutidos nos componentes, não retrofitados por tela).