Ringophilia/pense-como-o-usuario

Pense como o Usuário ao Interagir

Problema

A IA ao escrever interações, muitas vezes organiza a interface na ordem da implementação em vez de na ordem do usuário: primeiro coloca os controles com base na estrutura de dados; o botão onde a função foi escrita primeiro. O resultado:

• O botão "Salvar" de um formulário longo fica no topo da página, e o usuário, ao preencher até o final, precisa rolar de volta para encontrá-lo.
• "Excluir" fica ao lado de "Salvar", com a mesma cor e o mesmo tamanho.
• A função mais usada está escondida no segundo nível do menu "Mais ⋯", enquanto uma configuração raramente usada ocupa o local mais proeminente da barra de ferramentas.
• Mesmo com apenas uma opção, o usuário precisa selecioná-la antes de clicar em "Próximo".
• Para renomear algo, é necessário: clicar em "Modo de edição" → alterar → clicar em "Aplicar" → clicar em "Salvar" → janela de confirmação "Tem certeza que deseja salvar?".
• Criar algo novo exige três etapas de um assistente, quando na verdade só precisa de um nome.
• Botões rotulados como "Enviar", "Executar", "OK", e o usuário não sabe o que acontecerá ao clicar.
• Ao ocorrer um erro, aparece uma mensagem "Falha na operação" e todo o conteúdo inserido é limpo.

Cada item isoladamente não é fatal, mas juntos resultam em "Por que isso é tão estranho?".

Primeiro Passo: Esclareça para que o Usuário Veio

Antes de começar, escreva (mesmo que apenas mentalmente):

1. Quem está usando: Um novato de primeira viagem ou um veterano que usa diariamente?
2. Quais são as 1 a 3 tarefas mais comuns?: Essas tarefas devem ser as mais rápidas e mais visíveis.
3. Qual é o caminho ideal para cada tarefa?: Desde abrir o programa até concluir, quantos passos são necessários?

Organize o layout da interface de acordo com essa prioridade, e não com base na lista de funcionalidades, campos do banco de dados ou módulos de código.

Segundo Passo: Onde Colocar Botões e Entradas

Princípio	Prática	Contraexemplo
Ação perto do objeto que afeta	Botões de edição/exclusão na mesma linha; ações do cartão no próprio cartão	Primeiro selecionar uma linha, depois ir ao topo da página para encontrar "Editar"
Posicionar conforme o fluxo de conclusão	Botão de envio do formulário no final do formulário; botões da caixa de diálogo na parte inferior	Botão "Salvar" de um formulário longo no topo
Frequência determina proeminência	Funções mais usadas ficam visíveis diretamente; as ocasionais ficam em menus; as raras em configurações	Funções comuns escondidas em menus de segundo nível
Uma interface, uma ação principal	Ação principal com estilo de destaque; as demais com estilo secundário	Cinco botões azuis igualmente proeminentes
Ações perigosas separadas	"Excluir" com cor diferente, posicionado mais distante ou dentro de um menu	"Excluir" e "Salvar" lado a lado, com a mesma aparência
Seguir convenções da plataforma	Botões de diálogo no Windows no canto inferior direito, "OK" à esquerda de "Cancelar"; no macOS "Cancelar" à esquerda, botão principal à direita; pop-ups web com fechar no canto superior direito	Criar uma ordem própria
Mesma ação, mesma posição consistente	O botão "Novo" em todas as páginas está no mesmo lugar	Posição diferente em cada página
Entrada no local onde o usuário procura	O usuário pensa "Quero exportar" e olha no local esperado (barra de ferramentas, menu Arquivo, acima da lista)	Exportar escondido dentro da página de configurações

Terceiro Passo: Corte Etapas Desnecessárias

Liste cada passo da tarefa principal e pergunte gradualmente:

