Wireframing e Prototipagem que Sobrevive à Engenharia

Na primeira vez que aconteceu comigo, quase pedi demissão.

Havia passado três semanas em um fluxo de configurações. Arquivo no Figma impecável. Cada tela. Um estado de hover no upload do avatar porque eu me importava com isso. A engenharia construiu. O estado vazio era uma caixa cinza triste com a palavra "Empty" em Arial de 12px. O toast de erro era a barra vermelha padrão do navegador. O carregamento era um spinner genérico que aparecia instantaneamente, mesmo em desenvolvimento local onde a requisição levava 40ms. A mensagem de validação? Um tooltip nativo de <input> HTML que dizia "please match the requested format."

Mandei mensagem para o engenheiro. Ele disse, com calma: "você não especificou." Fiquei com raiva. Voltei ao Figma. Ele estava certo. Eu não havia especificado.

Essa conversa é o único motivo pelo qual este guia existe. Engenharia não é o inimigo. Lacunas de spec são. E lacunas de spec são um problema de UX, não de engenharia.

Por que isso importa agora

Faça a conta de um único retrabalho. Uma funcionalidade. Um sprint. O estado vazio está errado, o tratamento de erro está faltando, a engenharia precisa refatorar o componente porque as variantes não estavam lá para começar. Com base nos meus últimos quatro empregos, o custo médio de um desses retrabalhos fica em torno de 40 horas do designer e 60 horas da engenharia. São 100 horas-pessoa, custo combinado de aproximadamente $12.000 a $15.000, dependendo do time. Um retrabalho por trimestre e você queimou $50K por ano em trabalho de correção que um handoff doc melhor teria evitado.

Esses são só os números financeiros. O custo em confiança é pior. Após o segundo retrabalho, a engenharia para de confiar nas suas specs e começa a construir o que acha que você quis dizer. Após o terceiro, seu PM para de acreditar nos seus prazos porque "design sempre precisa de mais uma rodada." O handoff não é uma entrega. É um contrato. Trate-o como tal e a maior parte disso desaparece.

Baixa vs alta fidelidade: quando cada uma justifica seu custo

O maior erro que vejo designers júniors cometendo é pular para alta fidelidade cedo demais. Mocks pixel-perfeitos antes de o fluxo estar definido. A engenharia os vê, fica animada, começa a construir. Então a pesquisa volta e o fluxo muda. Agora a engenharia entregou metade da coisa errada em código de produção e alguém precisa explicar ao PM por que o sprint atrasou.

Baixa fidelidade é para lógica de fluxo e aprovação de stakeholders. Rascunhos em papel, Balsamiq, frames rascunhados no Figma com retângulos de placeholder. A pergunta sendo respondida é "isso é sequer a ideia certa." Não polir pixels em uma tela que você pode jogar fora amanhã. A entrega é um protótipo clicável que prova que o caminho de A para B faz sentido, mais um diagrama de fluxo. Só isso.

Alta fidelidade é para a construção. Pixel-perfeita, com copy real (zero lorem ipsum, porque a engenharia vai copiar e colar e você vai encontrar "Lorem ipsum dolor" na página de login ao vivo; pergunta como sei), formatos de dados reais, todos os estados. Apenas depois de o fluxo estar travado. Se você se pega ajustando detalhes de layout em uma tela cujo fluxo ainda está sendo debatido, pare. Volte para baixa fidelidade. Trave o fluxo primeiro.

O teste honesto: se um stakeholder ainda está perguntando "espera, por que o usuário vai para cá?" você não está pronto para alta fidelidade. Não importa o quanto os retângulos estejam bonitos.

As lacunas de spec que a engenharia vai perguntar (e que você não projetou)

Essa é a parte que ninguém ensina na escola de design. Cada tela tem aproximadamente oito estados. Você provavelmente projetou dois deles. Aqui está a lista que a engenharia vai devolver para você no momento em que sentar para construir:

Os oito estados que toda tela precisa

Padrão / preenchido. O caminho feliz. Você projetou este.
Vazio. Zero itens, zero resultados, usuário pela primeira vez. O que o usuário vê quando não há nada a ver? "Nenhum item ainda" não é um design. Mostre a ilustração, o copy do CTA, a ação secundária.
Carregamento. Skeleton, spinner, UI otimista. E a regra de tempo: quanto tempo antes de o spinner aparecer? (200ms é o limiar padrão; não mostre nada abaixo disso.)
Erro. Falha de API, validação, permissão negada, rede offline. Cada um é diferente. O erro 500 não parece com o 403, que não parece com "sua senha é muito curta."
Parcial / degradado. Metade dos dados carregados, algumas imagens quebradas, widget de terceiros fora do ar. Sistemas reais chegam aqui constantemente.
Variante de permissão. Admin, membro, visualizador, convidado. O que está oculto versus desabilitado versus mostrado com tooltip?
Dados extremos. Nomes longos que quebram a linha, 0, null ou números negativos, 47 itens em uma lista projetada para 5, um ID fiscal com 32 caracteres.
Mobile / breakpoints. Se o design é desktop-first, o que acontece em 768px e 375px? "Responsivo" não é uma spec.

