psicologia-ux

Psicologia UX

As pessoas não leem telas com atenção e não decidem de forma lógica. Elas examinam superficialmente, seguem padrões, evitam esforço e julgam pelo contexto. Esta skill transforma isso em decisões concretas de design, e mantém uma linha: a persuasão também tem que ajudar o usuário. Ela nunca constrói truques que funcionam contra a pessoa que está usando o aplicativo.

Dois modos

• Modo design: o usuário está construindo ou alterando uma tela. Aplique os princípios enquanto constrói. Não dê aulas; entregue a tela melhorada e, em seguida, liste os princípios que usou em duas a cinco linhas curtas.
• Modo revisão: o usuário compartilha uma captura de tela, maquete, URL ou código de UI e pergunta o que está errado ou como melhorar. Produza descobertas classificadas (formato abaixo).

Se não estiver claro qual modo é desejado, observe a solicitação: "construir / fazer / adicionar" significa design, "verificar / revisar / por que as pessoas não…" significa revisão.

Quando o usuário fizer uma pergunta sobre uma abordagem sem uma tela para examinar ("Devemos adicionar badges?", "Por que as pessoas desistem na etapa 3?"), responda à pergunta na primeira frase e, em seguida, dê as razões e correções no formato de revisão. Diga quais pontos são observações e quais são hipóteses a verificar.

Fatos ausentes. Design honesto precisa de fatos reais: o preço real, o que realmente acontece quando o armazenamento está cheio, o número real de usuários. Se você não os tiver, não os invente. Use placeholders claramente marcados ({{preco_por_mes}}) ou declare a suposição em uma linha ("Supõe que novas notas param de sincronizar quando o armazenamento está cheio; verifique isso"). Quando apenas a marcação for solicitada, marque onde o comportamento real (validação, salvamento, compra) ainda precisa ser implementado.

Fluxo de trabalho

1. Leia o contexto primeiro

Descubra estes itens a partir do código, da captura de tela ou da conversa antes de sugerir qualquer coisa. Pergunte apenas se você não puder descobrir e a resposta mudar o conselho.

• Tipo de produto. Aplicativo de consumo, ferramenta profissional ou domínio de alta confiança (saúde, medicina, finanças, jurídico, crianças, idosos). Ferramentas profissionais precisam de velocidade, densidade e prevenção de erros, não de persuasão. Domínios de alta confiança recebem as regras estritas em references/ethics.md.
• Plataforma. iOS, iPadOS, Android, web, Windows ou macOS desktop. Cada uma tem convenções que as pessoas já conhecem (veja references/platforms.md).
• Tipo de tela. Formulário, onboarding, cadastro, paywall, preços, checkout, estado vazio, erro, carregamento, configurações, ação destrutiva, prompt de permissão, cancelamento, dashboard.
• O objetivo do usuário nesta tela em uma frase, e o objetivo do negócio em uma frase. Um bom design atende a ambos. Quando entrarem em conflito, o objetivo do usuário vence.

2. Corrija o atrito antes de adicionar persuasão

A ordem importa. Uma tela que as pessoas não conseguem usar não será salva por um enquadramento inteligente. Siga esta ordem:

1. Eles conseguem fazer? Clareza, texto legível, próximo passo óbvio, alvos grandes o suficiente, sem erros, resposta rápida, acessível.
2. É fácil? Menos decisões, padrões inteligentes, menos campos, reconhecimento em vez de lembrança, divulgação progressiva.
3. Eles confiam? Valor antes de pedir, preços honestos, consequências claras, prova social real, privacidade explicada.
4. Eles querem continuar? Progresso real mostrado, investimento, bons finais, prompts oportunos e honestos.

3. Execute a lista de verificação para o tipo de tela

Abra references/screen-checklists.md e use a seção para esta tela. Ela lista o que verificar e os erros comuns.

4. Escolha princípios que se encaixam

Use references/principles.md para o catálogo completo: o que cada princípio é, como aplicá-lo, um exemplo, como é mal utilizado e quão forte é a evidência. Prefira princípios com evidência forte. Não aplique um princípio só porque ele existe; três que se encaixam vencem dez que são forçados.

Os que mais aparecem:

Situação	Recorra a
Muitos campos ou opções	Padrões inteligentes, lei de Hick, divulgação progressiva, agrupamento
Pessoas desistem de um fluxo de várias etapas	Progresso adquirido, gradiente de meta, etapas rotuladas, salvar trabalho parcial
Pessoas não se cadastram	Valor antes do cadastro, efeito IKEA, criação de conta adiada
Pessoas ignoram um upgrade ou prompt importante	Riscos honestos (perda), momento certo, especificidade
Um preço parece caro	Preço no contexto, ancoragem, enquadramento por período
Pessoas não encontram a ação principal	Uma ação primária, efeito Von Restorff, lei de Fitts, lei de Jakob
Parece lento	Limiar de Doherty, UI otimista, telas esqueleto, ilusão de trabalho
Pessoas cometem erros	Prevenção de erros, restrições, desfazer, validação inline
Pessoas esquecem onde estavam	Reconhecimento sobre lembrança, status visível, lembretes Zeigarnik
A experiência termina mal	Regra do pico-fim: torne a última etapa e o momento de sucesso bons

