Leis de UX — Índice e Protocolo

O que Leis de UX — Índice e Protocolo faz?

Este arquivo seleciona o modo, determina quais das 30 leis se aplicam e define como elas são usadas em conjunto e como relatar os resultados. Cada lei reside em seu próprio arquivo sob references/, nomeado conforme as tabelas abaixo (fitts-law → references/fitts-law.md). Abra apenas os que você selecionar.

Se o usuário nomear uma lei específica ("revise este formulário de acordo com a Lei de Postel"), abra apenas aquela referência e use-a no modo solicitado. As revisões ainda seguem a seção 5 deste documento.

0. Arquivos e Ambiente

Este skill funciona em qualquer agente que possa ler arquivos. Não depende de ferramentas específicas.

• Caminhos em todos os arquivos deste skill, incluindo as referências, são relativos ao diretório que contém este SKILL.md. references/fitts-law.md sempre significa <diretório do skill>/references/fitts-law.md, mesmo quando aparece dentro de outro arquivo de referência.
• Se você não conseguir abrir os arquivos de referência (por exemplo, se este texto foi colado em um prompt sem sua pasta), informe isso e solicite os arquivos de lei de que precisa. Não execute verificações de memória: os IDs de verificação, severidades e tipos de evidência são definidos apenas nesses arquivos.
• A evidência depende do que você pode inspecionar. Se você não pode visualizar imagens, capturas de tela e maquetes não contam como evidência static para você; revise qualquer texto ou código que possuir e informe isso na linha de escopo. Se você não pode executar o artefato, interactive e runtime estão fora de escopo, a menos que o usuário forneça gravações ou medições.

1. Escolha o Modo

Modo	Quando usar	O que você produz
Aconselhar	Apenas uma meta, briefing, declaração de problema, item de roadmap ou conceito inicial existe.	Um breve briefing de direcionamento: as leis mais importantes aqui, os riscos que preveem, as perguntas que a equipe deve responder e as decisões a serem tomadas agora.
Construir	Um design ou implementação está em andamento e precisa de uma referência.	Orientação direcionada para o componente ou tela em questão, extraída do Modo 2 das leis relevantes, com valores concretos onde existirem.
Revisar	Um design finalizado, protótipo, conjunto de capturas de tela, URL ou diff de código está prestes a ser commitado.	Um relatório rigoroso de descobertas com severidades, evidências, correções e um veredito.

Se a solicitação não especificar, infira a partir da entrada: uma meta → Aconselhar; trabalho em andamento → Construir; um artefato finalizado → Revisar. Se ainda assim estiver incerto, faça uma pergunta.

2. Selecione as Leis

Não abra todas as 30 para cada tarefa. Selecione por situação e, em seguida, adicione aquelas cujos gatilhos correspondam ao que você vê.

Linha de base para qualquer revisão de UI (sempre execute): fitts-law, jakobs-law, cognitive-load, law-of-proximity, law-of-similarity, selective-attention, cognitive-bias. Adicione doherty-threshold sempre que o artefato for interativo.

Por situação:

Situação	Abrir
Formulários, entrada de dados, cadastro	postels-law, working-memory, chunking, law-of-proximity, parkinsons-law, goal-gradient-effect
Navegação, menus, arquitetura da informação	hicks-law, serial-position-effect, mental-model, jakobs-law, chunking, pareto-principle
Painéis, ferramentas densas em dados e para especialistas	cognitive-load, chunking, law-of-common-region, law-of-pragnanz, flow, pareto-principle
Visualização de dados e diagramas	law-of-pragnanz, law-of-uniform-connectedness, law-of-similarity, von-restorff-effect
Onboarding, primeira execução, ajuda	paradox-of-the-active-user, goal-gradient-effect, zeigarnik-effect, cognitive-load, mental-model
Preços, planos, catálogos, checkout	choice-overload, hicks-law, cognitive-bias, von-restorff-effect, serial-position-effect, peak-end-rule
Notificações, alertas, status	selective-attention, von-restorff-effect, flow, zeigarnik-effect
Mobile e toque	fitts-law, law-of-proximity, serial-position-effect, doherty-threshold
Performance, carregamento, trabalho assíncrono	doherty-threshold, goal-gradient-effect, peak-end-rule, flow
Redesigns e migrações	jakobs-law, mental-model, serial-position-effect, aesthetic-usability-effect
Automação, IA e recursos inteligentes	teslers-law, mental-model, cognitive-bias, doherty-threshold
Escopo, priorização, roadmap	pareto-principle, occams-razor, teslers-law, hicks-law
Design visual e trabalho em design system	aesthetic-usability-effect, law-of-similarity, law-of-proximity, law-of-common-region, law-of-pragnanz, von-restorff-effect
Erros, falhas e encerramentos	peak-end-rule, postels-law, selective-attention, mental-model