Mantenho essa lista fixada perto do meu monitor. Antes de qualquer handoff, percorro cada tela contra os oito estados. Se um estado é "igual ao padrão," escrevo isso. Se é "fora do escopo deste sprint," escrevo isso também. O ponto não é projetar todos os oito sempre. O ponto é decidir todos os oito, intencionalmente, e colocar a decisão no arquivo.

A lacuna dos oito estados é a falha mais comum que vejo. Resolva isso e você terá eliminado talvez 60% dos momentos de "você não especificou."

Disciplina de Auto-Layout no Figma

Auto-Layout não é opcional. Se seu arquivo não é construído sobre ele, a engenharia não consegue ver o que é um componente e o que é um frame, não consegue distinguir padding de margin, não consegue prever o que acontece quando o copy fica maior. Eles chutam. Chutam errado. Então é culpa sua.

Quatro regras que me pouparam horas:

Componentes, não frames desvinculados. Todo elemento reutilizável é um componente com um nome que a engenharia consegue ler. Um botão é Button/Primary/Default, não Rectangle 47. Se a engenharia não consegue ver o nome do componente no inspetor, está chutando.
Tokens de espaçamento reais, não margens a olho. 4, 8, 12, 16, 24, 32. Só isso. Se você está digitando padding: 13px, está fazendo errado. Escolha um e siga em frente.
Constraints configuradas para que o redimensionamento realmente funcione. Teste cada componente no maior e menor tamanho que pode assumir. Se um card quebra quando o título tem 80 caracteres, a engenharia vai encontrar esse bug em produção.
Variantes para estado. Padrão, hover, ativo, desabilitado, carregando, erro. Tudo em um componente, alternável via propriedade. A engenharia conecta a variante à máquina de estados e o arquivo se torna autodocumentado.

Um teste útil: abra seu arquivo, clique em qualquer elemento e olhe o painel da direita. Se você não consegue saber de imediato qual componente é, em qual variante está e qual token de espaçamento usa, a engenharia também não consegue. Corrija antes do handoff.

Design tokens: o contrato com a engenharia

Tokens são a coisa de maior alavancagem que um UX designer pode entregar. Cores, escala tipográfica, espaçamento, radii, sombras, durações de animação: todos nomeados, todos definidos uma vez, todos referenciados pelo nome em cada componente.

