¿Cómo lograr que los usuarios lean mensajes de error?

Si programa para una audiencia no técnica, se encuentra en un alto riesgo de que los usuarios no lean sus mensajes de error cuidadosamente redactados e ilustrativos, sino que simplemente hagan clic en el primer botón disponible con un encogimiento de frustración.

Por lo tanto, me pregunto qué buenas prácticas puede recomendar para ayudar a los usuarios a leer su mensaje de error, en lugar de simplemente dejarlo de lado. Las ideas que se me ocurren caerían en la línea de:

• Formateo de la ayuda del curso; tal vez un mensaje simple y corto, con un botón "aprender más" que conduce al mensaje de error más largo y detallado
• Tener todos los mensajes de error vinculados a alguna sección de la guía del usuario (algo difícil de lograr)
• Simplemente no emita mensajes de error, simplemente rehúse realizar la tarea (una forma algo "Apple" de manejar la entrada del usuario)

Editar: la audiencia que tengo en mente es una base de usuarios bastante amplia que no usa el software con demasiada frecuencia y no es cautiva (es decir, no tiene un software interno o una comunidad limitada). Se hizo una forma más genérica de esta pregunta en slashdot , por lo que es posible que desee verificar algunas de las respuestas.

Esa es una excelente pregunta digna de un +1 de mi parte. La pregunta, a pesar de ser simple, cubre muchos aspectos de la naturaleza de los usuarios finales. Aquí se reduce a una serie de factores que lo beneficiarían a usted y al software en sí, y, por supuesto, a los usuarios finales.

• No coloque mensajes de error en la barra de estado: nunca los leerán a pesar de tener colores, etc. ¡siempre los extrañarán! No importa cuánto lo intente ... En una etapa durante la prueba de interfaz de usuario de Win 95 antes de su lanzamiento, MS llevó a cabo un experimento para leer la interfaz de usuario ( ed . 'Mira debajo de la silla' ), con un billete de $ 100 dólares pegado en la parte inferior de la silla en la que estaban sentados los sujetos ... ¡nadie vio el mensaje en la barra de estado!
• Haga los mensajes cortos, no use palabras intimidantes como 'Alerta: el sistema encontró un problema', el usuario final presionará el botón de pánico y reaccionará de forma exagerada ...
• No importa cuánto lo intentes, no uses colores para identificar el mensaje ... psicológicamente, ¡es como agitar una bandera roja al toro!
• ¡Usa palabras que suenen neutrales para transmitir una reacción mínima y cómo proceder!
• Puede ser mejor mostrar un cuadro de diálogo con el mensaje de error neutral e incluir una casilla de verificación que indique '¿Desea ver más de estos mensajes de error en el futuro?', Lo último que desea un usuario final es estar trabajando en medio del software que se bombardeará con mensajes emergentes, se frustrarán y la aplicación los apagará. Si la casilla de verificación estaba marcada, en su lugar, conéctela a un archivo ...
• Mantenga a los usuarios finales informados sobre los mensajes de error que habrá ... lo que implica ... capacitación y documentación ... ahora es difícil de transmitir ... no quiere que piensen que habrá sean 'problemas' o 'fallas técnicas' y qué hacer en caso de que ... no deben saber que habrá posibles errores, lo que es realmente complicado.
• Siempre, siempre, no tenga miedo de pedir comentarios cuando suceda sin incidentes, como 'Cuando apareció ese error número 1304, ¿cómo reaccionó? ¿Cuál fue su interpretación? - la ventaja con eso es que el usuario final puede darle una explicación más coherente en lugar de 'Error 1304, ¡se perdió el objeto de la base de datos!', En lugar de decir 'Hice clic en esto para y entonces, alguien tiró del cable de red de la máquina accidentalmente ', esto le dará una pista sobre cómo tener que lidiar con él y puede modificar el error para decir' Vaya, conexión de red desconectada '... usted entiende.
• Por último, pero no menos importante, si desea dirigirse a audiencias internacionales, tenga en cuenta la internacionalización de los mensajes de error; de ahí que sea neutral, porque así será más fácil traducir, evitar sinónimos, palabras de jerga, etc. la traducción no tiene sentido: por ejemplo, Fiat Ford, la compañía de automóviles vendía su marca Fiat Ford Pinto, pero se dio cuenta de que no había ventas en Sudamérica, resultó que Pinto era una jerga de 'pene pequeño' y, por lo tanto, no había ventas. ...
• ( ed ) Documente la lista de mensajes de error que se esperan en una sección separada de la documentación titulada 'Mensajes de error' o 'Acciones correctivas' o similar, enumerando los números de error en el orden correcto con una declaración o dos sobre cómo proceder. ..
• ( ed ) Gracias a Victor Hurdugaci por su aporte, mantenga los mensajes corteses, no haga que los usuarios finales se sientan estúpidos. Esto va en contra de la respuesta de Jack Marchetti si la base de usuarios es internacional ...