• Pode ser removido? O usuário precisa tomar uma decisão aqui? Se não, remova.
• Pode ter um valor padrão? 90% das pessoas escolheriam a mesma opção? Então marque-a como padrão. Lembre-se da última escolha do usuário.
• Pode ser combinado? "Editar → Aplicar → Salvar" pode se tornar editar diretamente com salvamento automático ou um único salvamento?
• Pode ser adiado? Registro, configurações detalhadas, campos opcionais podem ser perguntados apenas quando o usuário realmente precisar?
• Pode ser inferido automaticamente? O que pode ser deduzido do nome do arquivo, contexto ou dados existentes não deve ser solicitado ao usuário.

Etapas desnecessárias comuns:

Desnecessário	Substituir por
Ação reversível com confirmação "Tem certeza?"	Executar diretamente e oferecer "Desfazer" (toast estilo Gmail); confirmação apenas para ações irreversíveis e de alto impacto
Caixa de confirmação "Tem certeza? [Ok] [Cancelar]"	Escrever a consequência e o objeto: "Excluir 3 arquivos? Esta ação não pode ser desfeita. [Excluir] [Cancelar]"
Uma única opção que precisa ser selecionada	Selecionar automaticamente ou pular esta etapa diretamente
Alternância separada de "Modo de edição"	Tornar diretamente editável
Uma única informação em várias etapas de assistente	Uma caixa de entrada + um botão, ou criação inline
Alterar configuração e depois clicar em "Aplicar" e depois em "Salvar"	Uma única ação, ou efeito imediato
Após a operação, pular para outra página e o usuário ter que navegar de volta	Permanecer no local, atualizar no lugar
Preencher as mesmas informações repetidamente	Lembrar ou pré-preenchê-las

Quarto Passo: Não Adicione o que o Usuário Não Pediu

A IA facilmente "aproveita" e faz mais: o usuário quer um botão de exportar, e acaba com um menu suspenso de formato de exportação, histórico de exportação, página de configurações de exportação; o usuário quer uma ferramenta pequena, e acaba com uma barra lateral, menu de configurações, alternância de tema, página Sobre, central de ajuda, espaços reservados para "Em breve".

Cada funcionalidade, menu ou entrada adicional é mais uma coisa que o usuário precisa entender e pular, tornando a entrada da tarefa principal mais difícil de encontrar. Tudo na interface compete pela atenção do usuário.

Antes de adicionar algo, pergunte:

• O usuário pediu isso? Se não pediu e não é essencial para a tarefa principal, não adicione.
• Sem isso, o usuário ficará bloqueado? Se não, não adicione.
• Tem apenas uma opção ou quase ninguém vai alterar? Então não precisa de item de configuração nem de menu suspenso; use diretamente um valor padrão razoável.
• Está vazio, não implementado, ou "talvez seja útil depois"? Não coloque espaços reservados, botões acinzentados "Aguarde", menus que não respondem ao clique.

Comum demais:

Desnecessário	Substituir por
Ferramenta com apenas uma ou duas funções, mas com barra lateral + navegação superior + menu de configurações	Uma interface que exibe diretamente as funções
Alternância de tema, de idioma, configurações personalizadas não solicitadas	Não fazer; adicionar apenas quando necessário
Uma página que seria suficiente, mas dividida em "Início / Painel / Sobre / Ajuda"	Uma única página
A mesma funcionalidade com três entradas (barra de ferramentas, menu de contexto, página de configurações)	Uma entrada onde o usuário mais provavelmente procurará; atalhos de teclado podem ser adicionados separadamente
Espaços reservados "Em breve", "Recursos avançados", cartões de estatísticas vazios	Remover
Cada valor transformado em item configurável	Definir bons valores padrão e expor apenas o que o usuário realmente alterará

Quando achar que um recurso adicional é realmente útil, após concluir o requisito principal, sugira-o, deixando o usuário decidir se quer, em vez de implementá-lo diretamente.

Quinto Passo: Mantenha o Usuário Informado a Qualquer Momento

