Como uma tela nasce

Toda tela do programa passa pelo mesmo caminho, em todos os eixos: do entendimento da necessidade à entrega conferida pela área. O visual vem do design system e o fluxo vem do que a área de negócio validou. O P19 (Gestão de Obras, Contratos e Serviços) e o P20 (Cadastro Técnico Imobiliário) são o piloto.

A base é o documento do programa "Orientações para atuação em UX e UI", versão 1.4, de 29/10/2026.

Os seis passos

1. Entendimento e PRD inicial. O líder técnico e a equipe do eixo levantam com a área de negócio o problema, quem usa, as tarefas e as regras já conhecidas, e começam um PRD curto, que cresce ao longo do processo. Quando é preciso desenhar ou revisar uma tela, o líder chama a equipe de UX/UI e passa o contexto. Veja O PRD e as tarefas.
2. Fluxos e mockups. A equipe de UX/UI completa o entendimento com o líder e a equipe e propõe os fluxos e os mockups, só com o design system. O detalhe acompanha o tamanho da mudança: tela ou fluxo novo, ou que importa para o trabalho da área, tem detalhe para a área validar; ajuste simples reaproveita componentes e decisões já validados. Veja Mockups.
3. Validação interna. A equipe de UX/UI, o líder técnico e os devs do eixo conferem se o conjunto é consistente, se dá para construir e se o fluxo faz sentido. Decisões, dúvidas e ajustes ficam na issue da validação. Veja Validação.
4. Validação com a área. O conjunto vai para a área de negócio do TJ. A issue registra a versão mostrada, quem participou, a decisão e as ressalvas. Os ajustes ficam registrados e, quando preciso, as telas voltam para a área. Falta de resposta não é aprovação.
5. Consolidação e tarefas. O PRD recebe os fluxos, as telas, as regras, os estados e os critérios de aceite combinados, com os links dos protótipos validados. O líder técnico e a equipe montam as tarefas e as dependências, ligadas ao entregável e ao PRD.
6. Implementação e conferência. A equipe constrói a partir do PRD e dos protótipos validados. A entrega é conferida por dentro e depois pela área, pelos critérios de aceite. Diferença ou mudança relevante fica registrada e, quando preciso, passa por nova validação.

O quadro de cada projeto acompanha o trabalho em ciclos de duas semanas, marcados no campo Ciclo. Vários passos, e várias telas, cabem em um mesmo ciclo. O que entra em cada ciclo depende do escopo, das prioridades e da agenda de quem participa. Validação pendente fica registrada com o impacto dela: a issue da validação fica Pendente, e a tarefa que espera por ela fica "Bloqueada (dependência TJ)", com o que atrasa anotado na tarefa.

A aprovação de UX/UI diz que a tela serve a quem vai usá-la. Ela não dispensa a conferência técnica do código, a análise de segurança da STIC nem o aceite da área do Tribunal.

Quem faz o quê

Quem	O que faz
Área de negócio do TJ	Explica a necessidade, valida fluxos e telas e confere a entrega
Líder técnico do eixo	Faz o entendimento com a área, começa e mantém o PRD com a equipe, conduz a validação com a área com o dev sênior, monta as tarefas e acompanha a construção
Devs do eixo	Ajudam no entendimento, avaliam se dá para construir e constroem
Equipe de UX/UI (em todos os eixos)	Propõe os fluxos e os mockups, mantém o design system, revisa e apoia a validação com a área nas primeiras rodadas
Gestão do portfólio	Acompanha, decide prioridades em conflito e ajuda a destravar impedimentos

Onde fica o registro

Tudo fica no repositório de cada projeto, no GitHub. O registro é a própria issue: não há formulário a mais.

Passo	Onde fica
PRD	Um arquivo em docs/prd/, que entra por PR (pull request, o pedido para incorporar uma mudança ao projeto) e cresce a cada validação
Mockups	Imagens em docs/mockups/, que entram por PR
Validação interna e com a área	Uma issue com o modelo "Validação de telas". As decisões de tela ficam só nela; o PRD e a tarefa apontam para a issue
Tarefas	Issues no quadro do projeto, com o andamento no campo Status e o ciclo no campo Ciclo
Conferência	Uma issue com o modelo "Conferência da entrega". Diferença encontrada vira ajuste na tarefa

Duas regras práticas:

• Cada validação é um commit. A tarefa aponta para o PRD no commit da main que trouxe a versão validada, e não para a main. Assim, o dev não constrói sobre um PRD que mudou no meio do trabalho. Veja O PRD e as tarefas.
• A decisão de tela fica num lugar só. O que foi decidido sobre uma tela fica na issue "Validação de telas". O PRD traz o link da issue, sem copiar a decisão.

Os modelos de issue, o modelo de PRD e o Vocabulário, com os termos e o significado de cada status, vêm do repositório tjes-base-web, de onde todo projeto parte. Os repositórios são privados; os links abrem para quem tem acesso à organização.

Piloto: P19 e P20

As tarefas que o P19 e o P20 já têm vieram das reuniões, antes de qualquer tela. Quando as telas de cada conjunto forem validadas, essas tarefas serão revistas contra o PRD.

Material complementar

Consulte Modelos práticos de UX e UI para exemplos de levantamento, validação, conferência e checklists de usabilidade e acessibilidade. Os modelos são adaptáveis e não exigem formulários paralelos; mantenha os registros no PRD, nas issues e nos artefatos versionados.