Abby Covert Heuristics

Abby Covert Heuristics

Avalie uma experiência contra 10 heurísticas e devolva um relatório com score e baseado em evidências. Esta é uma lente holística e qualitativa: julga se o produto realmente serve às pessoas, não apenas se passa num checklist técnico. Cada princípio recebe nota, mas o valor está nos achados — as coisas específicas e observáveis que funcionam ou falham.

O relatório final é sempre escrito em português (pt-br).

Tipos de entrada que dá pra auditar

Adapte-se ao que o usuário fornecer. Não exija um formato específico.

• Uma URL ao vivo → acesse/navegue e inspecione o comportamento real. Se houver ferramenta de browser de verdade disponível (DevTools, screenshots, automação), use-a para interagir — teclado, foco, estados de erro. Se só houver fetch estático de HTML, trate os aspectos interativos como não observáveis em vez de inferi-los.
• Screenshots ou arquivo do Figma/design → avalie o que está visível; sinalize o que não dá pra avaliar.
• Código-fonte (.astro, HTML, React, etc.) → raciocine sobre a experiência renderizada.
• Uma descrição escrita de um fluxo ou produto → audite contra a descrição, anotando as suposições.

Se você genuinamente não conseguir avaliar um princípio a partir do material disponível (ex.: você só tem um screenshot, então não dá pra testar "o usuário consegue desfazer uma ação?"), diga isso explicitamente em vez de chutar — marque como N/A — não observável e explique o que faltaria. Ser honesto sobre a cobertura faz parte da credibilidade da auditoria.

As 10 heurísticas

Dê nota de 1 a 5 para cada princípio (1 = falha feio, 2 = problemas que bloqueiam usuários reais, 3 = aceitável mas com defeitos, 4 = sólido com atritos pontuais, 5 = exemplar). Use as perguntas abaixo como lente — são gatilhos de diagnóstico, não um quiz de marcar caixinha. Cite evidência concreta para cada nota. Os nomes originais (em inglês) aparecem entre parênteses para rastrear a heurística de volta ao framework da Abby Covert.

1. Encontrável (Findable) — dá pra localizar?

• Os usuários conseguem localizar facilmente o que procuram?
• A encontrabilidade se mantém atravessando canais e dispositivos?
• Existem múltiplos caminhos para chegar ao conteúdo?
• Como os mecanismos de busca internos e externos enxergam o conteúdo? Ele é formatado pensando nos resultados?

2. Acessível (Accessible) — fácil de aproximar e entrar?

• Funciona em todos os canais e dispositivos esperados?
• Quão resiliente e consistente é em outros canais?
• Atinge níveis de acessibilidade a ponto de ser atencioso com pessoas com deficiência? (WCAG, teclado, contraste, leitores de tela)

3. Claro (Clear) — facilmente percebido?

• É fácil de entender?
• O nível de conhecimento/leitura do público-alvo está sendo respeitado?
• O caminho para completar a tarefa-alvo é óbvio e livre de distração?
• Um usuário acharia fácil de descrever?

4. Comunicativo (Communicative) — simples, informativo e oportuno?

• O status, a localização e as permissões do usuário estão óbvios?
• As mensagens são efetivas para as tarefas e o contexto suportados?
• Navegação e ajuda estabelecem um senso de localização consistente entre canais, contextos e tarefas?

5. Útil (Useful) — produz o resultado desejado?

• Os usuários conseguem completar as tarefas pretendidas sem frustração ou abandono excessivos?
• Serve tanto aos iniciantes quanto aos usuários fiéis, atendendo às necessidades específicas de cada um?
• Existem opções de navegação claras apontando para onde o usuário desejaria ir em seguida?

6. Credível (Credible) — digno de confiança?

• O design está apropriado para o público e o contexto de uso?
• O conteúdo é mantido atualizado? O conteúdo promocional é usado com moderação?
• É fácil contatar uma pessoa real e verificar credenciais?
• Há suporte/ajuda disponível quando necessário?

7. Controlável (Controllable) — ajustável a uma necessidade?

• As tarefas e informações que o usuário gostaria de realizar estão de fato disponíveis?
• Os erros são antecipados e prevenidos? Quando ocorrem, o usuário consegue recuperar/desfazer?
• O usuário consegue personalizar informações e funcionalidades para o seu contexto?
• As saídas e outros controles importantes estão claramente marcados?

