user-interface - practicas - ux error messages

¿Cómo hacer que los usuarios lean los mensajes de error? (26)

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 y esclarecedores, sino que simplemente haga clic en el primer botón disponible con un encogimiento de frustración.

Entonces, me pregunto qué buenas prácticas puedes recomendar para ayudar a los usuarios a leer tu mensaje de error, en lugar de simplemente descartarlo. Las ideas en las que puedo pensar caerían en la línea de:

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

Edición: 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 estrecha). Se pidió una forma más genérica de esta pregunta en slashdot , por lo que es posible que desee verificar algunas de las respuestas.

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

¿Qué tal hacer que el botón indique "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.

A menos que pueda proporcionarle al usuario algunas soluciones simples, no se moleste en mostrarle al usuario un mensaje de error. No tiene sentido, ya que al 90% de los usuarios no les importará lo que diga.

Por otro lado, si realmente puede mostrar al usuario una solución útil, entonces una forma de forzarlos a leer es hacer que el botón Aceptar se habilite después de 10 segundos más o menos. Más o menos como lo hace Firefox cada vez que intentas instalar un nuevo complemento.

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

" Lamento haberlo arruinado, nos gustaría enviarle información sobre este accidente, ¿nos permitirá hacerlo? SÍ / NO "

Además, trate de no hacer que sus mensajes de error sean más largos que una oración. Cuando las personas (incluido yo) vemos un párrafo entero hablando sobre el error, mi mente simplemente se apaga.

Con tanta sobrecarga de información y medios sociales, la gente se congela cuando ven un muro de texto.

EDITAR:

Recientemente, alguien también sugirió usar tiras cómicas junto con cualquier mensaje que quieras mostrar. Tal como algo de Dilbert que puede estar cerca del tipo de error que pueda tener.

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.

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

El usuario tiene que hacer una elección antes de que aparezca el botón Aceptar

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

Agregar un botón "Avanzado" que habilite algunos detalles más técnicos proporcionará un incentivo para leerlo para la parte del público objetivo que se considera a sí misma como técnica.

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

El objetivo real, sin embargo, debería ser diseñar su aplicación para que los usuarios no puedan cometer errores. No permita que realicen acciones que den lugar a masajes erróneos y solicite una copia de seguridad. Como ejemplo simple, en un formulario web que requiere que se rellenen 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 todo el campo contenga contenido válido. Significa más trabajo en la parte posterior, pero da como resultado una mejor experiencia de usuario.

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

Un buen mensaje de error debe contener:

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

Una de las peores cosas que puede hacer es simplemente pasar los mensajes de error del sistema a los usuarios. Por ejemplo, cuando su programa Java arroja una excepción, no pase simplemente el programador-ese a la interfaz de usuario y 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 recursos limitados), siempre acudían a mí, me explicaban qué necesitaban y me dejaban crear un mensaje de error que fue claro y siguió el estilo de la compañía. Si esa era la mentalidad predeterminada de cada programador, el mundo de la computación sería un lugar mucho, mucho mejor.

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

Por ejemplo, escribí una aplicación que permitía a nuestra gente de HR hacer un mejor seguimiento de las fechas de contratación / incendio de los empleados. [Éramos una compañía pequeña, muy relajada].

Cuando ingresaron fechas incorrectas, escribí:

¡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 tratar de averiguar qué ingresaron y si ingresaron "blahblah" para mostrar un error. Sin embargo, esta era una aplicación muy pequeña para una persona de recursos humanos que conocía personalmente. De ahí que otra vez personas, lea la primera línea de esta publicación: Dependiendo de su base de usuarios ...

Recientemente trabajé en un proyecto de Art Institute, por lo que los mensajes de error se dirigieron a la audiencia, como:

La mayoría del arte antes del 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 ajústelo a su audiencia si es posible, y evite aburrir como todos los errores generales sobrenaturales como: "por favor, introduzca el correo electrónico" o "por favor, introduzca un correo electrónico válido".

El mejor diseño de interfaz de usuario será donde prácticamente nunca se 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 acribillas al usuario con diálogos sin sentido como esos, estás entrenando explícitamente para que ignoren tus mensajes.

En mi opinión y experiencia, son los usuarios avanzados quienes no leen los mensajes de error. La audiencia no técnica que conozco lee todos los mensajes en la pantalla con mucho cuidado y el problema en este momento es principalmente: no lo entienden.

Este punto puede ser la causa de su experiencia, porque en algún punto 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 autorizada: 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 ponerse en contacto con el desarrollador o administrador para resolver el problema). Lo siento por los inconvenientes ocasionados.

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