Editar: ¡ Una palabra especial de agradecimiento a gnibbler que también mencionó otro punto extremadamente vital!

• Permita que el usuario final pueda seleccionar / copiar el mensaje de error para que pueda, si lo desea, enviar un correo electrónico al equipo de soporte técnico o al equipo de desarrollo.

Edición # 2: ¡ Mi mal! Vaya, gracias a DanM que mencionó eso sobre el auto, me confundí con el nombre, era Ford Pinto ... mi mal ...

Edición n. ° 3: Han resaltado por ed para indicar adiciones o adiciones y acreditado a otros por sus aportes ...

Edición n. ° 4: en respuesta al comentario de Ken: esta es mi opinión ... No, no lo es, use colores neutros estándar de Windows ... ¡no elija colores llamativos! Apéguese al color de fondo gris normal con texto en negro, que es una guía GUI estándar normal en las especificaciones de Microsoft ... consulte las Pautas UX ( ed ).

Si insiste en colores llamativos, al menos, tenga en cuenta a los usuarios potenciales daltónicos, es decir, la accesibilidad, que es otro factor importante para aquellos que tienen una discapacidad, mensajes de error amigables de aumento de pantalla, daltonismo, aquellos que sufren con albino, ellos puede ser sensible a los colores llamativos, y también a los epilépticos ... que pueden sufrir de un color particular que podría desencadenar una convulsión ...

Muéstrales el mensaje. Debida diligencia y todo, pero registre cada error en un archivo. Los usuarios no pueden recordar lo que estaban haciendo o cuál fue el mensaje de error segundos después del evento, es como cuentas de testigos presenciales de perpetradores.

Proporcione una buena manera de permitir que le envíen un correo electrónico o carguen el registro para que pueda ayudarlos a conciliar el problema. Si se trata de una aplicación web: incluso mejor, puede estar recibiendo información sobre la situación antes de que alguien informe el problema.

Respuesta corta: no puedes.

Respuesta menos corta: hacerlos visibles, relevantes y contextuales (resaltar lo que estropearon). Pero aún así, estás luchando una batalla perdida. Las personas no leen en las pantallas de las computadoras, escanean y han recibido capacitación para hacer clic en los botones hasta que desaparezcan los cuadros de diálogo.

Ponemos un gráfico simple y memorable en el cuadro de error: no es un ícono, un mapa de bits bastante grande y nada como los íconos de mensaje estándar de Windows. Nadie puede recordar la redacción de un cuadro de mensaje (la mayoría ni siquiera lo leerá si el cuadro tiene un botón "Aceptar" que pueden presionar), pero la mayoría de las personas SÍ recuerdan la imagen que vieron. Entonces, nuestro personal de soporte puede preguntarle al cliente "¿viste al chico que bebe café?" o "¿viste el escritorio vacío?". Al menos de esa manera sabemos aproximadamente qué salió mal.

Dependiendo de su base de usuarios, escribir mensajes de error divertidos / groseros / personales puede funcionar muy bien.

