Em uma frase: design bom desaparece; design ruim faz o usuário perguntar “por quê?”.
0. Resumo em cinco segundos
Num game de cartas competitivo, subir de ranking e não achar adversário numa tarde vazia é compreensível. O problema muda quando toda falha exige apertar Tentar novamente. Era para ser PvP, mas a primeira luta é contra a UI.
A regra: não me faça lutar fora da partida. Pessoas criam previsões sobre o que normalmente acontece e sobre como um sistema deveria funcionar se o objetivo declarado for real. Quando realidade e modelo divergem, aparece o “ué?”, “por quê?”, “tem algo estranho”.
Chamaremos isso de detecção de inconsistência estrutural, como rótulo prático, não termo psicológico oficial. Ele conecta prediction error, expectancy disconfirmation, processing fluency, Person–Environment Fit, Expectancy Violations Theory e intuição especializada.
Incômodo é alarme, não sentença sobre a causa.
1. A origem: o primeiro chefe era Tentar novamente
Ranking sobe → pouca gente → matchmaking falha → tentar novamente → falha → de novo. A UI não cria jogadores, mas pode continuar buscando ou tentar automaticamente.
A reclamação vira “por que eu sou o operador do matchmaking?”. O jogo deveria exigir decisões sobre cartas, tempo, risco e vitória, não oferecer um bico de Técnico de Reinício Manual.
Não transforme humanos em cron jobs. Eu abri um game, não uma vaga em Operações de UI.
2. O princípio: remova o PvE fora do objetivo
Não transforme atrito fora do objetivo em trabalho do usuário. Comprar e lutar com cadastro, reservar e lutar com disponibilidade, trabalhar e procurar aprovador, automatizar e depois vigiar a automação todo dia, conversar e fazer engenharia reversa de regras invisíveis: tudo é PvE fora do objetivo.
Ninguém quer a conquista “Formulário de checkout derrotado”. Serviço bom não cria inimigos extras.
3. Alta qualidade costuma parecer “nada demais”
Porta abre, pagamento termina, busca encontra, próximo passo é óbvio, está claro quem decide e a conversa flui. Fim. Avaliação: normal.
Pesquisa sobre processing fluency examina como facilidade de processamento se relaciona a simpatia, confiança e familiaridade. Pesquisa de serviços também mostra a importância da relação entre expectativa e experiência.
Sistema maduro fica transparente. Sistema imaturo se apresenta alto demais: clique aqui, volte, fale com outro departamento. Design ruim faz uma apresentação barulhenta; design bom reduz a própria presença.
4. Traduzindo “tem algo estranho” para pesquisa
Prediction error: uma meta-análise de 264 estudos de neuroimagem examinou erro de previsão em recompensa, punição, ação, cognição, percepção e inferência social. Versão comum: “Ué, agora acontece isso?”
Expectancy disconfirmation: meta-análise de 2024 reuniu 150 registros, 168 estudos independentes e 58.597 participantes. Não importa apenas desempenho; a distância entre expectativa e experiência também pesa.
Processing fluency: fácil de ler, achar, entender e prever. Não use o cérebro do cliente como CPU auxiliar gratuita.
Person–Environment Fit: ambiente excelente não serve para todo mundo. Sapato caro dói com tamanho errado.
Expectancy Violations Theory: comportamento fora da expectativa interpessoal chama atenção; uma surpresa positiva também pode ser violação.
5. Cinco inconsistências estruturais
- Objetivo–meio: querer velocidade e adicionar três aprovações.
- Responsabilidade–autoridade: “decida” e depois “por que decidiu sem permissão?”. Campo minado vendido como autonomia.
- Fala–comportamento: “valorizamos experimentação” e punir um erro por meses. Cartaz e operação parecem empresas diferentes.
- Avaliação–resultado: querer produtividade e premiar horas visíveis; querer qualidade e punir relato de defeitos. Pessoas otimizam como ganhar pontos.
- Humano–sistema: cliques repetidos, duplicação de dados, partida manual de automações, vigilância de “nada aconteceu”. Não transforme humanos em cron jobs.
6. Como o detector funciona
Entenda o objetivo → preveja estrutura razoável → observe a realidade → detecte a diferença → pergunte por quê → examine causas, critérios e responsabilidade → redesenhe.
Notar fricção não significa ser negativo. O efeito colateral é que, depois de perceber um passo inútil, você o vê para sempre. A pedrinha vira protagonista da caminhada. O mundo fica em UI Debug Mode.
7. Serviços: não transforme UI em boss fight
Procure redigitação, confirmações inúteis, recuperação manual de falhas previsíveis, formulários que apagam dados, ações principais obscuras, códigos de erro sem causa e perguntas sobre informações já conhecidas pelo sistema.
Microfricção repetida domina a experiência. Serviço maduro não pergunta só “o que adicionar?”, mas “o que o usuário pode parar de perceber?”
8. Ambientes: não remende instituições ruins com força de vontade humana
Se ninguém sabe quem decide, pergunta ao veterano; sem definição de pronto, lê o ambiente; sistemas não integram, Excel vira cola; agenda quebra, alguém vigia todo dia.
O trabalho terminar não prova que o sistema é bom. Talvez pessoas estejam corrigindo em tempo real um sistema defeituoso. Quanto melhor a equipe, mais um processo ruim pode sobreviver. Cooperação infernal.
9. Pessoas: incômodo não é telepatia
Contradições repetidas, regras que mudam e responsabilidade que sempre se move na mesma direção merecem observação. Mas observar inconsistência não prova má intenção.
Separe fatos, previsão, diferença, hipóteses alternativas e próxima verificação. Incômodo é detector de fumaça, não foto do incendiário.
10. Quando confiar na intuição especializada
Kahneman e Klein destacaram em 2009 a importância de regularidades que podem ser aprendidas e prática suficiente com feedback significativo. Regras sempre mudando, resultados quase impossíveis de verificar ou aleatoriedade alta não garantem boa intuição só por causa da experiência.
Registre também os palpites errados. Não faça um site de reviews da própria memória mostrando só cinco estrelas.
11. Transforme incômodo em melhoria
Escreva o objetivo → descreva o processo atual → ache a luta fora do objetivo → pergunte por que um humano faz isso → confira tecnologia, segurança, custo, política e legado → remova, automatize, consolide ou deixe visível → meça se o “por quê?” diminuiu.
12. Why Count
Conte quantas vezes aparecem: por que clicar nisso?, por que digitar de novo?, por que perguntar àquela pessoa?, por que conferir manualmente?, por que essa regra existe?
0: transparente. 1–2: fluido. 3–5: o sistema rouba a cena. 6+: o usuário vive operação e manutenção, não o produto. Não é escala acadêmica validada, mas aponta fricção concreta.
13. “Normal” é produto de luxo
Portas devem abrir, energia funcionar, busca encontrar, pagamento terminar, responsabilidades ser compreensíveis e relações não exigir reconstrução de regras em toda conversa.
Por isso um sistema excelente recebe “normal”. Por trás dessa normalidade existem exceções, testes, documentação e melhoria. O melhor design esconde o quanto foi difícil construir. Restaurante não anuncia “hoje a cozinha também não pegou fogo”; só serve o jantar.
14. Conclusão: bom design desaparece
Incômodo não prova que o mundo está errado nem que você está certo. Primeiro informa que seu modelo interno e a realidade observada não combinam.
Detecte → separe observação de interpretação → classifique → teste a causa → remova fricção → faça o “por quê?” desaparecer.
Não me faça lutar fora da partida. Não me faça trabalhar fora do trabalho. Não me faça fazer operação e manutenção só para viver. Não transforme o usuário no debugger gratuito do seu sistema.
