O design na Anested tem uma frase governante: interfaces devem se explicar sozinhas. Todo o resto que praticamos — cada comentário de review, cada mockup rejeitado — é consequência desse único teste. Se um usuário precisa de manual, o design não está pronto.
Primeiro, hierarquia antes de decoração. Uma tela é um argumento ranqueado sobre o que mais importa. Se tudo está em negrito, nada está; se cada elemento exige atenção, o usuário não dá atenção a nenhum. Definimos escalas tipográficas, espaçamento e alinhamento antes que alguém possa escolher uma cor, porque hierarquia comunica mesmo quando o estilo falha.
Segundo, os estados são o design. Estados vazios, de carregamento, de erro, de sucesso — é onde os usuários realmente vivem, especialmente na primeira semana de uso de um produto. Nós os projetamos primeiro, não por último. Um caminho feliz bonito preso a um estado de erro críptico não é um produto bonito; é um produto quebrado com bom marketing.
Terceiro, movimento precisa merecer seu custo de renderização. Removemos quase toda animação do nosso próprio site corporativo, e o que sobreviveu foi feedback de hover e nada mais. Cada animação é uma cobrança sobre a atenção do usuário e a bateria do aparelho. Contenção, descobrimos, é lida como confiança.
Quarto, acessibilidade é piso, não recurso. Razões de contraste, estados de foco, navegação por teclado e marcação semântica são exigidos em code review exatamente como qualquer outra questão de corretude. Uma interface que só funciona para alguns usuários é uma interface com bug.
E quinto: se nos pegamos escrevendo um tooltip para explicar um controle, primeiro tentamos redesenhar o controle. Às vezes o tooltip vence — mas ele precisa vencer o debate. O manual é o bug, e cada princípio acima é apenas uma forma diferente de não escrevê-lo.
Precisa de ajuda com algo deste post?
Nossos engenheiros respondem diretamente — hospedagem, bancos de dados, código ou qualquer assunto deste post.