Siga as Leis relacionadas de cada lei aberta apenas quando uma descoberta ou pergunta realmente tocar nessa lei.

3. Protocolo de Aconselhamento

1. Reafirme a meta, os usuários e o contexto em duas ou três linhas. Se os usuários ou o contexto forem desconhecidos, informe — esse é o primeiro risco.
2. Selecione 3–6 leis da tabela. Mais de seis dilui o conselho.
3. Para cada uma, forneça um ou dois riscos que ela prevê para este projeto e a pergunta que a equipe deve responder. Use o Modo 1 da lei como fonte, mas torne-o específico.
4. Liste as decisões a serem tomadas agora (orçamentos, padrões, convenções, regras de ênfase, medição) e quem deve ser o responsável.
5. Sinalize tensões entre leis que exigirão uma escolha deliberada (veja a seção 6).

Mantenha aproximadamente uma página. O objetivo é direcionar, não pré-projetar.

4. Protocolo de Construção

1. Identifique o componente, tela ou fluxo que está sendo trabalhado.
2. Abra as leis correspondentes e use suas listas do Modo 2 como referência, citando valores concretos (tamanhos alvo, tempos, proporções de contraste, critérios WCAG).
3. Quando as orientações entrarem em conflito, informe e recomende uma resolução para este caso.
4. Não execute a revisão completa durante a construção; mencione um problema de nível de Revisão apenas se for provavelmente um Bloqueador.

5. Protocolo de Revisão (rigoroso)

As revisões existem para evitar problemas antes do commit. Regras de rigor:

• Evidência ou não passou. Uma verificação passa apenas com evidência positiva no artefato. Nunca presuma um estado, tamanho, tempo ou comportamento que você não pode ver.
• Não verificável significa NÃO VERIFICADO, não aprovado. Nomeie o que você precisaria (um estado de erro, uma medição, dados reais, um dispositivo, o código).
• O escopo é declarado, nunca implícito. Um veredito cobre apenas a evidência que você recebeu. Verificações que precisam de um tipo de evidência que você não recebeu são listadas como fora de escopo, para que uma revisão de captura de tela não seja interpretada como uma aprovação completa.
• Não amenize. Sem elogios, sem "no geral parece ótimo", sem reduzir a severidade devido a prazos ou esforço já despendido.
• Seja específico. Cada descoberta nomeia o local (tela, componente, elemento ou arquivo:linha), o que você observou e uma correção concreta.
• Um problema, uma descoberta. Se várias leis sinalizarem o mesmo problema, relate-o uma vez, liste todos os IDs de verificação e use a maior severidade.
• Relate leis limpas explicitamente. Liste quais leis foram aplicadas sem descobertas, para que a cobertura fique visível.

Passos:

1. Inventarie o que você recebeu (telas, estados, breakpoints, código) e o que está faltando, e defina o escopo da evidência: quais dos tipos de evidência abaixo você possui.
2. Selecione a linha de base mais as leis situacionais.
3. Execute cada verificação na tabela do Modo 3 de cada lei selecionada. Classifique cada verificação em uma das categorias:
   • verificada — passou ou produziu uma descoberta;
   • não verificada — seu tipo de evidência está no escopo, mas o estado, elemento ou medição necessários estão faltando (por exemplo, escopo static, mas nenhuma tela de estado de erro);
   • fora de escopo — nenhum de seus tipos de evidência está no escopo;
   • não aplicável — o artefato não tem nada com que a verificação se relacione (por exemplo, FIT-1 em uma ferramenta de desktop apenas com mouse). Dê o motivo em algumas palavras.
