¿Deben disculparse los mensajes de error? (2013)
Si el software debería decir “lo siento” en los mensajes de error divide opiniones entre quienes prefieren un lenguaje humano y empático y quienes quieren precisión seca, parecida a una máquina. Muchos sostienen que las disculpas, los chistes y el lenguaje cursi resultan insinceros o paternalistas, especialmente cuando ocultan detalles accionables como qué salió mal, qué hacer a continuación o un código de error que se pueda buscar. Otros señalan que el tono y la indirecta pueden depender de la cultura, pero hay un amplio acuerdo en que la claridad, la brevedad y la orientación hacia una solución importan mucho más que la cortesía.
Si los mensajes de error deberían disculparse
- Muchos sostienen que “lo siento” suele ser un relleno innecesario. Rara vez ayuda a los usuarios a recuperarse y a menudo suena insincero o falso, ya que el software y los ingenieros no están realmente presentes ni son emocionales en el momento del fallo.
- Algunos creen que las disculpas solo son apropiadas para problemas graves o irrecuperables (por ejemplo, pérdida de datos, una interrupción prolongada) o cuando la organización ha fallado claramente y está trabajando para solucionarlo.
- Otros ven una disculpa cortés como parte de un buen servicio al cliente: si el usuario está bloqueado, el producto le ha fallado, incluso si “lo usó mal”.
Tono: humanizado vs. parecido a una máquina
- Existe un fuerte rechazo a los mensajes cursis, infantilizantes o excesivamente alegres (“upsi”, mascotas, caritas sonrientes o tristes). Se consideran paternalistas, poco profesionales y especialmente irritantes cuando los usuarios están estresados.
- Un grupo considerable prefiere errores secos, impersonales y “parecidos a una máquina” (estilo Unix) que eviten la antropomorfización y la empatía falsa.
- A algunos les gusta un tono humano ligero (“lo sentimos, tu correo no se pudo enviar”) para no sonar como si el software estuviera gritando, siempre que sea breve y respetuoso.
Claridad, capacidad de acción y detalle
- Hay un amplio acuerdo en que los requisitos básicos son:
- Ser conciso y específico sobre qué salió mal.
- Evitar o explicar la jerga para los usuarios finales.
- Indicar qué puede hacer el usuario después (reintentar, esperar, cambiar la entrada, contactar a alguien, seguir un enlace).
- Proporcionar identificadores o códigos que puedan buscarse o darse al soporte.
- Los mensajes vagos del tipo “Algo salió mal. Lo sentimos.” son muy criticados; bloquean a los usuarios y ocultan diagnósticos útiles.
Audiencia, responsabilidad y agencia
- Distinción entre:
- Mensajes dirigidos al usuario (educados, de alto nivel, centrados en acciones).
- Mensajes para desarrolladores/administradores (más técnicos, pueden incluir trazas de pila, rutas de configuración, etc.).
- Un largo subhilo debate “quién habla”: la herramienta del usuario, el proveedor o un administrador. En contextos libres/de código abierto, disculparse puede implicar una relación de control que algunos consideran indeseable; en software propietario o controlado por un proveedor, una disculpa en nombre de la empresa se considera más apropiada.
Cultura y lenguaje
- Algunos dialectos del inglés usan “sorry” para expresar simpatía, no culpa; otros lo entienden como una admisión de responsabilidad, lo que afecta a cómo se perciben las disculpas en los errores.
- Varios hablantes no estadounidenses señalan que las interfaces localizadas a menudo eliminan por completo “please/sorry” por considerarlo innecesario o culturalmente desajustado.
Humor e insultos
- El humor suave o los easter eggs pueden apreciarse en casos de bajo riesgo.
- La excesiva ternura o el chiste en fallos graves es ampliamente rechazado.
- Algunos disfrutan de errores deliberadamente sarcásticos o agresivos en nichos o en contextos de juegos, pero reconocen que no es apropiado para el software en general.