UX de produto focada em tarefas
Comece com a situação do usuário e o resultado pretendido. Sistemas de design existentes, pesquisas e designs fornecidos são evidências; não os substitua por um painel genérico. Leia padrões e contrapontos para o tipo relevante de tarefa, não todos os padrões.
Antes de construir uma tela
Para cada função/tarefa principal, identifique o gatilho, as informações já conhecidas, as decisões a serem tomadas, o resultado da conclusão e o caminho de recuperação. Separe fluxos específicos de função quando suas decisões diferirem; compartilhe telas quando a tarefa e o contexto realmente coincidirem.
Produza um fluxo compacto e um layout de baixa fidelidade proporcionais à mudança. Para cada estado de região visível:
- Qual decisão ou ação do usuário precisa disso agora?
- É primário, detalhe contextual ou desnecessário nesta visualização?
- Qual requisito, fonte ou decisão de design explícita justifica isso?
Use isso para selecionar informações, não para gerar mais texto de produto. Não adicione automaticamente cartões de visão geral, gráficos, banners, filtros, navegação, explicações de IA ou painéis "em breve". Uma métrica pertence quando alguém toma uma decisão relevante com ela. A proveniência técnica pode pertencer quando necessária para julgar atualidade ou validade; registros de depuração e status de implementação geralmente pertencem a registros de desenvolvimento.
Não minimize cegamente. Mantenha instruções de acessibilidade, erros significativos, contexto essencial, divulgações obrigatórias e consequências de decisões. Uma ação primária é um padrão útil, não um limite arbitrário de um botão. Evite ocultar ações importantes atrás de menus genéricos apenas para reduzir controles visíveis.
Estado e interação
Modele estados relevantes: inicial, carregamento, vazio, falha, sucesso, edição/não salvo, resultado desatualizado e restrições de permissão. Use apenas estados que o produto precisa. Faça com que as entradas selecionadas e os resultados exibidos se refiram ao mesmo contexto. Preserve o trabalho do usuário em erros recuperáveis. Escolha ações explícitas onde mudanças silenciosas surpreenderiam o usuário.
Ao selecionar uma superfície de edição ou alterar layouts com estado, leia seleção de padrão de interação. Escolha edição inline, um diálogo ou uma página dedicada com base na complexidade da tarefa, frequência, necessidades de contexto e espaço disponível; não use um modal apenas para ocultar um bug de layout. Verifique a posição antes/depois, rolagem e foco de controles significativos. A divulgação intencional pode mover conteúdo; saltos incidentais ou alvos que desaparecem precisam de correção.
Use os tokens, componentes, idioma e convenções de acessibilidade do projeto. Inspecione uma referência fornecida por meio de uma ferramenta suportada disponível; a falta de um Figma MCP não é por si só motivo para parar. Nunca rotule um design não inspecionado como correspondente. Não introduza uma nova biblioteca de componentes apenas para uma pequena alteração.
Verifique nomes e descrições acessíveis em estados válidos/erro/recuperados, não apenas visibilidade visual e foco. Uma mensagem oculta ainda pode ser exposta quando referenciada por uma descrição acessível; conecte o texto de erro apenas quando o erro se aplicar.
Revise o fluxo renderizado
Use uma ferramenta de navegador ou aplicativo disponível para executar a tarefa a partir de seu ponto de entrada real. Inspecione a estrutura para rótulos e controles, e as capturas de tela renderizadas para hierarquia, recorte, espaçamento e estados visuais. Verificações automatizadas de acessibilidade ou DOM sozinhas não comprovam qualidade visual ou de usabilidade.
Para verificações responsivas, confirme as dimensões reais da viewport do navegador e inspecione a imagem capturada final. Recortar uma captura de tela, alterar a largura de um elemento ou verificar o estouro horizontal sozinho não é um teste de viewport equivalente. Se a ferramenta não puder definir ou verificar a viewport, marque essa cobertura como não verificada. Reconcilie a captura de tela com o resultado relatado: conteúdo ausente, quebra inutilizável ou ações invisíveis não podem ser chamados de aprovação visual apenas porque uma verificação de DOM foi aprovada.
Para cada constatação registre: reprodução → comportamento observado → impacto no usuário → menor correção útil → nova verificação. Rotule inferência separadamente de observação. Prefira remover, mover, consolidar ou melhorar padrões antes de adicionar explicações. Não repita uma revisão aprovada a menos que alterações ou preocupações restantes a justifiquem.
Se o acesso ao navegador não estiver disponível, revise evidências de código/layout e marque UX de tempo de execução como não verificada; continue o trabalho independente. Não fabrique capturas de tela, cliques ou validação de usuário. A revisão do desenvolvedor ou agente não é um estudo de usuário.