4. Mescle duplicatas, atribua severidade, escreva correções.
5. Dê o veredito, com seu escopo.

Tipos de Evidência

Cada verificação do Modo 3 tem uma coluna Evidência que nomeia os tipos de entrada que podem resolvê-la. Quando lista mais de um, qualquer um deles é suficiente.

Tipo	O que é	Exemplos de entrada
static	O que pode ser visto em imagens estáticas das telas e estados relevantes.	Capturas de tela, maquetes estáticas, arquivos de design com medidas, quadros de fluxo
interactive	O que só aparece quando você opera a coisa: teclado, foco, transições, tempo experimentado, o que acontece após uma ação.	Um protótipo clicável, uma build em execução, uma URL, uma gravação de tela
code	O que está no código-fonte ou na marcação: semântica, ARIA, autocomplete, áreas de toque, tokens e comportamento que o código-fonte fixa de forma inequívoca (o que um manipulador faz em caso de erro, se a entrada é mantida, para onde o foco vai).	Um diff, código-fonte do componente, DOM renderizado
runtime	Medições em hardware, redes e dados realistas.	Rastreamentos de performance, números de RUM ou lab
context	Fatos fora do artefato: dados de uso, pesquisa, registros de decisão, regras de negócio.	Analytics, resultados de pesquisa, um PRD ou ADR, uma declaração da equipe

Considere um tipo de evidência como dentro do escopo apenas se você realmente o tiver. Ser informado de que o código existe não coloca code no escopo.

Severidade

Severidade	Significado
Bloqueador	Impede ou engana em uma tarefa principal; arrisca perda de dados, danos financeiros, de segurança ou de proteção; falha em um critério WCAG 2.2 AA; ou é um padrão enganoso. Deve ser corrigido antes do commit.
Grave	Atrito significativo, design propenso a erros ou clara inconsistência com convenções ou com o design system. Corrija antes do commit ou registre aceitação explícita por um responsável nomeado com um acompanhamento.
Menor	Polimento e consistência. Corrija quando a área for tocada novamente.

Veredito

Aplique a primeira regra que corresponder:

1. Qualquer Bloqueador → Não commitar.
2. Qualquer verificação Bloqueador dentro do escopo está NÃO VERIFICADA → Bloqueado pendente de evidência. Nomeie o estado ou medição faltante, que a equipe poderia ter fornecido com a evidência já dada.
3. Qualquer Grave → Commite apenas com cada Grave corrigido ou aceito por um responsável nomeado.
4. Apenas Menor ou nenhum → Aprovado.

Todo veredito carrega seu escopo, por exemplo Aprovado (escopo static). Se alguma verificação Bloqueador estiver fora de escopo, liste-a na linha do veredito com o tipo de evidência de que cada uma precisa, por exemplo fora de escopo: JAK-1 (interactive), SA-2 (interactive), DOH-1 (interactive). Um veredito pode ser não qualificado (apenas "Aprovado") apenas quando nenhuma verificação Bloqueadora das leis selecionadas estiver fora de escopo ou não verificada. Verificações fora de escopo nunca alteram o veredito. Elas informam à equipe o que ainda não foi revisado e se é necessária uma segunda passagem com mais evidências antes do lançamento.

Modelo de Relatório

## Revisão de Leis de UX — <nome do artefato>

Revisado: <o que foi revisado: telas, estados, breakpoints, arquivos>
Escopo da evidência: <static | interactive | code | runtime | context — aqueles realmente fornecidos>
NÃO fornecido: <estados ou evidências faltantes>
Leis aplicadas: <códigos>
Veredito: <Não commitar | Bloqueado pendente de evidência | Commitar com Graves aceitos | Aprovado> (escopo <escopo>)
         fora de escopo: <IDs de verificação Bloqueador com o tipo de evidência que cada um precisa, ou "nenhum">

### Bloqueadores
- [BLOQUEADOR] FIT-1, JAK-1 · <local> — <observação> → <correção>

### Graves
- [GRAVE] CL-2 · <local> — <observação> → <correção>

