Crítica de Design de Produto

Uma passagem de crítica estruturada para uma tela, fluxo ou componente. O resultado é uma lista priorizada de mudanças que um designer ou engenheiro pode executar — não adjetivos. Crítica não é redesenho; recomende, não reconstrua.

Quando usar

• Um designer ou engenheiro pede feedback sobre uma tela, mock ou UI ao vivo.
• Um recurso está sendo lançado e alguém quer uma leitura final de UX.
• Suspeita-se que um fluxo esteja causando abandono de usuários e você quer uma leitura pré-pesquisa antes da instrumentação.

Quando não usar

• O usuário quer um redesenho. Isso é um projeto de design, não uma crítica.
• O trabalho está tão no início que nenhum artefato concreto existe. Desenhe com eles em vez de criticar o ar.
• Você não tem contexto sobre o trabalho do usuário. Peça primeiro; a crítica de design sem contexto do usuário se transforma em gosto.

Contexto pré-crítica

Antes de abrir uma tela, obtenha:

• Quem é o usuário. Cargo e competência específicos, não "usuários".
• Qual trabalho ele está fazendo nesta tela. Uma frase.
• O que o sucesso parece. O que o usuário pode fazer depois desta tela que não podia antes.
• Onde esta tela se encaixa no fluxo maior. O que precede e segue.

Se algo estiver faltando, pergunte. Crítica sem esses elementos é opinião.

A passagem (em ordem)

1. Clareza do trabalho do usuário.

   • Em até 3 segundos após a abertura, fica óbvio para que serve esta tela?
   • A ação principal corresponde ao trabalho real do usuário ou a um caminho preferido do designer?

2. Hierarquia visual.

   • A coisa mais importante na tela deve ser a mais proeminente (tamanho, peso, posição, cor).
   • Ações secundárias devem parecer secundárias. Terciárias devem ser encontráveis, mas não chamativas.
   • Títulos devem agrupar o conteúdo em grupos corretos para a tarefa.

3. Acessibilidade e sinalizadores.

   • Coisas clicáveis parecem clicáveis.
   • Coisas desabilitadas parecem desabilitadas e explicam o porquê ao passar o mouse/focar.
   • Interações de arrastar, rolar ou deslizar são descobertas, não escondidas.

4. Estados.

   • Estado vazio (sem dados) é projetado, não um retângulo em branco.
   • Estado de carregamento comunica progresso, não apenas gira.
   • Estados de erro dizem o que deu errado e o que fazer a seguir, nas palavras do usuário.
   • Estado de sucesso confirma sem celebrar ações banais.

5. Entradas e formulários.

   • Rótulos visíveis, não apenas placeholders.
   • Validação ocorre no momento certo (ao sair do campo, não a cada tecla digitada, a menos que o usuário esteja em um campo de formato conhecido).
   • Campos obrigatórios marcados.
   • A ordem dos campos corresponde à ordem mental do usuário, não à ordem do banco de dados.

6. Acessibilidade.

   • Contraste de cores suficiente (WCAG AA no mínimo; AAA onde razoável).
   • A ordem de foco é lógica para navegação por teclado.
   • Elementos interativos são alcançáveis sem mouse.
   • Informações críticas não são apenas de cor (ícones, texto, posição as suportam).
   • Alvos de toque com pelo menos 44×44 px no celular.

7. Consistência.

   • Tokens, componentes e padrões correspondem ao restante do produto.
   • Padrões "emprestados" de outros produtos são intencionais, não desvios acidentais.

8. Texto.

   • Botões são verbos que nomeiam o resultado ("Salvar alterações" é melhor que "Enviar").
   • Microcopy explica, não decora.
   • O tom corresponde à voz do produto.

9. Casos extremos.

   • Conteúdo longo (nomes longos, muitos itens, idiomas RTL).
   • Conteúdo pequeno (um item, zero itens).
   • Rede lenta e comportamento offline.
   • Permissões negadas.

Formato de saída

Agrupe as descobertas por gravidade, depois por categoria. Cada descoberta é um problema e uma correção sugerida.

## Design critique: <screen name>

### Must-fix (blocks ship)
- **<category>:** <one-line issue>. **Try:** <one-line suggestion>.

### Should-fix (before broader rollout)
- **<category>:** <one-line issue>. **Try:** <one-line suggestion>.

### Nice-to-fix (when there's room)
- **<category>:** <one-line issue>. **Try:** <one-line suggestion>.

### Strengths to keep
- <one-line thing the design got right>

Sempre inclua a seção "pontos fortes a manter". Não é bajulação — é um sinal para o designer sobre o que não mudar na próxima rodada.

Antí-padrões

• "Eu faria diferente" sem dizer o quê ou por quê. Isso é preferência, não crítica.
• Críticas longas que enterram itens de correção obrigatória sob itens "legais de ter".
• Sugerir recursos totalmente novos sob o disfarce de uma crítica.
• Ignorar o contexto do usuário e julgar pelo gosto.
• Tratar uma crítica como aprovação. Declare a aprovação explicitamente se solicitado; caso contrário, a crítica é feedback, não um "ok".