O contrato é simples. Quando um token muda (digamos, a marca atualiza de #0066FF para #0052CC), a engenharia muda uma variável, não 40 componentes. O mesmo vale para escala tipográfica, radius, cada sombra.

A infraestrutura ficou genuinamente boa. Figma Variables como fonte de verdade. Tokens Studio (ou a exportação nativa de Variables) para empurrar para JSON. O JSON é importado para a configuração do Tailwind, variáveis CSS ou um build do Style Dictionary. A engenharia nunca digita um valor hexadecimal à mão. Você nunca escolhe uma cor de memória.

Se você ainda não usa tokens, esse é o investimento de maior ROI que pode fazer neste trimestre. A primeira migração leva uma semana. Cada handoff depois fica mais barato.

O handoff doc: Loom mais anotações

O handoff doc é um contrato. Handoffs verbais não são. "Vou só falar com a engenharia" é o atalho mais caro do design. Conversas de corredor são ótimas para esclarecer. São péssimas para especificar, porque em três semanas, quando o QA encontrar uma lacuna, ninguém vai lembrar o que você disse.

Veja como um handoff doc se parece, em três partes.

Parte 1: Um Loom de 5 minutos percorrendo o fluxo. Abra o Figma, compartilhe a tela, grave. Percorra o fluxo no ritmo de um desenvolvedor que nunca o viu. Destaque: o ponto de entrada, cada tela, o comportamento não óbvio ("note que o toast desliza para dentro, não aparece gradualmente, 200ms ease-out") e toda lógica de troca de estado ("isso fica vazio quando o usuário tem zero faturas, mas se ele teve faturas e as deletou todas, mostramos a variante 'todas deletadas', não o estado vazio de primeiro acesso"). Mantenho em uma estrutura de 3 minutos: 30 segundos de contexto, 2 minutos de walkthrough do fluxo, 30 segundos de pegadinhas, 30 segundos de perguntas para a engenharia.

Parte 2: Frames anotados no Figma. Chamadas numeradas em cada tela. Não sticky notes vermelhos. Anotações numeradas reais que leem como um contrato. "1: Avatar. Clicar abre modal de upload. O modal fecha com Esc, clique no overlay e após upload bem-sucedido." Cada interação. Cada tempo de animação. Cada caso extremo que o percurso dos oito estados revelou.

Parte 3: Critérios de aceitação na linguagem da engenharia. Essa é a parte que designers pulam e não deveriam. Os critérios de aceitação se parecem com:

Quando o usuário clicar em "Salvar" com um e-mail inválido, então em até 200ms aparece um erro inline abaixo do campo com o texto "Por favor, insira um endereço de e-mail válido", o campo recebe uma borda vermelha (token: border-error) e o foco permanece no campo.

São três fatos comportamentais (tempo, copy, estado de foco) que o QA consegue verificar e a engenharia consegue construir. Escreva cinco a dez desses por tela para qualquer interação não trivial. Sim, é lento. É lento de propósito. A parte lenta é onde as lacunas de spec morrem.

Uma última regra: aponte para um único frame de referência no Figma. Não 12 arquivos. Não "veja a exploração v3 e v5, mas não a v4." Um frame. Uma URL. Se você precisa apontar para múltiplos arquivos, a engenharia vai escolher o errado e você vai merecer.

O modo de falha "vou só falar com a engenharia"

Conheço designers que se orgulham de relações próximas com a engenharia e tratam handoffs escritos como burocracia. Entendo. Já fui uma delas. A relação é real e vale investir nela. Mas a relação não é substituta do documento.

Três problemas com handoff verbal:

Sem registro. Seis semanas depois, quando o QA encontrar a lacuna, você e a engenharia vão meio que lembrar a conversa de formas diferentes. Quem tiver mais capital político vence. Não é assim que uma org de design deveria funcionar.
Sem entendimento compartilhado. A engenharia sai da chamada com a interpretação dela. Você sai com a sua. As interpretações se sobrepõem em talvez 70%. Os 30% de lacuna é onde vivem os bugs.
Sem como verificar pós-entrega. Quando você for fazer QA da build, não há nada para checar contra. Você está fazendo QA de sensações.

A regra pela qual me guio agora: se não está escrito, não aconteceu. O Loom está escrito (é uma gravação). As anotações estão escritas. Os critérios de aceitação estão escritos. Conversas de corredor do tipo "ei, você pode também fazer X" são seguidas por escrito em até uma hora, ou X não será construído.

Revisão pós-entrega

O handoff não termina quando a engenharia faz o merge. Termina quando você fez QA da build ao vivo contra o Figma, juntos, e registrou as lacunas.

Como conduzo: reunião de 30 minutos em um ambiente sandbox ou staging. Designer e engenharia compartilham tela. Percorra cada tela e cada estado. Para cada um, três resultados possíveis:

Compatível. Siga em frente.
Lacuna, corrigir neste sprint. Registre, abra o bug, a engenharia se compromete com uma correção. Geralmente 1 a 2 por funcionalidade.
Lacuna, aceitar e atualizar o Figma. Às vezes a versão da engenharia é melhor, ou a lacuna é pequena demais para valer um sprint. Atualize o Figma para corresponder à realidade. Não deixe o arquivo mentindo sobre o que está em produção.

O pecado capital é a correção silenciosa. Não atualize passivo-agressivamente o próximo release sem contar para a engenharia. Não finja que a lacuna não existe. Registre, decida juntos, siga em frente. Após alguns ciclos desse processo, a engenharia começa a confiar que o QA é colaborativo, não adversarial. Eles vão começar a levantar suas próprias preocupações mais cedo durante a construção.

Uma meta razoável: no máximo 3 lacunas registradas por funcionalidade entregada, diminuindo ao longo do tempo à medida que a disciplina dos oito estados se consolida.

Medindo o sucesso

Três sinais indicam que a disciplina de handoff está funcionando.

Zero momentos de "você não especificou" por sprint. Este é o indicador defasado. Se você está recebendo esses, o percurso dos oito estados não foi feito.
A engenharia cita nomes de frames do Figma em PRs. "Implementa Settings/Profile/Avatar-Upload v2." Quando a engenharia escreve mensagens de commit e descrições de PR que referenciam seus frames pelo nome, seu arquivo se tornou a fonte de verdade. Esse é o objetivo.
A revisão pós-entrega registra no máximo 3 lacunas por funcionalidade. E as lacunas tendem para polimentos visuais pequenos, não estados faltantes ou comportamentos errados.

Se as três condições são verdadeiras, você resolveu o problema de handoff. Seu papel passa de defender o design para expandi-lo. Que é, finalmente, o trabalho que UX deveria estar fazendo.

O arquivo no Figma não é arte. É um contrato. Escreva tudo. Percorra os oito estados. Grave o Loom. Anote os frames. Escreva critérios de aceitação na linguagem da engenharia. Faça a revisão pós-entrega. Repita isso cinco vezes seguidas e sua taxa de retrabalho cai perto de zero, e você para de temer a sexta-feira de handoff.

Camellia

Playbooks para UX Designer