### Menores
- [MENOR] SIM-6 · <local> — <observação> → <correção>

### Não verificado (no escopo, evidência faltante)
- POS-2 · <o que não pôde ser verificado> — precisa de <o estado ou medição específico>

### Fora de escopo
- interactive: JAK-1, SA-2, DOH-1, …
- code: CH-3, PKL-3, …

### Não aplicável
- FIT-1 — <motivo>

### Aplicado sem descobertas
<códigos>

6. Tensões Comuns

Tensão	Resolução padrão
Hick / Occam (menos opções) vs. cauda longa de Pareto e necessidades de especialistas	Mantenha funções críticas, mas raras, encontráveis por meio de divulgação progressiva; nunca as remova apenas com base no uso.
Occam (remover) vs. Tesler (complexidade irredutível)	Remova a complexidade incidental; mova a complexidade inerente para o sistema, com visibilidade e desfazer.
Jakob (convenção) vs. diferenciação	Inove no problema, não nos controles principais. Desvios precisam de um benefício declarado e testado.
Von Restorff (ênfase) vs. Similaridade (consistência)	Um elemento enfatizado por visualização; todo o resto consistente.
Fitts (alvos grandes e convenientes) vs. ativação acidental	Separe ações destrutivas; adicione desfazer ou confirmação para ações consequenciais.
Fluxo (sem interrupções) vs. confirmações de segurança	Interrompa apenas para ações consequenciais e irreversíveis.
Carga Cognitiva (mostrar menos) vs. Memória de Trabalho (mostrar contexto)	Mostre o contexto necessário para a etapa atual; esconda o resto.
Postel (aceitar liberalmente) vs. correção	Liberal no formato, rigoroso no significado; confirme valores ambíguos e consequenciais.
Gradiente de Meta, Efeito Zeigarnik, Posição Serial, Von Restorff como alavancas vs. interesse do usuário	Use apenas para resultados que o usuário deseja; veja cognitive-bias.

7. Todas as Leis

Percepção e Atenção

Lei	Código	Use para
aesthetic-usability-effect	AUE	polimento visual, primeiras impressões, expressão da marca, interpretação de testes de usabilidade e a lacuna entre como um produto parece e como funciona
law-of-common-region	CR	cartões, painéis, seções, bordas, preenchimentos de fundo, linhas de tabela, grupos de formulários e qualquer contêiner usado para sinalizar que itens pertencem uns aos outros
law-of-proximity	PRX	espaçamento, densidade do layout, associação rótulo-campo, agrupamento de controles e conteúdo e escalas de espaçamento
law-of-pragnanz	PRG	ícones, ilustrações, visualizações de dados, silhuetas de layout, logotipos e qualquer visual que deva ser compreendido rapidamente
selective-attention	SA	notificações, alertas, alterações de status, banners, dicas de onboarding, mensagens do sistema e posicionamento de informações que os usuários não devem perder
law-of-similarity	SIM	consistência visual, estilos de links e botões, variantes de componentes, cores de status, famílias de ícones e uso do design system
von-restorff-effect	VR	destaque de chamada para ação, informações críticas, etapas especiais em fluxos (pagamento, exclusão), ofertas de teste e qualquer item que precise se destacar

Memória e Aprendizado

Lei	Código	Use para
cognitive-load	CL	qualquer tela densa em informação para especialistas ou iniciantes; assistentes passos-a-passo, divulgação progressiva, dicas de contexto, validadores inline e decide se é mais barato tornar uma tarefa aprendível ou imediatamente clara
working-memory	WM	formulários, entrada de dados, checkout, passos de pesquisa, recuperação de rascunhos, preenchimento automático, comparação lado a lado e retenção de contexto entre telas
chunking	CH	formulários longos, dados em grupos, números grandes, cronogramas, listas, máscaras de entrada, acordeões e frascos de progresso
serial-position-effect	SP	menus, abas, etapas do assistente, listas, resultados de pesquisa, linhas de tabela, listas de reprodução, formulários e ordem de páginas
zeigarnik-effect	ZE	onboarding, tutoriais, rastreamento de progresso, indicadores de conclusão parcial, retenção de entrada não salva-antes-da-ação e gamificação
mental-model	MM	metáforas de design (carrinho, pasta), convenções de plataforma, padrões de atalhos, arquitetura da informação, filtros de pesquisa e terminologia
paradox-of-the-active-user	PAU	documentação inline, dicas de ferramentas, autodescoberta, configurações avançadas, pesquisa por comando e comportamento de pulo de tutorial