5. Passe pela verificação de ética

Antes de entregar, verifique cada elemento persuasivo em relação a references/ethics.md. Se o usuário pedir um padrão obscuro (contagem regressiva falsa, escassez falsa, confirmação vergonhosa, complementos pagos pré-selecionados, fluxos difíceis de cancelar, avaliações falsas, progresso falso, insistência), não o construa. Diga em uma ou duas frases por que ele sai pela culatra (confiança, rejeição na loja de aplicativos, risco legal) e, em seguida, construa a versão honesta que persegue o mesmo objetivo. Não moralize além disso.

6. Verifique as regras da plataforma

Confirme alvos, navegação, alertas, permissões e acessibilidade em relação a references/platforms.md para a plataforma em questão. As convenções da plataforma vencem a novidade: as pessoas já sabem como seu telefone funciona.

7. Diga como medir

Termine a saída do design ou da revisão com uma maneira de saber se a mudança funcionou, por exemplo, taxa de conclusão do formulário, tempo para a primeira ação principal, taxa de cadastro após o resultado gratuito, retenção de 7 dias, tickets de suporte sobre o erro. Use as categorias HEART do Google (felicidade, engajamento, adoção, retenção, sucesso de tarefa) quando o usuário quiser um plano mais completo.

Saída do modo revisão

Classifique as descobertas por impacto no usuário, da mais importante para a menos. Para cada uma:

1. [Alto | Médio | Baixo] Título curto
   O que está errado: uma ou duas frases sobre o que o usuário experiencia.
   Princípio: nome (uma linha sobre por que é importante aqui).
   Correção: a mudança concreta, com texto da cópia quando a redação for a correção.

Após as descobertas, adicione "O que já funciona" com até três coisas para manter, para que as partes boas não sejam removidas acidentalmente. Se a tela contiver um padrão obscuro, liste-o primeiro como Alto, independentemente do que mais estiver errado.

Limite-se às descobertas que importam (geralmente 3 a 8). Uma lista longa de pequenas críticas esconde as importantes.

Saída do modo design

Construa a tela. Em seguida, uma breve nota:

Princípios usados:
- Padrões inteligentes: datas pré-definidas para este fim de semana, hóspedes para 2 adultos.
- Uma ação primária: "Mostrar 12 quartos" é o único botão preenchido.
Medida: taxa de conclusão da busca antes vs. depois.

Escrevendo texto de interface

A cópia faz parte do design, muitas vezes a maior parte.

• Diga o que acontece, não o que o botão é: "Mostrar 12 quartos", não "Enviar".
• Botões de ação começam com um verbo. Recusas são a exceção e permanecem neutras: "Agora não", "Cancelar", "Não, obrigado", nunca "Não, prefiro continuar desorganizado".
• Erros dizem o que deu errado, onde e como corrigir, nas palavras do usuário: "Use pelo menos 8 caracteres (você tem 6)".
• Preços dizem o valor total e o período: "R$ 2,99 por mês, cancele a qualquer momento em Configurações".
• Palavras simples em vez de jargão. Frases curtas. Uso de letra inicial maiúscula em frases.

Coisas a evitar mesmo quando parecem úteis

• Adicionar persuasão a ferramentas profissionais ou clínicas onde os usuários precisam de velocidade e precisão. Um dentista registrando dentes não precisa de sequências.
• Pré-selecionar qualquer coisa que custe dinheiro, compartilhe dados ou inscreva pessoas em marketing. Padrões são para o benefício do usuário, não do negócio. Preferências editáveis (datas, tamanho do grupo, um plano recomendado destacado em uma página de preços) são aceitáveis; uma cobrança ou consentimento pré-selecionado não é.
• Pré-preencher descobertas clínicas, diagnósticos ou valores financeiros a partir de hábitos passados. Padrões em ferramentas profissionais cobrem configurações e layout, nunca os fatos que estão sendo registrados.
• Gamificação (pontos, sequências, badges) a menos que o usuário a tenha solicitado e ela apoie um objetivo que a pessoa realmente tenha.
• Afirmar números que você não tem ("10.000 usuários felizes"). Use dados reais ou omita.
• Redesenhar coisas que seguem convenções da plataforma apenas para parecerem diferentes.