Handoff de design: entregue decisões e critérios de aceite

Um arquivo com telas organizadas pode continuar deixando perguntas essenciais para o desenvolvimento. Qual informação vem do serviço? O que acontece se ela não chegar? Onde o foco fica depois de fechar um painel? Handoff de design é o trabalho de tornar essas decisões compartilhadas e verificáveis, mantendo uma conversa sobre o comportamento final.

Apresente o fluxo antes das medidas

Identifique a tarefa, os pontos de entrada e o resultado esperado. Mostre como as telas se relacionam e quais condições mudam o caminho. Uma sequência numerada de imagens não explica, sozinha, se um passo é obrigatório, condicional ou apenas ilustrativo. Registre essas distinções para evitar interpretações diferentes durante a implementação.

Em um portal hipotético de pedidos de assistência, anexar uma fotografia é opcional em alguns tipos de ocorrência e obrigatório em outros. O handoff deve indicar a regra e seu efeito no envio. Descrever apenas o campo visual faz o desenvolvimento descobrir a dependência tarde demais.

Inclua dados e estados que pressionam o desenho

Forneça exemplos de conteúdo longo, ausência de dado, carregamento e erro. Indique limites conhecidos e quem define cada validação. Um componente pode parecer estável com uma frase curta e romper com uma resposta real do serviço. Os exemplos precisam revelar essas condições antes de a tela ser considerada pronta.

Esclareça a origem da informação

Marque o que é conteúdo fixo, configuração ou dado recebido. Se uma lista depende de uma integração, registre ordenação e tratamento de indisponibilidade conforme os acordos do produto. Evite apresentar um valor ilustrativo com aparência de regra, principalmente quando ele determina uma decisão de negócio.

Descreva adaptação e interação como regras

Explique quais regiões crescem, quais mudam de posição e como rótulos quebram em telas estreitas. Para ações, detalhe abertura, fechamento, foco e preservação dos dados. Imagens de desktop e celular devem exemplificar essas regras, sem substituir a descrição do que acontece entre os dois tamanhos.

Reutilize os nomes dos componentes e tokens já adotados pela equipe. Quando uma exceção for necessária, informe o motivo. Um botão parecido com o componente existente, mas copiado e alterado silenciosamente, pode perder correções compartilhadas e tornar a manutenção mais difícil.

Transforme intenções em critérios observáveis

Troque a orientação funcionar bem com teclado por comportamentos verificáveis: alcançar o controle, abrir o painel, operar seus campos e retornar ao acionador. Para conteúdo, especifique que a mensagem completa permanece legível em determinada condição de ampliação. O foco é permitir conferir um resultado, sem depender da memória de uma discussão.

A documentação de acessibilidade do USWDS reforça a relação entre componentes e avaliação na implementação. Um padrão de biblioteca não garante, sozinho, a acessibilidade da página composta. Inclua revisão do fluxo real nos critérios, especialmente quando componentes recebem conteúdo ou regras específicos do produto.

Feche dúvidas e revise no ambiente implementado

Faça uma conversa curta antes de iniciar o trabalho para revelar dependências e restrições. Registre decisões que alterem o desenho no mesmo lugar consultado pela equipe. Um acordo importante perdido em mensagens privadas tende a reaparecer como divergência na revisão.

Ao receber a implementação, percorra a tarefa com os mesmos exemplos do handoff. Separe diferenças que afetam significado e operação de refinamentos visuais menores. Comece pelo fluxo de maior risco e atualize a especificação com o comportamento aprovado. O handoff termina quando as decisões relevantes estão refletidas no produto e podem ser verificadas por outra pessoa.