Tomada de Decisão e Viés

Lei	Código	Use para
cognitive-bias	CB	sinais de confiança (avaliações, contagens de usuários), padrões de redes sociais, prova social, escassez, ancoragem e efeito de doação — e o viés de confirmação em testes
choice-overload	CO	comparação de planos, configuração, filtragem, catálogos, sequências de onboarding e preferências vs. padrões
peak-end-rule	PER	checkout e pagamento, saldo de navegação para conteúdo, pós-onboarding, feedback de suporte, animações de conclusão e satisfação exibida vs. relatada
goal-gradient-effect	GG	barras de progresso, conclusão de perfil, programas de fidelidade, marcos de onboarding, rastreamento de metas e sinalização de conclusão parcial

Motor e Ação

Lei	Código	Use para
fitts-law	FIT	dimensões e posicionamento de botões, áreas de toque, alvos de foco, menus, sliders, links, ferramentas de desenho, teclados de tela e alvos móveis
hicks-law	HICK	comprimento de menus e listas, alinhamento de botões, gavetas de ação, complexidade da página inicial, itens por seção e guias vs. acordeões
doherty-threshold	DOH	estados e indicadores de carregamento, feedback de clique, tempo de resposta da UI, e otimização percebida vs. real — use com flow
law-of-uniform-connectedness	UC	transições, animações, encadeamento visual, setas de fluxo, diagramas Sankey, orientação de gráficos de pizza e atribuição de série temporal
flow	FLW	integridade da tarefa, etapas do checkout, interrupções (tos, erros, notificações), feedback em tempo real e entrada em modo imersivo

Complexidade e Priorização

Lei	Código	Use para
jakobs-law	JAK	patronos, navegação, atalhos de teclado, convenções de componentes, terminologia e metáforas que os usuários trazem de outras ferramentas
teslers-law	TES	configuração de automação, regras de negócio, recuperação de dados, preferências de usuário, potência vs. limites de interface e exposição de complexidade do sistema
parkinsons-law	PKL	formulários sem restrição de tempo, feedback em tempo real, verificação dupla, integridade de conclusão de página e adiamento de entrada
pareto-principle	PAR	wireframes vs. variantes de estado final, roteirização de recursos, análise de dados de log, testes A/B e escopo de coleta de dados
postels-law	POS	formatos de entrada (telefone, data, CEP), validação de e-mail, tratamento de erros, mensagens de erro e formatação de dados de saída
occams-razor	OR	debate de complexidade de visualização de dados, cortes de recursos, histoires de usuário, falsa simetria (mostrar o que não pode ser visto) e análise de tarefas

8. Marcadores de Arquivo e Ambiente

Os seguintes marcadores ajudam a personalizar o protocolo.

Marcador	Quando usado	Efeito
INLINE	O usuário colou as leis no prompt em vez do caminho da pasta.	Verifique se o texto de cada lei foi incluído; se não, cancele e peça que ele cole suas leis individuais também.
FULL CHECKLIST	O usuário solicita explicitamente a lista de verificação completa (por exemplo, "execute a verificação completa de Fitts").	Emita cada verificação individual, ignorando 'verificada sem descobertas'; use o modelo de relatório completo.
NO REPORT	O usuário solicita apenas conselho verbal, sem saída formatada.	Pule o modelo de relatório; forneça conselho em prosa.
html	A saída será visualizada em um navegador.	Saída em HTML, preserve a semântica e torne a formatação mais rica, mas não altere o conteúdo ou o rigor.
pdf	A saída será visualizada ou arquivada em PDF.	Como html, mas evite cores claras e links; escreva as URLs completas entre parênteses após o texto do link.

---

Protocolo e índices escritos por Mark Hougaard Jensen (@markhougaard). Leis mantidas em lawsofux.com.