Modelos práticos de UX e UI

Material complementar para consulta. Adapte as verificações à solução, sem criar formulários paralelos. O líder técnico e a equipe levantam a necessidade e iniciam o PRD; quando necessário, acionam UX/UI. A validação pendente não é aprovação.

Onde registrar

• Necessidade, perfis, fluxos, regras, estados e critérios de aceite: modelo de PRD.
• Protótipo, versão, pessoas, decisões e evidências: modelo de validação de telas.
• Conferência da entrega e diferenças: modelo de conferência.
• Alterações, ressalvas e histórico: issues e artefatos versionados vinculados ao PRD; não crie registro paralelo da mesma decisão.

A avaliação de UX/UI não substitui homologação técnica, análise de segurança nem aceite institucional. Os padrões oficiais de identidade visual e orientações internas do TJES devem ser incorporados quando recebidos.

Avaliação heurística

Consulte por fluxo ou conjunto de telas, no protótipo e na implementação; registre na issue as verificações e evidências pertinentes, sem duplicar formulários. Marque A = atende; P = atende parcialmente; N = não atende; NA = não aplicável; NV = não verificado. Para P ou N, registre evidência, impacto, prioridade, responsável e prazo; para NV, indique a próxima verificação. Exemplos são ilustrativos e devem ser ajustados à solução.

1. Visibilidade do estado: [A/P/N/NA/NV] A tela informa o que está acontecendo, o progresso e o resultado das ações? Ex.: ao consultar, exibe carregamento; ao concluir, mostra resultado ou erro. Evidência/pendência: [ ].

2. Correspondência com o mundo real: [A/P/N/NA/NV] Usa termos, sequência e informações familiares ao público? Ex.: apresentar o saldo de medição com termos confirmados pela Engenharia. Evidência/pendência: [ ].

3. Controle e liberdade: [A/P/N/NA/NV] A pessoa pode cancelar, voltar ou corrigir uma ação? Ex.: cancelar alteração antes da confirmação, quando aplicável. Evidência/pendência: [ ].

4. Consistência e padrões: [A/P/N/NA/NV] Ações iguais se comportam da mesma forma e respeitam os padrões acordados? Ex.: botões de mesma finalidade mantêm nome e posição coerentes. Evidência/pendência: [ ].

5. Prevenção de erros: [A/P/N/NA/NV] Campos, restrições e avisos evitam erros antes de acontecer? Ex.: validar data e sinalizar ação de efeito relevante. Evidência/pendência: [ ].

6. Reconhecimento em vez de memorização: [A/P/N/NA/NV] As opções, informações e instruções necessárias estão visíveis no contexto? Ex.: manter o contrato identificado ao consultar medições. Evidência/pendência: [ ].

7. Flexibilidade e eficiência: [A/P/N/NA/NV] A interface atende iniciantes e pessoas experientes, sem passos desnecessários? Ex.: filtros e atalhos adequados à tarefa. Evidência/pendência: [ ].

8. Estética e simplicidade: [A/P/N/NA/NV] O conteúdo prioriza o que é necessário, sem distrações que escondam dados importantes? Ex.: apresentar pendências prioritárias com contexto suficiente. Evidência/pendência: [ ].

9. Reconhecimento e recuperação de erros: [A/P/N/NA/NV] A mensagem explica o problema e como agir, sem jargão? Ex.: informar falha na consulta e oferecer nova tentativa. Evidência/pendência: [ ].

10. Ajuda e documentação: [A/P/N/NA/NV] Há orientação acessível para tarefas difíceis, no lugar e momento apropriados? Ex.: explicar um campo ou oferecer acesso ao guia. Evidência/pendência: [ ].

Regras de Shneiderman: verificar consistência; atalhos para usuários frequentes; feedback; fechamento das ações; prevenção e tratamento de erros; possibilidade de desfazer; controle pelo usuário; e redução da carga de memória. Os itens acima cobrem essas regras de forma integrada; acrescente verificações específicas quando necessário.

Acessibilidade

Marque A/P/N/NA/NV e registre evidências, responsável e encaminhamento. Confirme com o TJES o padrão, versão e nível exigidos. Avaliações automáticas ajudam, mas não substituem testes manuais ou com usuários.

• [A/P/N/NA/NV] Teclado: todos os controles operáveis e ordem de foco lógica. Evidência: [ ].

• [A/P/N/NA/NV] Foco: posição visível em todos os estados relevantes. Evidência: [ ].

• [A/P/N/NA/NV] Contraste e zoom: legibilidade e identificação de controles nos temas e tamanhos aplicáveis. Evidência: [ ].

• [A/P/N/NA/NV] Semântica: nomes e funções acessíveis, rótulos associados a campos e cabeçalhos organizados. Evidência: [ ].

• [A/P/N/NA/NV] Leitor de tela: mensagens, erros e mudanças de estado comunicados quando aplicável. Evidência: [ ].

• [A/P/N/NA/NV] Informação: cor não é o único meio de transmitir estados; imagens informativas têm alternativa textual. Evidência: [ ].

• [A/P/N/NA/NV] Formulários: instruções, erros, correções e obrigatoriedade identificáveis. Evidência: [ ].

Exemplo de fluxo: piloto P19

O P19 usa os registros existentes como piloto. O levantamento e os mockups foram produzidos antes deste registro; não se deve simular que foram solicitados ou aprovados antes da data real. A issue de acompanhamento do piloto liga os PRDs às validações. As decisões reais devem ser registradas pelas pessoas responsáveis.

1. Levantamento e PRD inicial. O líder técnico e a equipe confrontam o PRD de medição com as fontes; distinguem regras informadas pela área, propostas e perguntas pendentes.
2. UX/UI. O líder compartilha o contexto com UX/UI. No piloto, os mockups já existem: apontar para a versão e os arquivos relacionados na validação de medição, sem refazer o trabalho.
3. Revisão interna. Líder, UX/UI e desenvolvedores podem conversar ou trabalhar de forma assíncrona. Registrar versão, participantes, data, achados e decisão na issue. A revisão do líder sobre o PRD fica no acompanhamento; não equivale ao aceite da área.
4. Ajustes e dúvidas. Vincular uma issue quando houver trabalho concreto. O ajuste das datas simuladas é um exemplo real de achado. A dúvida sobre saldo negativo está na tarefa de fechamento; aguarda resposta da Engenharia.
5. Validação com a área. O líder técnico e o desenvolvedor sênior conduzem a apresentação, com apoio de UX/UI. Registrar tarefas observadas, decisão e ressalvas; ausência de resposta não é aprovação.
6. Consolidação e entrega. Atualizar o PRD incrementalmente, vincular tarefas à versão validada e conferir a implementação com a equipe e a área.

Simulação fictícia de registros, apenas para ilustrar a escrita; não são decisões do P19:

• Revisão do PRD pelo líder: “Versão [commit], revisada em [data]: de acordo para seguir com ressalva sobre [dúvida]. Próximo passo: consultar a área.”
• Alinhamento de UX/UI: “Protótipo [link e versão] cobre [tarefa e perfis]; estados [lista]. Pontos a verificar: [lista].”
• Validação interna: “Participantes [nomes], data [data], versão [commit]. Resultado: ajustes necessários. Evidência: [link]. Ajuste acompanhado em [issue].”
• Validação com a área: “Responsável [nome], data [data], versão [commit], decisão [aprovado/com ressalvas/ajustes/pendente], evidência [link].”

Registre fatos e decisões verdadeiros nas issues e no PRD, sem copiar estes exemplos como aprovações. Adapte o nível de detalhe à solução e use os registros já existentes.