Por ejemplo, escribí una solicitud que permitía a nuestro personal de RR. HH. Rastrear mejor las fechas de contratación / despido de los empleados. [Éramos una empresa pequeña, muy relajada].

Cuando ingresaban fechas incorrectas, escribía:

¡Oye tonto, aprende cómo ingresar una cita!

EDITAR: Por supuesto, un mensaje más útil es decir: "Ingrese la fecha como mm / dd / aaaa" o tal vez en el código para intentar averiguar qué ingresaron y si ingresaron "blahblah" para mostrar un error. Sin embargo, esta fue una aplicación muy pequeña para una persona de recursos humanos que conocía personalmente. Por lo tanto, nuevamente gente, lea la primera línea de esta publicación: Dependiendo de su base de usuarios ...

Recientemente trabajé en un proyecto del Instituto de Arte, por lo que los mensajes de error se dirigieron a la audiencia, tales como:

La mayoría del arte anterior al período barroco no tenía firma. Sin embargo, ahora estamos más allá del período barroco, por lo que todos los campos deben completarse.

Básicamente, diríjalo a su audiencia si es posible, y evite todos los errores generales aburridos como: "ingrese un correo electrónico" o "ingrese un correo electrónico válido".

Las alertas / ventanas emergentes son molestas, por eso todos presionan el primer botón que ven.

Hazlo menos molesto . Ejemplo: si el usuario ingresó la fecha de manera incorrecta, o ingresó un texto donde se esperan números, entonces NO muestre un mensaje, simplemente resalte el campo y escriba un mensaje en algún lugar a su alrededor.

Crea un cuadro de mensaje personalizado . No utilice nunca el cuadro de mensaje predeterminado del sistema, por ejemplo, los cuadros de mensaje de Windows XP son molestos. Cree un nuevo cuadro de mensaje de color, con un color de fondo diferente al predeterminado del sistema.

Muy importante: no insistas . Algunos cuadros de mensaje utilizan el cuadro de diálogo modal e insisten en hacerle leerlo, esto es muy molesto. Si puede hacer que el cuadro de mensaje aparezca como un mensaje de advertencia, sería mejor, por ejemplo, los mensajes de desbordamiento de pila que aparecen justo en la parte superior de la página, informando pero no molestos.

ACTUALIZAR
Haga que el mensaje sea significativo y útil . Por ejemplo, no escriba algo como "No se encontró el teclado, presione F1 para continuar".

El mejor diseño de interfaz de usuario será donde prácticamente nunca muestra un mensaje de error. El software debe adaptarse al usuario. Con ese tipo de diseño, un mensaje de error será novedoso y captará la atención de los usuarios. Si acribilla al usuario con diálogos sin sentido como ese, lo está entrenando explícitamente para ignorar sus mensajes.

En mi opinión y experiencia, son los usuarios avanzados, que no leen los mensajes de error. El público no técnico que conozco lee cada mensaje en la pantalla con más cuidado y el problema en este punto es: no lo entienden.

Este punto puede ser la causa de su experiencia, porque en algún momento dejarán de leerlos, porque "de todos modos no lo entienden", por lo que su tarea es fácil:

Haga que el mensaje de error sea lo más fácil de entender posible y mantenga la parte técnica debajo del capó.

Por ejemplo, transfiero un mensaje como este:

ORA-00237: operación de instantánea no permitida: archivo de control recién creado Causa: Se realizó un intento de invocar cfileMakeAndUseSnapshot con un archivo de control actualmente montado que se creó recientemente con CREATE CONTROLFILE. Acción: monte un archivo de control actual y vuelva a intentar la operación.

a algo como:

Este paso no se pudo procesar debido a problemas momentáneos con la base de datos. Póngase en contacto con (su administrador | el servicio de asistencia | cualquier persona que pueda contactar al desarrollador o administrador para resolver el problema). Lo siento por los inconvenientes ocasionados.

