Cuando el usuario produce un error, ¿le informamos de forma clara cuál fue el problema y de qué manera lo puede solucionar?

Mensajes de error frustrantes:

  1. No indican el campo donde está el error.
  2. No otorgan soluciones.
  3. Tiene un lenguaje técnico. Están redactados por y para programadores!

Ej:   “Imposible contactar al servidor SMTP”
“Error al escribir datos en MySQL”


Jakob Nielsen, en su artículo Error Message Guidelines” ofrece los siguientes consejos:

  • Indicar explícitamente que ha sucedido un problema. Cuando los usuarios provocan errores y no reciben un feedback, se encuentran completamente perdidos.
  • Evitar el lenguaje técnico y abreviaturas, utilizando un lenguaje claro y comprensible (human-readable language).
  • Usar frases amigables (polite phrasing): No culpar a los usuarios con mensajes como “comando ilegal”.
  • Ser precisos: Hacer una descripción exacta del problema. No utilizar mensajes vagos y genéricos como “error de sintaxis”.
  • Brindar siempre soluciones. Si es necesario incluir ejemplos.
  • Hacer visible el cartel de error y señalar claramente el campo en cuestión (para indicarlo, no basarse sólo en el color, sino, acompañarlo también de un icono).
  • Preservar el trabajo del usuario. No limpiar el formulario cuando se produzca un error, sino respetar el trabajo que se tomó para completarlo y permitir que lo corrija sin tener que rescribirlo.
  • Reducir el trabajo del usuario y si es posible, interpretar lo que intentaba hacer, ofreciéndo una lista breve con opciones para que elija lo que deseaba realizar.
  • También se pueden utilizar (sin abusar) links a páginas con material adicional de ayuda.

Desde ya, siempre es mejor tratar de evitar que se produzcan errores, pero en caso de que ocurran, los mensajes deben de ser expresados en un lenguaje claro y no técnico proveyendo constructivamente una solución.

Fuente: Error Message Guidelines, Jakob Nielsen