Filosofia de design

Os princípios dizem o que valorizamos. A filosofia é o que usamos quando as regras acabam: uma forma de pensar que orienta a resolução de problemas que nenhuma diretriz previu. Novas complexidades às vezes necessitam de novas formas de interação. Em qualquer uma delas, buscamos sempre facilitar os processos complexos para nossos usuários.

“Simples pode ser mais difícil que complexo: você precisa trabalhar duro para deixar o pensamento limpo e torná-lo simples.” — Steve Jobs, entrevista à BusinessWeek (1998)

Três ideias sustentam essa filosofia.

1. A complexidade não some, muda de dono

Um processo logístico é complexo por natureza: várias unidades, documentos, prazos, exceções. Isso não desaparece com uma tela bonita. A pergunta é quem carrega essa complexidade: o sistema ou a pessoa?

A Lei de Tesler (Larry Tesler, pesquisador da Xerox PARC) diz que todo sistema tem uma quantidade de complexidade que não pode ser eliminada, só tratada em algum lugar: ou no desenvolvimento do produto, ou na interação com o usuário. Também é chamada de Lei da Conservação da Complexidade.

Nossa escolha é deixar o sistema carregar. Quando o time de produto ou de engenharia absorve a complexidade (calcula, valida, preenche, sugere), a pessoa executa a tarefa. Quando não absorve, ela vai parar no colo do operador, em forma de mais campos, mais passos e mais decisões. Na prática

A complexidade fica com…	Como aparece	Exemplo
A pessoa	Campos a mais, regras para lembrar, erros para corrigir.	Digitar peso, volume e cubagem, e depois calcular o frete de cabeça.
O sistema	A pessoa informa o essencial; o resto é resolvido.	Informar origem e destino; o sistema sugere rota, calcula o frete e aponta o que falta.

Isso dá trabalho para quem projeta e desenvolve, e é por isso que vale. Cada minuto que gastamos absorvendo a complexidade é multiplicado por todas as pessoas que usam o sistema todos os dias.

2. O usuário bêbado

Uma abordagem interessante é o conceito de imaginar que “o usuário está bêbado”, originalmente desenvolvido por Richard Littauer e simplificado no vídeo a seguir. [video] A ideia não é sobre álcool. É sobre atenção: projetar para a pessoa que está distraída, cansada, com pressa ou interrompida. Se a interface funciona para ela, funciona para todo mundo. As principais vantagens desta abordagem:

Força a manter uma funcionalidade simples.
Baseia-se no usuário distraído. No nosso contexto, “bêbado” tem outros nomes: a pessoa no pátio sob o sol, de luva, no celular do motorista, no meio de uma fila de doca, atendendo o telefone enquanto preenche a tela. Ninguém está no seu melhor momento, e é aí que o sistema mais precisa ajudar. (O design inclusivo chama isso de limitação situacional: qualquer pessoa pode ter, a qualquer momento, sem ser deficiência permanente.)

Como aplicar: o teste do usuário bêbado

[Proposta] Revise a tela pensando em alguém atento pela metade:

Se a pessoa…	A tela deve…	Veja
Não lê, só passa o olho	Ter um objetivo evidente e a ação principal em destaque.	Clareza, Objetividade
Esquece o que estava fazendo	Mostrar o contexto (onde estou, o que estou editando) e não exigir que ela lembre.	Navegação e hierarquia
Erra o clique (luva, tela pequena, pressa)	Ter alvos de toque generosos e dar um jeito de voltar atrás.	Feedback ao usuário, Formulários e validação
Clica sem pensar numa ação destrutiva	Dizer o que vai acontecer antes, e não só “Tem certeza?”.	Feedback ao usuário
É interrompida e volta minutos depois	Preservar o que foi digitado, ou avisar que vai perder.	Formulários e validação
Erra ao digitar	Prevenir, aceitar formatos variados e explicar o erro com a saída.	Formulários e validação

Sinais de que estamos ignorando essa ideia

A interface só funciona se a pessoa ler o manual, o tooltip ou o texto de ajuda.
Um erro pequeno (digitar o CPF com pontos) trava o fluxo inteiro.
Não dá para desfazer nada.

3. A pessoa no controle

O sistema faz o trabalho pesado, mas quem decide é a pessoa. Automatizar é sugerir, preencher e antecipar, e não é tirar o controle.

“Os usuários frequentemente escolhem funções por engano e precisam de uma ‘saída de emergência’ claramente marcada para sair do estado indesejado.” — Jakob Nielsen, controle e liberdade do usuário (heurística nº 3)

Preencha automaticamente, mas deixe editar.
Toda ação que altera dado deve poder ser desfeita, ou avisar com clareza que não pode.
Nunca tome uma decisão irreversível pela pessoa.

Quando as regras acabam

Estas diretrizes são um direcionamento, não um livro de regras. Vai aparecer uma situação em que nenhuma delas se encaixa, ou em que seguir a regra deixa a experiência pior. Nesse caso, decida assim: [Proposta]

Qual é o problema real? Escreva em uma frase. (Princípio Questionamos)
Já existe um padrão? Procure no MDS e nas outras telas antes de inventar.
Qual solução exige menos da pessoa? Escolha a que deixa o sistema carregar a complexidade.
Isso passa no teste do usuário bêbado?
Dá para desfazer? Se a decisão estiver errada, o custo de voltar atrás deve ser baixo.
Se funcionar, registre. Uma exceção que se repete vira padrão no MDS. Conte ao time para ela não ficar só na sua tela. Desviar de uma diretriz é permitido. Desviar sem saber por quê, não.

Para designers

Ao desenhar, pergunte primeiro “o que o sistema pode fazer por ela?” e só depois “o que ela precisa fazer?”.
Revise cada tela com o teste do usuário bêbado.
Documente as exceções que abrir, com o motivo.

Para desenvolvedores

Se uma regra de negócio pode ser calculada, calcule. Não peça à pessoa para digitar o que o sistema sabe.
Preserve o estado quando o usuário é interrompido: rascunho, filtros, posição na lista.
Ao implementar uma ação que altera dado, pense em como desfazer e em como avisar.

Checklist de revisão

O sistema absorve a complexidade (calcula, valida, sugere) em vez de repassá-la à pessoa?
A tela funciona para alguém distraído, com pressa ou interrompido?
Dá para desfazer ou fica claro que não dá?
Se desviei de uma diretriz, sei dizer o porquê e avisei o time?

Para ir além

Laws of UX: Lei de Tesler
Jakob Nielsen, 10 heurísticas de usabilidade (controle e liberdade, prevenção de erros)
Microsoft Inclusive Design: deficiência permanente, temporária e situacional
Don Norman, The Design of Everyday Things, sobre erro humano e design que o previne