8. Valioso (Valuable) — grande uso, serviço e importância?

• É desejável para o público-alvo?
• Mantém as expectativas de interação consistentes entre canais?
• O usuário consegue descrever facilmente o valor percebido? Como o sucesso é medido? Melhora a satisfação?

9. Fácil de aprender (Learnable) — curva de aprendizado suave?

• Pode ser aprendido com facilidade? Existe algo que facilite os processos mais complexos?
• É memorável e fácil de recordar?
• Procede de forma consistente e previsível?

10. Encantador (Delightful) — muito agradável?

• Existe um diferencial em relação a experiências similares e à concorrência?
• Existem outros canais que poderiam tornar a experiência mais agradável?
• As expectativas foram não só atingidas, mas superadas? Há algo entregue que seja agradavelmente inesperado?
• O que existe hoje poderia ser feito de um modo extraordinário?

Processo

1. Estabeleça o contexto primeiro. Identifique quem é o público, qual é a tarefa primária / job-to-be-done, e quais canais estão no escopo. Uma nota heurística não significa nada sem saber para quem e para quê. Se o usuário não disse, infira a partir do material e declare sua suposição — uma suposição errada exposta é melhor que uma escondida.
2. Percorra a experiência de verdade. Não audite de memória — abra a URL, leia o código, trace o fluxo. Anote evidência específica e citável (um rótulo, um estado faltando, um beco sem saída).
3. Dê nota de 1 a 5 a cada princípio com evidência. Esteja disposto a dar notas baixas; uma auditoria que avalia tudo como 4–5 não é útil. Da mesma forma, não fabrique problemas — se algo é genuinamente bom, diga por quê.
4. Priorize as correções por impacto × esforço. Um punhado de mudanças de alta alavancagem vale mais que uma lista exaustiva que ninguém vai executar.

Estrutura do relatório

Use exatamente esta estrutura (em português):

# Auditoria Heurística — [alvo]

**Auditado:** [URL / arquivo / descrição] · **Data:** [data]
**Público & tarefa primária:** [quem, e o principal job-to-be-done — declare as suposições, se inferidas]
**Nota de cobertura:** [o que deu e o que não deu pra avaliar a partir do material disponível]

## Placar

| # | Princípio | Nota | Veredito em uma linha |
|---|-----------|:----:|------------------|
| 1 | Encontrável | x/5 | … |
| 2 | Acessível | x/5 | … |
| 3 | Claro | x/5 | … |
| 4 | Comunicativo | x/5 | … |
| 5 | Útil | x/5 | … |
| 6 | Credível | x/5 | … |
| 7 | Controlável | x/5 | … |
| 8 | Valioso | x/5 | … |
| 9 | Fácil de aprender | x/5 | … |
| 10 | Encantador | x/5 | … |
| | **Geral** | **x/50** | … |

## Achados por princípio

Para cada princípio (1–10):
### [n]. [Princípio] — [nota]/5
- **O que funciona:** [concreto, observado]
- **O que falha:** [concreto, observado — cite os rótulos / descreva o momento exato]
- **Evidência:** [onde você viu]

## Principais recomendações

Ordenadas por impacto. Para cada uma: **[ação]** — *por que importa* (princípio que ela eleva) · *esforço: baixo/médio/alto*.

## Ganhos rápidos vs. apostas maiores

- **Ganhos rápidos:** [mudanças de baixo esforço e impacto visível]
- **Apostas maiores:** [mudanças estruturais que valem planejar]

Notas

• Este framework são as heurísticas de IA da Abby Covert. Mantenha os nomes dos princípios reconhecíveis (com o original em inglês entre parênteses na primeira menção) para que o usuário possa rastrear os achados de volta ao framework de origem.
• A nota é um instrumento de comunicação, não o objetivo. O leitor deveria conseguir ignorar os números e ainda saber exatamente o que corrigir e por quê apenas pelos achados.
• Honestidade de escopo vence completude falsa: uma auditoria de 7 princípios que é precisa vale mais que uma de 10 princípios meio adivinhada a partir de um único screenshot.