Módulo 6 · 5 de 6
Caso real: a designer que não esperou o dev
Leitura: ~5 min
Entre o módulo passado e este, falamos de peças soltas: spec (lá no Módulo 5), CLI, MCP e analytics. Cada uma fez sentido sozinha. Agora quero juntá-las em uma história real, porque é quando essas peças se encontram dentro de um fluxo de trabalho que elas param de ser jargão e viram ferramenta.
E tem um detalhe que eu faço questão de adiantar: a protagonista dessa história não é uma engenheira. É uma designer. Você vai reconhecer nela um pouco da sua própria rotina.
O problema que todo designer conhece
Pense comigo em uma cena que talvez você já tenha vivido. A designer, vou chamá-la de Marina, percebe que os botões do produto estão inconsistentes. Em uma tela, o botão primário é roxo; em outra, é de um roxo levemente diferente. O design system definia um único token de cor, mas o código de algumas telas tinha ignorado o token e cravado a cor na mão.
Detalhe importante para quem está chegando agora: token é o nome que damos a cada decisão de design guardada como uma variável reutilizável: a cor primária, o espaçamento base, o raio da borda. Quando o código usa o token, toda tela herda a mesma decisão. Quando ignora, nasce a inconsistência.
Até pouco tempo atrás, o caminho da Marina seria um só: abrir um chamado, descrever o problema, e esperar. Talvez duas sprints. Talvez mais, porque "trocar uma corzinha" sempre perde a fila para a entrega que está pegando fogo.
Caso real
O mesmo problema, com o repertório novo
Dessa vez, a Marina fez diferente. Não virou programadora da noite para o dia. Ela usou exatamente as peças que você viu nestes dois últimos módulos.
Primeiro, escreveu um spec, aquele contrato claro do que precisa mudar: "toda referência de cor primária cravada na mão deve passar a usar o token --color-accent; nenhuma outra cor deve ser tocada; o resultado tem que passar nos testes visuais existentes". Curto, específico, sem ambiguidade. O spec é o que separa um pedido vago de uma tarefa executável.
Depois, abriu uma ferramenta de agente de IA (como o Claude Code ou o Cursor, que ela conheceu no Módulo 5), conectada ao repositório do design system e ao Figma via MCP, o protocolo que dá à IA acesso coordenado e autorizado às ferramentas certas. O agente leu o spec, varreu o código, encontrou as telas com a cor cravada na mão e propôs a troca pelo token, arquivo por arquivo.
Marina não aceitou nada no escuro. Ela revisou a proposta como quem revisa um layout: isso aqui faz sentido? Esse arquivo deveria mesmo mudar? Um desenvolvedor do time deu o aval final e a mudança entrou. O que levaria duas sprints levou uma tarde, e a designer esteve no controle da decisão o tempo inteiro.
E aqui vem a parte que fecha o módulo. Marina não parou no "ficou bonito". Ela foi medir. Usando os mesmos eventos de analytics que você viu no capítulo anterior, acompanhou se a interface mais limpa e consistente mudou o comportamento de quem usa o produto: a conclusão do fluxo principal subiu, e o tempo de hesitação na tela do botão caiu. Decisão de design virou número, e número virou argumento na próxima reunião.
O que realmente mudou
Repare no que aconteceu, porque não foi a Marina virar dev. Foi a Marina ganhar autonomia. Ela saiu da posição de quem só descreve o problema e espera, e entrou na posição de quem propõe a solução, valida e mede o resultado. As ferramentas não substituíram o olhar dela; ampliaram o alcance dele.
Se ler "agente", "repositório", "token" te dá um frio na barriga, relaxa. Note que em nenhum momento a Marina precisou decorar comandos ou escrever código do zero. Ela precisou de uma coisa que é, no fundo, design: descrever com clareza o que deveria acontecer e julgar se o resultado estava certo. Isso você já sabe fazer.
E se você está pensando em carreira e portfólio, olhe de novo para essa história. "Identifiquei uma inconsistência de design system, especifiquei a correção, coordenei a execução com IA e medi o impacto no comportamento do usuário" é exatamente o tipo de frase que muda o nível de uma entrevista. Não é o designer que faz telas bonitas. É o designer que fecha o ciclo entre intenção, execução e evidência.