Validação

Toda tela passa por duas validações antes de entrar nas tarefas: primeiro por dentro, depois com a área de negócio. Cada uma fica numa issue com o modelo "Validação de telas", no repositório do projeto. As decisões de tela ficam só nessa issue: o PRD e as tarefas apontam para ela, sem copiar a decisão.

Validação interna

Participam a equipe de UX/UI, o líder técnico e os devs do eixo. Eles conferem:

• se as telas seguem os Padrões de tela e usam só componentes do design system;
• se dá para construir: os dados que a tela mostra existem ou têm de onde vir, e o que falta no design system já tem issue;
• se o fluxo faz sentido do começo ao fim;
• se os textos seguem Como escrever as mensagens;
• se cada tela tem os estados que a mudança pede (veja Mockups).

Decisões, dúvidas e ajustes ficam na issue. O conjunto só vai para a área depois de aprovado aqui.

Validação com a área

O líder técnico conduz, com o dev sênior do eixo. Nas primeiras rodadas, a equipe de UX/UI apoia. Mostre:

• o conjunto inteiro, na ordem do fluxo: primeiro o caso comum, depois os outros estados;
• dados de exemplo parecidos com os do trabalho real, sempre fictícios;
• as dúvidas que só a área responde, como uma regra que ainda não foi definida, numa pergunta direta.

Pergunte se o fluxo segue o trabalho de verdade, se os nomes são os que a área usa e se falta alguma informação ou passo. Quando preciso, as telas voltam para a área com os ajustes.

Como registrar a decisão

A issue registra a versão mostrada (os links das imagens ou do protótipo, com a versão), participantes, data, responsável pela decisão, decisão, ressalvas e link da evidência quando houver. Registre as verificações de UX e acessibilidade e suas evidências conforme a solução; use os modelos práticos como apoio, sem duplicar formulários. Marque uma decisão só:

Decisão	Quando	O que acontece
Aprovado	Nada a mudar	O conjunto segue: da validação interna para a área, da área para a consolidação do PRD
Aprovado com ressalvas	Ajustes pequenos, que não mudam o fluxo nem as regras	O conjunto segue. As ressalvas ficam na issue e entram na versão seguinte das telas, que é a que o PRD usa, sem nova rodada
Ajustes necessários	O ajuste muda o fluxo, uma regra ou várias telas	Sai uma nova versão das telas, e ela passa por nova validação, numa issue nova
Pendente	A decisão ainda não saiu	O conjunto espera, e a tarefa que depende dele fica "Bloqueada (dependência TJ)"

Em "Decisões, ajustes e ressalvas", anote o que ficou decidido, o que muda, em qual tela e quem faz. A tarefa que o ajuste muda recebe o link da issue. Se a aprovação veio numa reunião, por e-mail ou por mensagem, registre na issue quem aprovou e quando.

Quando a validação fecha, a atualização do PRD entra por PR (pull request, o pedido para incorporar uma mudança ao projeto). O commit da main que ela gera é a versão validada: anote o link dele no comentário que fecha a issue.

Falta de resposta não é aprovação

Se a área não respondeu, a decisão é Pendente. O PRD só é consolidado com a aprovação escrita na issue. Anote na tarefa o que a espera atrasa. Quando a resposta demora, o líder técnico cobra a área e, se continuar parado, leva o caso à gestão do portfólio.