Muestre a los usuarios que el mensaje de error tiene un significado y que es una forma de brindarles asistencia y que lo leerán. Si se trata solo de jerga o mensaje sin sentido genérico, aprenderán a descartarlos rápidamente.

He aprendido que es una muy buena práctica incluir un cuadro de diálogo de error con acción predeterminada para enviar (por ejemplo, por correo electrónico) información de diagnóstico detallada, si responde rápidamente a esos correos electrónicos con información valiosa o solución alternativa, lo adorarán.

Esta también es una gran herramienta de aprendizaje. En futuras versiones, puede resolver problemas conocidos o al menos proporcionar información de solución en el lugar. Hasta entonces, los usuarios aprenderán que este mensaje es causado por X y el problema puede ser resuelto por Y, todo porque alguien se lo explicó.

Por supuesto, esto no funcionará en una aplicación a gran escala, pero funciona muy bien en aplicaciones empresariales con unos pocos cientos de usuarios, y en un entorno ágil y ágil, lanzar a menudo versiones tempranas.

EDITAR:

Dado que tiene una amplia base de usuarios, le recomiendo proporcionar un software que haga lo que los usuarios son / pueden esperar que haga, por ejemplo. no les muestre un mensaje de error si el número de teléfono no está bien formateado, vuelva a formatear si es para ellos.

Personalmente, me gusta el software que no me hace pensar , y cuando ocasionalmente no hay nada que usted (el desarrollador) pueda hacer para interpretar mi intención, proporcionar mensajes muy bien escritos (y revisados ​​por usuarios reales).

Es de conocimiento común que las personas no leen la documentación (¿leyó las instrucciones consecutivamente cuando enchufó un electrodoméstico?), Intentan una forma de obtener resultados rápidamente, cuando falla, debe captar su atención (por ejemplo. desactivar el botón predeterminado por un tiempo) con información significativa y útil . No les importa la falla de su software, ahora quieren obtener resultados.

Hacerlas divertidas . (Parecía relevante, dado el sitio en el que estamos :))

Para comenzar, escriba mensajes de error que los usuarios puedan entender. "Error: 1023" no es un buen ejemplo. Creo que es mejor registrar el error que mostrarlo al usuario con un código "elegante". O si el registro no es posible, brinde a los usuarios la forma adecuada de enviar los detalles del error al departamento de soporte.

Además, sea lo suficientemente breve y claro. No incluya algunos detalles técnicos. No les muestre información que no puedan usar. Si es posible, proporcione una solución para el error. Si no proporciona una ruta predeterminada, se debe tomar.

Si su aplicación es una aplicación web, diseñar páginas de error personalizadas es una buena idea. Insisten menos en los usuarios, tomen SO por ejemplo. Puede obtener algunas ideas sobre cómo diseñar una buena página de error aquí: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

Una cosa que me gustaría agregar.

Use verbos para sus botones de acción para cerrar sus mensajes de error en lugar de exclamaciones, por ejemplo, no use "¡Ok!" "Cerrar" etc.

Un buen consejo que he aprendido es que debes escribir un cuadro de diálogo como un artículo de periódico. No en el sentido del tamaño, sino en el sentido de la importancia. Dejame explicar.

Debe escribir las cosas más importantes para leer, primero, y proporcionar información más detallada en segundo lugar.

En otras palabras, esto no es bueno:

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Do you want to retry opening the file?

En cambio, cambie el orden:

Problem loading file, do you want to retry?

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

De esta manera, el usuario puede leer todo lo que quiera, o molestarse, y aún así tener una idea de lo que se le pregunta.

Ver también las respuestas de los usuarios de Slashdot aquí .

A menos que pueda proporcionarle al usuario una solución simple, no se moleste en mostrarle un mensaje de error. Simplemente no tiene sentido, ya que al 90% de los usuarios no les importará lo que dice.

Por otro lado, si PUEDE mostrarle al usuario una solución útil, entonces una forma de obligarlo a leerlo es habilitar el botón Aceptar después de 10 segundos más o menos. Algo así como Firefox lo hace cada vez que intentas instalar un nuevo complemento.

