As mensagens de erro devem pedir desculpas? (2013)
Se software deve dizer “desculpe” em mensagens de erro divide opiniões entre quem prefere uma redação humana e empática e quem quer precisão sucinta, parecida com máquina. Muitos argumentam que desculpas, piadas e linguagem meiga soam insinceras ou paternalistas, especialmente quando escondem detalhes acionáveis como o que deu errado, o que fazer em seguida ou um código de erro para pesquisar. Outros observam que o tom e a indireção podem depender da cultura, mas há amplo consenso de que clareza, brevidade e orientação para a correção importam muito mais do que polidez.
Se mensagens de erro devem pedir desculpas
- Muitos argumentam que “desculpe” geralmente é excesso desnecessário. Raramente ajuda os usuários a se recuperarem e muitas vezes parece insincero ou falso, já que o software e os engenheiros não estão realmente presentes nem emocionais no momento da falha.
- Alguns acham que desculpas são apropriadas apenas para problemas graves ou irrecuperáveis (por exemplo, perda de dados, indisponibilidade prolongada) ou quando a organização claramente falhou e está trabalhando para corrigir isso.
- Outros veem um pedido de desculpas educado como parte de um bom atendimento ao cliente: se o usuário ficou impedido, o produto falhou com ele, mesmo que ele o tenha “usado incorretamente”.
Tom: humanizado vs. parecido com máquina
- Forte rejeição a mensagens meigas, infantilizantes ou excessivamente alegres (“ops”, mascotes, carinhas felizes/tristes). São vistas como paternalistas, pouco profissionais e especialmente irritantes quando os usuários estão estressados.
- Um grupo considerável prefere erros sucintos, impessoais, “parecidos com máquina” (estilo Unix) que evitam antropomorfismo e empatia falsa.
- Alguns gostam de um tom humano leve (“pedimos desculpas, seu e-mail não pôde ser enviado”) para não parecer que o software está gritando, desde que seja breve e respeitoso.
Clareza, acionabilidade e detalhe
- Há amplo consenso de que os requisitos centrais são:
- Ser conciso e específico sobre o que deu errado.
- Evitar ou explicar jargão para usuários finais.
- Indicar o que o usuário pode fazer a seguir (tentar novamente, esperar, alterar a entrada, contatar alguém, seguir um link).
- Fornecer identificadores ou códigos que possam ser pesquisados ou informados ao suporte.
- Mensagens vagas como “Algo deu errado. Desculpe.” são muito criticadas; elas bloqueiam os usuários e escondem diagnósticos úteis.
Público, responsabilidade e agência
- Distinção entre:
- Mensagens voltadas ao usuário (educadas, de alto nível, focadas em ação).
- Mensagens para desenvolvedores/administradores (mais técnicas, podem incluir traces de pilha, caminhos de configuração etc.).
- Um longo subthread debate “quem está falando”: a ferramenta do usuário, o fornecedor ou um administrador. Em contextos livres/de código aberto, pedir desculpas pode implicar uma relação de controle que alguns consideram indesejável; em software proprietário/controlado pelo fornecedor, um pedido de desculpas em nome da empresa é visto como mais apropriado.
Cultura e linguagem
- Alguns dialetos do inglês usam “sorry” para expressar empatia, não culpa; outros ouvem isso como admissão de responsabilidade, o que afeta a forma como as desculpas em mensagens de erro são percebidas.
- Vários falantes não americanos observam que UIs localizadas frequentemente retiram “por favor/desculpe” por completo por ser desnecessário ou culturalmente desalinhado.
Humor e insultos
- Humor leve ou easter eggs podem ser apreciados em casos de baixo risco.
- Excesso de meiguice ou piadas em falhas graves é amplamente rejeitado.
- Alguns gostam de erros deliberadamente sarcásticos ou agressivos em contextos de nicho ou jogos, mas reconhecem que isso é inadequado para software em geral.