• Texto do botão = verbo + objeto: "Exportar CSV", "Excluir projeto", "Enviar convite", em vez de "Enviar", "Executar", "OK". Use as palavras do usuário, não as palavras da implementação (não escreva "Sincronizar payload", "Acionar job").
• Reação ao clique: Feedback visual em 100ms; para ações que levam mais de 1 segundo, mostre progresso ou estado de carregamento e desabilite o botão para evitar envios duplicados.
• Informe quando concluído: Um leve aviso de sucesso, ou a interface exibe diretamente o resultado.
• Erro: diga o que fazer: Explique claramente o que deu errado e como corrigir; exiba o erro ao lado do campo com erro; mantenha o conteúdo já inserido pelo usuário.
• Estado vazio: oriente o próximo passo: Quando a lista estiver vazia, informe o que aparecerá ali e forneça diretamente um botão "Criar o primeiro".
• Teclado: Ao abrir uma caixa de diálogo, o foco deve estar no primeiro campo de entrada; Enter para enviar, Esc para fechar; a ordem de tabulação deve corresponder à ordem visual.
• Não mude de repente: Não mova botões nem exiba pop-ups que bloqueiem o local onde o usuário está clicando.

CLI também: parâmetros comuns têm opções curtas e valores padrão razoáveis; operações perigosas exigem confirmação, mas fornecer --yes; mensagens de erro explicam como corrigir; tarefas longas mostram progresso.

Sexto Passo: Percorra Realmente o Fluxo

Escrever não é igual a ser fácil de usar. Antes de entregar, percorra realmente como usuário a tarefa principal (para capturas de tela, veja background-friendly):

1. Finja ser a primeira vez: sem olhar o código, apenas a interface, consegue encontrar em 5 segundos a entrada para a tarefa que deseja fazer?
2. Conte os passos: Quantos cliques/entradas são necessários para concluir a tarefa principal? Compare com o caminho ideal escrito no primeiro passo. Cada passo extra deve ter uma justificativa.
3. Percorra apenas com o teclado.
4. Cometa um erro de propósito: insira dados errados, cancele no meio, desconecte a rede, veja o que acontece e se a entrada é perdida.
5. Reduza a janela, com muito conteúdo ou vazia: os botões ainda estão em posições razoáveis?

Quando não for possível percorrer (sem ambiente de execução), informe claramente ao usuário "Fluxo de interação não verificado na prática" e liste as etapas que você projetou para que o usuário as verifique.

Limites

• Quando o usuário especificar layout ou fluxo, siga o dele; se achar que há problema, diga e deixe o usuário decidir.
• Usuários veteranos de ferramentas profissionais podem valorizar mais a eficiência do que a facilidade de aprendizado: atalhos, operações em lote, alta densidade são mais importantes que tutoriais para iniciantes. Primeiro, identifique quem é o usuário.
• Operações irreversíveis e de alto risco (pagamento, exclusão de dados de produção, envio de mensagens em massa) devem ter uma etapa extra de confirmação; não a remova apenas para "reduzir passos".
• Ao modificar um programa existente, não faça grandes alterações em posições que os usuários já estão acostumados apenas para "tornar mais razoável"; se realmente precisar alterar, explique o motivo.

Lista de Verificação

• Quais são as 1 a 3 tarefas mais comuns? Elas são as mais rápidas e mais visíveis?
• Cada botão está próximo ao objeto que afeta e na posição onde o usuário conclui o fluxo?
• Cada interface tem apenas uma ação principal? Ações perigosas estão separadas da ação principal?
• Está de acordo com as convenções da plataforma (ordem dos botões, posição, atalhos)?
• Cada passo da tarefa principal foi questionado: "pode ser removido, pode ser padrão, pode ser combinado"?
• Cada funcionalidade, menu e entrada são solicitados pelo usuário ou essenciais? Não há espaços reservados nem configurações não solicitadas?
• As caixas de confirmação são usadas apenas para operações irreversíveis? Operações reversíveis oferecem "Desfazer"?
• O texto do botão é "verbo + objeto"? Usa as palavras do usuário?
• Estados de carregamento, sucesso, erro e vazio foram tratados? Em caso de erro, a entrada é preservada?
• Você realmente percorreu como um novo usuário e contou os passos? Se não percorreu, diga "não verificado"