Si se trata de un bloqueo total del que no puede recuperarse con gracia, informe al usuario en términos muy simples diciendo:

" Lamento que nos hayamos equivocado, nos gustaría enviar información sobre este bloqueo, ¿nos lo permite? SÍ / NO "

Además, trate de no hacer que sus mensajes de error sean más largos que una oración. Cuando la gente (incluido yo) ve un párrafo completo hablando sobre el error, mi mente se apaga.

Con tanta sobrecarga de redes sociales e información, la mente de las personas se congela cuando ven un muro de texto.

EDITAR:

Alguien también sugirió recientemente usar tiras cómicas junto con cualquier mensaje que desee mostrar. Como algo de Dilbert que puede estar cerca del tipo de error que pueda tener.

Según mi experiencia: no se consigue que los usuarios (especialmente los no técnicos) lean mensajes de error. No importa cuán claro y comprensible, en negrita, rojo y parpadeante sea el mensaje que muestra, la mayoría de los usuarios simplemente harán clic en cualquier cosa a la que no estén acostumbrados, incluso si es "¿Realmente desea eliminar todo?". He visto a los usuarios hacer clic en el icono "cerrar ventana" en lugar de "Aceptar" o "cancelar" aunque ni siquiera sabían qué opción elegirían al hacerlo ...

Si realmente necesita obligar a los usuarios a leer lo que está mostrando, sugeriría una cuenta regresiva de JavaScript hasta que se pueda hacer clic en un botón. De esa manera, el usuario utilizará el tiempo de espera para leer realmente lo que se supone que debe leer. Sin embargo, tenga cuidado: la mayoría de los usuarios estarán aún más molestos por eso :)

Además, me gusta su idea de un enlace de "leer más", aunque dudo que eso haga que los usuarios estén más interesados ​​que solo quieran deshacerse del mensaje por todos los medios ...

Solo para que conste: hay usuarios que SÍ leen mensajes de error pero tienen tanto miedo de no hacer nada al respecto. Una vez recibí una llamada de soporte en la que el cliente me leía un mensaje de error, preguntándome qué debía hacer. "Bueno, ¿cuáles son tus opciones?", Le pregunté. "La ventana solo tiene un botón 'OK'", respondió. ... mmh, uno duro :)

A menudo muestro el error en rojo (cuando el diseño lo permite).

Rojo significa "alerta", etc., por lo que se lee con más frecuencia.

Bueno, para responder a su pregunta directamente: no haga que sus programadores escriban sus mensajes de error. Si sigue este único consejo, ahorraría, acumulativamente, miles de horas de angustia y productividad del usuario y millones de dólares en costos de soporte técnico.

Sin embargo, el objetivo real debería ser diseñar su aplicación para que los usuarios no puedan cometer errores. No dejes que tomen medidas que conduzcan a masajes por error y que requieran que realicen una copia de seguridad. Como un ejemplo simple, en un formulario web que requiere que se completen todos sus campos, en lugar de mostrar un mensaje de error cuando los usuarios hacen clic en el botón Enviar, no habilite el botón Enviar hasta que todos los campos contengan contenido válido. Significa más trabajo en la parte posterior, pero resulta en una mejor experiencia de usuario.

Por supuesto, ese es un mundo un poco ideal. A veces, los errores del programa son inevitables. Cuando se producen, debe proporcionar información clara, completa y útil, y lo más importante, no exponga el sistema al usuario y no culpe a los usuarios por sus acciones.

Un buen mensaje de error debe contener:

1. Cuál es el problema y por qué sucedió.
2. Cómo resolver el problema

Una de las peores cosas que puede hacer es simplemente pasar mensajes de error del sistema a los usuarios. Por ejemplo, cuando su programa Java arroja una excepción, no simplemente pase el programador a la interfaz de usuario y lo exponga al usuario. Atrápalo y ten un mensaje claro creado por tu desarrollador de asistencia al usuario que puedes presentar a tu usuario.

