Design do dia a dia: os princípios de Don Norman aplicados ao UI/UX

Existe um tipo de porta que praticamente todo mundo já empurrou quando deveria ter puxado. Don Norman batizou o fenômeno de "porta Norman" sem querer: no livro O Design do Dia a Dia (The Design of Everyday Things), ele usa esse objeto banal para mostrar que, quando precisamos de um manual para abrir uma porta, o problema não é nosso — é do design.

O livro foi escrito pensando em objetos físicos, mas cada princípio dele tem um correspondente direto na tela. Trabalho há anos no limite entre design e engenharia, e raramente abro um produto sem reconhecer uma porta Norman escondida em algum lugar do fluxo. Abaixo, os princípios que mais uso no dia a dia de UI/UX.

Affordances e significantes

Uma affordance é a relação entre o que um objeto permite fazer e quem o usa. Uma cadeira "oferece" sentar; um botão "oferece" pressionar. No mundo digital, porém, quase nada tem affordance física real — tudo é pixel. Por isso o conceito que importa de verdade na interface é o significante (signifier): o sinal visível que comunica onde a ação acontece.

Sublinhar um link, dar profundidade a um botão, mostrar um cursor que muda de forma — são significantes. Quando você remove todos eles em nome de um visual "limpo", está removendo o mapa, não a sujeira.

Affordances determinam quais ações são possíveis. Significantes comunicam onde a ação deve acontecer. UI ruim costuma ter a primeira sem a segunda.

O flat design levado ao extremo é o exemplo clássico: um texto que é botão e um texto que é só texto ficam idênticos. A ação existe, mas ninguém a encontra.

Mapeamento

Mapeamento é a correspondência entre controles e seus efeitos. O exemplo do livro são as bocas do fogão: quando os botões estão em linha e as bocas em quadrado, você erra para sempre. Quando cada botão fica espacialmente alinhado à sua boca, você acerta sem pensar.

Na interface, mapeamento aparece em decisões como:

• um slider de volume que cresce da esquerda para a direita, como esperamos;
• setas de paginação que apontam para o lado em que o conteúdo se move;
• um toggle cujo estado "ligado" fica visualmente à direita e aceso.

Bom mapeamento é aquele que você nunca percebe — ele simplesmente coincide com a intuição que o usuário já trouxe de fora.

Feedback

Toda ação precisa de uma reação perceptível e imediata. Aperte um botão de elevador e ele acende; sem isso, você aperta de novo e de novo. Na tela, a ausência de feedback gera o mesmo comportamento: o usuário clica três vezes em "Salvar" porque nada confirmou o primeiro clique.

Feedback bem feito responde a três perguntas em ordem:

1. Recebi seu comando? — o estado de loading, o botão que afunda.
2. Está acontecendo? — a barra de progresso, o skeleton.
3. Terminou, e como? — o toast de sucesso, a mensagem de erro específica.

Pular qualquer um desses passos transforma uma espera de dois segundos numa sensação de produto quebrado.

Modelo conceitual

O usuário constrói um modelo mental de como o sistema funciona a partir do que vê. O trabalho do designer é fazer com que esse modelo bata com o modelo real da implementação. Quando os dois divergem, surge a frustração: a pessoa age segundo o modelo que imaginou, e o sistema responde segundo o que foi codado.

Um carrinho de compras é uma boa metáfora justamente porque empresta um modelo mental pronto do mundo físico — você adiciona, remove, vê o total. Quando uma interface inventa uma metáfora própria e não a sustenta, paga o preço em suporte.

O golfo da execução e o da avaliação

Norman descreve dois abismos entre intenção e ação:

• o golfo da execução — a distância entre o que quero fazer e descobrir como fazer;
• o golfo da avaliação — a distância entre o sistema agir e eu entender o que aconteceu.

Bom design estreita os dois. Significantes e mapeamento encurtam a execução; feedback encurta a avaliação. Quando recebo um ticket de "o usuário não achou o botão", quase sempre é um golfo de execução. Quando é "fiz mas não sei se deu certo", é avaliação.

Restrições: prevenir o erro antes de explicá-lo

Em vez de confiar na atenção do usuário, restrinja as ações possíveis. Um campo de data que só aceita datas válidas elimina uma classe inteira de erros. Desabilitar "Enviar" enquanto o formulário está incompleto é uma restrição — desde que você diga por que está desabilitado.

Norman separa dois tipos de erro que pedem soluções diferentes:

• Deslizes (slips): você sabia o que queria, mas a mão errou. Combatem-se com restrições e alvos de clique generosos.
• Enganos (mistakes): você formou o objetivo errado. Combatem-se com um modelo conceitual mais claro, não com mais validação.

Em vez de:  "Erro: entrada inválida"
Prefira:    "A data precisa ser futura — a entrega não pode ser no passado"

A primeira mensagem culpa o usuário. A segunda explica a restrição e mostra a saída.

Design centrado no humano

O fio que costura tudo é o design centrado no humano: comece pelas necessidades reais das pessoas, e não pela tecnologia ou pela estética. Norman defende o ciclo de observar, gerar ideias, prototipar e testar — repetido até a interface desaparecer e sobrar só a tarefa.

A lição que carrego do livro é quase um teste de aceitação: quando o usuário erra, a culpa é do design. Antes de adicionar um tooltip explicando o botão, pergunte por que o botão precisou de explicação. Quase sempre dá para mudar o significante, o mapeamento ou a restrição — e fazer a porta abrir do jeito certo na primeira tentativa.