No coloque mensajes de error en la barra de estado, nunca los leerán, a pesar de tener jazz con colores, etc. ¡Siempre los extrañarán! No importa cuánto lo intente ... En una etapa durante la prueba de interfaz de usuario Win 95 antes de que se iniciara, MS llevó a cabo un experimento para leer la IU ( ed - debe tenerse en cuenta que el mensaje explícitamente establecido en el contexto de ''Mire debajo de la silla'' ), con un billete de $ 100 pegado a la parte inferior de la silla sobre el 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á en exceso ...
No importa cuánto lo intentes, no uses colores para identificar el mensaje ... psicológicamente, ¡es como agitar una bandera roja al toro!
¡Use palabras que suenen neutrales para transmitir una reacción mínima y cómo proceder!
Puede ser mejor mostrar un cuadro de diálogo que liste el mensaje de error neutral e incluir una casilla de verificación que indique "¿Desea ver más mensajes de error en el futuro?", Lo último que desea un usuario final es estar trabajando en el medio del software que será bombardeado con mensajes emergentes, ¡se frustrarán y la aplicación los desconectará! Si la casilla de verificación estaba marcada, regístrese en un archivo en su lugar ...
Mantenga informados a los usuarios finales de los mensajes de error que habrá ... lo que implica ... capacitación y documentación ... ahora este es un truco difícil de transmitir ... no quiere que piensen que lo hará ser ''problemas'' o ''fallas'' y qué hacer en caso de que ... no deben saber que habrá posibles errores, de hecho difíciles.
Siempre, siempre, no tenga miedo de pedir retroalimentación cuando sucede algo sin incidentes, como ''Cuando apareció ese número de error 1304, ¿cómo reaccionó? ¿Cuál fue su interpretación? - la ventaja con eso, el usuario final puede darle una explicación más coherente en lugar de ''Error 1304, objeto de base de datos perdido!'', Sino que puede decir ''Hice clic en esto y entonces, entonces alguien tiró accidentalmente del cable de la red de la máquina '', esto le dará pistas sobre cómo lidiar con eso y puede modificar el error para decir'' Ooops, conexión de red desconectada ''... se entiende.
Por último, si desea dirigirse a audiencias internacionales, tenga en cuenta la internacionalización de los mensajes de error; de ahí que sea neutral, porque entonces será más fácil traducir, evitar sinónimos, palabras de jerga, etc., lo que haría la traducción no tiene sentido - por ejemplo, ~~Fiat~~ Ford, la compañía automotriz estaba vendiendo su marca ~~Fiat~~ Ford Pinto, pero notó que no había ventas en Sudamérica, resultó que Pinto era una jerga para ''pene pequeño'' y por lo tanto no tenía ventas ...
( ed ) Documente la lista de mensajes de error esperados 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 opinión, mantenga los mensajes amables, 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 quien mencionó otro punto extremadamente vital también!

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 de ayuda o al equipo de desarrollo.

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

Editar # 3: ha destacado por ed para indicar adiciones o adiciones y acreditado a otros por sus entradas ...

Editar # 4: En respuesta al comentario de Ken, esta es mi opinión ... No, no lo es, use colores estándar de Windows neutrales ... ¡no vaya por colores llamativos! Siga el color gris normal con texto negro, que es una guía GUI estándar normal en las especificaciones de Microsoft ... consulte las Pautas UX ( ed ).

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

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

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

Crea un cuadro de mensaje personalizado . Nunca use el cuadro de mensaje predeterminado del sistema, por ejemplo, los cuadros de mensaje de Windows XP son molestos por sí mismos. Cree un nuevo cuadro de mensaje de color, con un color de fondo diferente al predeterminado por el sistema.

Muy importante: no insistas . Algunos cuadros de mensaje usan el diálogo modal e insisten en hacer que lo leas, 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 en la parte superior de la página, informando pero no molestando.

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

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

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

Hemos descubierto que la única forma de hacer que los usuarios asuman la responsabilidad por los errores es dándoles una multa por forzar el error a desaparecer. 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 reinician para deshacerse de él (el Administrador de tareas está deshabilitado en todas las PC del cliente) la máquina no abrirá el aplicación que se estrelló durante 15 minutos. Por supuesto, todo esto depende del tipo de usuarios con los que se trate, ya que los usuarios técnicamente más expertos no aceptarían este tipo de sistema, pero después de intentar literalmente AÑOS hacer que los usuarios asuman la responsabilidad de los fallos y asegurarse de que el departamento de TI esté al tanto con el fin de solucionar el problema antes de que sea demasiado difícil de administrar, estos son los únicos pasos que funcionó. Ahora, todos nuestros usuarios finales son conscientes de que si ignoran los errores, van a sufrir por ellos mismos.

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 perpatrators.

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