Tuve la suerte, en mi último trabajo, de trabajar con un equipo de programadores que no pensaría en escribir sus propios mensajes de error. Cada vez que se encontraban en una situación en la que se requería uno y el programa no podía diseñarse para evitarlo (a menudo debido a los recursos limitados), siempre acudían a mí, me explicaban lo que necesitaban y me dejaban crear un mensaje de error que decía: Fue claro y siguió el estilo de la empresa. Si esa fuera la mentalidad predeterminada de cada programador, el mundo de la informática sería un lugar mucho, mucho mejor.

Menos errores

Si una aplicación te arroja vómito de forma regular, te vuelves inmune a él y los errores se vuelven irritantes muzak de fondo. Si un error es un evento raro, atraerá más atención.

Elimine todo lo que no sea importante, descarte todas esas advertencias, encuentre formas de comprender la intención del usuario, tome las decisiones siempre que sea posible. Tengo algunas aplicaciones que sigo simplificando de esta manera. Los desarrolladores ven cada error como importante, pero esto no es cierto desde la perspectiva del usuario. Busque la respuesta común de los usuarios a un problema y capture eso, impleméntelo como su respuesta.

Si necesita generar un error: corto, conciso, bajo factor de terror, sin signos de exclamación. Los párrafos son fallidos .

No hay una bala de plata, pero necesitas ingeniero social para que los errores sean importantes.

Les dijimos a los usuarios que su gerente había sido contactado (lo cual era una mentira). Funcionó demasiado bien y tuvo que ser eliminado.

Agregar un botón "Avanzado" que permita algunos detalles más técnicos proporcionará un incentivo para leerlo para la parte del público objetivo que se considera técnico

Le sugiero que envíe sus comentarios (indicando que el usuario cometió un error) inmediatamente después de cometer el error. (Por ejemplo, al ingresar un valor de un campo de fecha, verifique el valor y, si está incorrecto, haga que el campo de entrada sea visualmente diferente).

Si hay errores en la página (estoy más interesado en el desarrollo web, por lo tanto, me refiero a ella como una "página", pero también se puede llamar "formulario"), muestre un "resumen de errores", explicando que hay hubo errores y una lista con viñetas de los errores exactos que ocurrieron. Sin embargo, si hay más de 5-6 palabras por mensaje, no se leerán ni comprenderán.

¿Qué tal hacer que el botón diga "Haga clic aquí para hablar con un técnico de soporte que lo ayudará con este problema".

Hay muchos sitios web que ofrecen la opción de hablar con una persona real.

Leí a un candidato para la solución más horrible en slashdot:

Hemos descubierto que la única forma de hacer que los usuarios se hagan responsables de los errores es imponiéndoles una multa por obligar a que el error desaparezca. Para empezar, cuando sea posible, el error no se cerrará para ellos a menos que ingresemos una contraseña de administrador para que desaparezca, y si se reinician para deshacerse de él (el Administrador de tareas está deshabilitado en todas las PC clientes), la máquina no abrirá el aplicación que se bloqueó por 15 minutos. Por supuesto, todo esto depende del tipo de usuarios con los que está tratando, ya que los usuarios más expertos técnicamente no aceptarían este tipo de sistema, pero después de intentar literalmente AÑOS para hacer que los usuarios se responsabilicen de los bloqueos y se aseguren de que el departamento de TI esté al tanto de Para solucionar el problema antes de que sea demasiado difícil de administrar, estos son los únicos pasos que funcionaron. Ahora,

"¡ATENCIÓN! ¡ATENCIÓN! ¡Si no lee el mensaje de error, MORIRÁ!"

A pesar de todas las recomendaciones en la respuesta aceptada, mis usuarios continuaron haciendo clic en el primer botón que pudieron encontrar. Así que ahora muestro esto:

El usuario debe elegir antes de que aparezca el botón Aceptar

Si selecciona la tercera opción, puede continuar; de lo contrario, la aplicación se cierra.