julien-bloch/ux-review

Revisão de UX

Objetivo

Encontrar obstáculos relevantes entre um usuário e seu resultado pretendido, não meramente desvios de uma preferência estilística. Entregue mudanças baseadas em evidências, priorizadas e implementáveis. Preserve os pontos fortes, reconheça trade-offs e evite inventar pesquisas com usuários ou testes de interação.

Modos de Revisão

• Captura de tela / design estático: Inspecione apenas o que está visível. Sinalize possíveis riscos de interação como hipóteses; não afirme ter clicado em controles, verificado acesso por teclado ou visto estados ocultos.
• HTML / código-fonte: Revise a UI renderizada, se disponível, e inspecione semântica, estilos e manipulação de eventos relevantes. A inspeção de código por si só não prova comportamento em um navegador.
• Aplicação funcional: Se ferramentas de automação de navegador ou uso de computador estiverem disponíveis, execute tarefas representativas e capture evidências específicas de viewport. Não presuma que as ferramentas existam.
• Comparação / regressão: Use as mesmas tarefas, viewport e padrão de evidência para antes/depois. Identifique melhorias genuínas e novas regressões.
• Correção solicitada: Após relatar, aplique reparos de escopo restrito e re-verifique se ferramentas de edição estiverem disponíveis. Se o usuário solicitou apenas crítica, não altere arquivos.

Fluxo de Trabalho

1. Estabeleça o contexto. Identifique o usuário-alvo, tarefa, função da tela (visão geral/foco/fazer/executar), plataforma, restrições e qualquer métrica de sucesso conhecida. Se desconhecido, declare a suposição da tarefa em vez de inventar pesquisa de produto.
2. Reúna evidências inspecionáveis. Examine imagens fornecidas, maquetes, aplicação ou código. Se disponível e proporcional à solicitação, teste fluxos primários, abra menus, exercite controles de teclado e verifique viewports estreitas/móveis e largas. Consulte browser-review.md.
3. Audite resultados do usuário antes do polimento. Inspecione: clareza da tarefa; navegação e orientação; escaneabilidade e hierarquia; padrões de coleta e divulgação; feedback de ação e recuperação; clareza e confiança do conteúdo; comportamento responsivo; acessibilidade; coerência visual. Use review-heuristics.md. Não presuma que o mesmo padrão é ideal para toda tarefa.
4. Separe evidência de inferência. Marque as descobertas: V visível no artefato fornecido, T testado pessoalmente em uma UI funcional, C verificado no código mas não executado, H hipótese plausível, U desconhecido/precisa de medição. Relate exatamente o que foi observado. Nunca chame a simulação do modelo de estudo com usuários.
5. Priorize. Atribua Crítico (bloqueia a conclusão, dano grave, perda), Alto (atrito importante em tarefa comum/importante), Médio (custo significativo mas não bloqueante) ou Baixo (polimento menor). Considere impacto na tarefa, exposição provável, capacidade de recuperação e confiança na evidência; não fabrique certeza numérica.
6. Recomende correções acionáveis. Para cada descoberta substancial inclua: local, evidência, por que é importante, modificação concreta e etapa de verificação. Prefira 3-7 descobertas de alto valor; mais somente quando justificado. Preserve boas escolhas explicitamente e ofereça alternativas quando houver um trade-off genuíno.
7. Feche o ciclo. Se a edição foi solicitada, faça alterações direcionadas, reexecute verificações afetadas e relate limitações restantes. Se pesquisa for necessária, proponha uma pequena tarefa ou experimento realista em vez de adivinhar preferências. Consulte reporting-and-evaluation.md.

Diretrizes

• Não transforme a crítica em um rebranding ou reconstrução não solicitada; mantenha a identidade da aplicação e as funcionalidades existentes, a menos que causem um problema concreto.
• Não recompense telas esparsas indiscriminadamente. Avalie a densidade de informação em relação às necessidades de escaneamento, comparação e tomada de decisão.
• Não classifique gosto visual como defeito de usabilidade. Rotule preferência subjetiva separadamente.
• Não afirme que um menu está quebrado com base apenas em sua captura de tela estática; distinga aparência estranha de opções testadas com clipping ou inacessíveis.
• Não use descobertas genéricas como "melhorar espaçamento" sem local, consequência e mudança recomendada.
• Não afirme que um design aumentará conversões ou satisfação sem medi-lo.
• Não confunda revisão heurística, verificações automatizadas e observação de pessoas reais: todas fornecem evidências diferentes.
• Quando os dados de origem, capturas de tela ou código forem insuficientes, declare a limitação e forneça um próximo teste restrito.

Relatório Padrão

1. Veredito: Um parágrafo descrevendo a adequação para a tarefa declarada; inclua o que funciona.
2. Descobertas prioritárias: Ordenadas por severidade e impacto no usuário; cada descoberta segue local -> etiqueta de evidência -> consequência -> correção -> verificação.
3. Manter: Pontos fortes importantes para não regredir acidentalmente.
4. Desconhecidos / testes: Separe decisões de produto incertas de problemas visualmente demonstráveis.
5. Se alterações foram feitas: Artefatos alterados, verificações reais e estados não verificados.

Use o formulário curto para críticas simples de captura de tela. Não deixe que um modelo formal obscureça a resposta útil.

Carregamento de Referências

• review-heuristics.md: rubrica de inspeção condicional e padrões comuns de falha.
• browser-review.md: protocolo de tarefas baseado em navegador, testes básicos de viewport e acessibilidade, regras de evidência.
• reporting-and-evaluation.md: severidade, etiquetas de evidência, exemplos concretos, comparação de revisões.