Muestre a los usuarios que el mensaje de error tiene un significado , y es una manera de brindarles ayuda y ellos lo leerán. Si se trata de un simple mensaje genérico o un disparate 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 acciones predeterminadas para enviar información de diagnóstico detallada (por ejemplo, por correo electrónico); si responde rápidamente a esos correos electrónicos con información valiosa o solución alternativa, lo adorarán.

Esta es también una gran herramienta de aprendizaje. En versiones futuras, puede resolver problemas conocidos o, al menos, proporcionar información sobre soluciones in situ. Hasta entonces, los usuarios aprenderán que este mensaje es causado por X y el problema puede resolverse con Y, todo porque alguien se los explicó.

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

EDITAR:

Como tiene una amplia base de usuarios, le recomiendo que proporcione un software que haga lo que los usuarios son / pueden esperar que haga, por ej. no les muestre el mensaje de error si el número de teléfono no está bien formateado, reformatee 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, proporcione un mensaje muy bien escrito (y revisado por usuarios reales).

Es un conocimiento común que las personas no leen la documentación (¿leyeron las instrucciones consecutivas cuando encendieron el electrodoméstico?), Intentan obtener resultados rápidamente, cuando fallan deben llamar su atención (ej. 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.

Para comenzar, escriba mensajes de error que los usuarios realmente puedan entender. "Error: 1023" no es un buen ejemplo. Creo que es mejor registrar el error que mostrarlo al usuario con un código "sofisticado". 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 muestres información que no puedan usar. Si es posible, proporcione una solución para el error. Si no proporciona una ruta predeterminada, debe tomarse.

Si su aplicación es una aplicación web, es una buena idea diseñar páginas de error personalizadas. Acentúan menos a los usuarios, toman 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/

Ponemos un gráfico simple y memorable en el cuadro de error: no es un ícono, un mapa de bits bastante grande y nada parecido a los íconos de mensaje estándar de Windows. Nadie puede recordar el texto de un 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 RECUERDA la imagen que vieron. Entonces, nuestra gente de apoyo puede preguntar al cliente "¿viste al tipo que bebía café?" o "¿viste el escritorio vacío?". Al menos de esa manera, sabemos aproximadamente qué salió mal.

Respuesta corta: no puedes.

Respuesta menos breve: haz que sean visibles, relevantes y contextuales (resalta lo que han estropeado). Pero aún así, estás luchando una batalla perdida. Las personas no leen en las pantallas de las computadoras, las escanean y se les ha capacitado para hacer clic en los botones hasta que desaparecen los cuadros de diálogo.

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

Si realmente necesita forzar a los usuarios a leer lo que está mostrando, sugeriría una Cuenta atrás de JavaScript hasta que se pueda hacer clic en un botón. De esta forma, el usuario utilizará el tiempo de espera para leer realmente lo que se supone que debe hacer. Sin embargo, ten 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 "leer más", aunque dudo que los usuarios se interesen más y solo deseen deshacerse del mensaje por todos los medios ...

Solo para que conste: hay usuarios que SI leen mensajes de error pero tienen tanto miedo de no hacer nada con ellos. Una vez tuve una llamada de soporte técnico 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 ''Aceptar''", respondió. ... mmh, difícil :)

Sugiero que den su opinión (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 es 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 "forma"), muestro un "resumen de error", explicando que Hubo errores y una lista con viñetas de qué exactamente sucedieron los errores. Sin embargo, si hay más de 5-6 palabras por mensaje, no serán leídas / entendidas.

Un buen consejo que aprendí es que deberías 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.

Primero debe escribir las cosas más importantes para leer, 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 forma, el usuario puede leer todo lo que quiera, o moleste, y aún así tener una idea de lo que se está preguntando.

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.

Vea también las respuestas del usuario de Slashdot here .

Hazlos divertidos . (Parecía relevante, dado el sitio en el que estamos) :)

Menos errores

Si una aplicación te vomita regularmente, te vuelves inmune a ella y los errores se vuelven molestos. Si un error es un evento raro, atraerá más atención.

Quosh cualquier cosa que no sea un problema importante, deseche todas esas advertencias, encuentre maneras de comprender la intención del usuario, tome las decisiones siempre que sea posible. Tengo algunas aplicaciones que continúo simplificando de esta manera. Los desarrolladores consideran que cada error es 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: breve, conciso, bajo factor de terror, sin signos de admiración. Los párrafos son fallidos .

No hay una solución mágica, pero es necesario ingeniárselas socialmente para que los errores sean importantes.