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

177

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.

F'x
fuente
12
wiki de la comunidad ....
jldupont
3
¿A qué público apuntas tu software? P.ej. pocas empresas o usuarios de internet? ¿Existe alguna relación que pueda establecer con los usuarios?
Janusz Skonieczny
@WooYek: Esa sería (en mi caso) una base de usuarios bastante grande, pero con un tiempo de uso limitado (es decir, no es un software que usa con tanta frecuencia, es más un "uso ocasional" con una gran base de usuarios posible).
F'x
@MikeJ ¿Quizás es la misma persona que publica la pregunta en varios sitios?
7wp
77
Estaba en el laboratorio de computación en la universidad. Alguien se sentó a mi lado e intentó iniciar sesión. Apareció el mensaje de error: "Contraseña incorrecta. Compruebe que no tiene activado el bloqueo de mayúsculas". Lo descartó sin leer y lo intentó de nuevo. Varias veces. Cuando me pidió ayuda, solo le dije que leyera el mensaje.
TRiG

Respuestas:

70

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

t0mm13b
fuente
1
Interesante sobre la barra de estado. Yo diría que las personas hacen notificación esas tiras de colores brillantes en la parte superior de una página web que indican, por ejemplo, "que acaba de ganar una buena respuesta insignia". Esto no es equivalente a la barra de estado, pero sí me dice que la posición y el color de fondo de un mensaje de error son factores importantes. Ah, y una pequeña nota ortográfica: es Fiat Punto. Pinto era un producto de Ford famoso por su tanque de gasolina montado en la parte trasera que a veces explotaba.
Evitaría
@DanM: ¡Dios mío! ¡tienes razón! Fue Ford ... ¿qué estaba pensando cuando escribí la respuesta ... sí, fue defo Ford Pinto! ¡¡¡Gracias por el aviso!!!
t0mm13b
@tommie, no te olvides de Nova (como en Chevy Nova). Se traduce a "No Go" o "Doesn't Go" en español
:-P
2
@DanM: corrigió eso - hey, esa es una interesante ... ¡ay! Suena como un automóvil de madera con ruedas de madera que van de madera .... :)
t0mm13b
Gracias por la muy buena respuesta!
F'x
16

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.

MikeJ
fuente
2
Un gran +1 para esto. Tenga en cuenta que la parte del desarrollador puede contener el seguimiento completo de la pila y otros detalles. Incluso puede capturar capturas de pantalla de la aplicación (especialmente para aplicaciones internas de WinForms) si lo desea.
TrueWill
Soy un poco reacio a considerar un buen consejo para "capturar capturas de pantalla de la aplicación": después de todo, suena como una seria fuga de datos privados (incluso si su aplicación nunca fue diseñada para manejar la información NS <nogrep> A-class en primer lugar ) ...
F'x
Creo que es más una decisión de negocios / política que deben manejar los usuarios del dominio que los aspectos técnicos de brindar un mejor soporte al tener soporte de diagnóstico de fallas de "recuadro negro". Esperaría que las aplicaciones LOB internas tengan diferentes preocupaciones / objetivos que las relaciones de soporte externo del cliente con información confidencial.
MikeJ
11

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.

Matt Garrison
fuente
Ese hábito de hacer clic en los cuadros de diálogo fue un problema real con el antiguo cuadro de diálogo de instalación de IE ActiveX.
Alex Jasmin
10

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.

Bob Moore
fuente
1
Mi problema con esa idea es que rompe la uniformidad de la interfaz de usuario que la gente espera. Además, ¿cómo pueden saber que el "escritorio vacío" es un tema más amenazante que el "chico que bebe café"?
F'x
Hacemos sistemas de un solo propósito (centros de control de emergencia), por lo que solo nos preocupamos por la uniformidad de la interfaz de usuario dentro de ese sistema. Ninguna jerarquía de amenazas está implícita aquí de todos modos. El propósito es simplemente ser memorable. Esos dos gráficos en realidad representan situaciones de inactividad similares (el operador se alejó del escritorio, el operador probablemente en el descanso), por lo que serían significativos ... pero ese no es su verdadero propósito. Solo queremos que sean memorables. Tal vez no debería mencionar el ratón bailarín :-).
Bob Moore
10

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

Jack Marchetti
fuente
Me recuerda el "consejo" en MS Word: correr con unas tijeras puede ser peligroso
MikeJ
77
aprende a ingresar una fecha !! - Claro, pero dame una pista. No debería tener que adivinar el formato adecuado.
Alex Jasmin
44
+1 para mensaje barroco, siempre estoy entretenido por este tipo de creatividad :)
medopal
2
No estoy seguro de que me guste mucho ese tipo de mensaje ... Después de todo, ¿por qué debería aprender cómo ingresar una fecha?
F'x
1
En lugar de exigir a los usuarios que descifren el formato de fecha, tómese un par de minutos adicionales y enseñe a su software a analizar las fechas en múltiples formatos. La computadora es inteligente: deje que ayude al usuario en lugar de golpearse las muñecas.
Bryan Oakley
10

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

medopal
fuente
1
1 y 3 son buenos. 2 es cuestionable, por razones de accesibilidad. Los controles estándar del sistema pueden manejarse especialmente. Tus variantes no pueden.
Phil Miller
1
@Novelocrat, las probabilidades son buenas de que si el resto de su aplicación es accesible, su diálogo de error personalizado también lo será. Y si el resto de su aplicación ya tiene problemas de accesibilidad, un diálogo más con problemas no importará.
Mike Daniels
@Novelocrat, estoy hablando principalmente de aplicaciones web, en lugar del cuadro de alerta de JavaScript predeterminado, puede crear un nuevo cuadro elegante y darle las mismas propiedades. Pero la misma idea podría aplicarse a las aplicaciones de escritorio si el propósito es forzar la lectura del mensaje
medopal
Lo mismo de Novelocrat, realmente no me gusta la parte de la respuesta "nunca use la interfaz de usuario del sistema". La gente quiere sentirse en territorio conocido.
F'x
Y también, la accesibilidad siempre es mejor para la interfaz de usuario del sistema.
F'x
8

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.

Bryan Oakley
fuente
6

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.

bl4ckb0l7
fuente
2
Y luego admin / helpdesk / etc escucha sobre el mensaje y pregunta "¿Qué demonios se supone que debo hacer al respecto?". Su segundo mensaje es genérico hasta el punto de inutilidad. En cuanto a lo primero, al no haber utilizado nunca el software de Oracle (adivinar basado en el prefijo), todavía puedo formular una hipótesis sobre lo que se supone que debo hacer al respecto.
Phil Miller
Bueno, el servicio de asistencia puede informar al desarrollador para solucionar el problema. ¿Le ayudaría al cliente o al servicio de asistencia escribir el mensaje técnico en el error? Todo lo que el usuario quiere saber en este momento es: qué sucedió y dónde puedo obtener ayuda, si no es un error que cometió (entrada incorrecta o algo así). Y no me malinterpreten, ese es, por supuesto, el mensaje en la capa de presentación. En los registros del servidor, hay un mensaje de error específico, que lo ayudará a solucionarlo.
bl4ckb0l7
1
@Novelocrat, precisamente. A menudo puede encontrar personal de soporte técnico gritando: "¡Pero soy el administrador del sistema y no tengo ni idea de cuál es el problema!" Será mejor que agregue una opción "muéstrame el technobabble" a sus errores.
Mike Daniels
el servicio de asistencia no puede proporcionar mucha ayuda cuando se trata de una aplicación comercial estándar y el error no contiene información útil.
Mike Daniels
5

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.

Janusz Skonieczny
fuente
2

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/

anthares
fuente
2

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.

marca
fuente
1
Algunas plataformas no te permiten hacer esto. Existen casi buenas razones para esas restricciones, también.
Phil Miller
Apoyo fuertemente el comentario de Novelocrat. Una interfaz de usuario estandarizada es buena para los usuarios (y, por lo tanto, buena para usted). Creo que seguir las etiquetas de los botones estándar logra algo que no desea perder, incluso para captar la atención (excepto quizás en casos extraordinarios).
F'x
No necesita utilizar alertas JS () para mostrar mensajes de error. Puedes construir tu propia ventana de diálogo. Además, el propósito de usar verbos en lugar de solo exclamaciones es porque si ve 'Ok' como un botón, tendrá que leer el contenido del cuadro de diálogo. El problema es que algunos usuarios no se tomarán el tiempo para hacerlo, por lo que simplemente harán clic en Aceptar. Si usa verbos para describir la acción, un usuario sabrá lo que está sucediendo sin leer el cuadro de diálogo.
Mark
Cerrar es un verbo. Lo usaste en tu propia oración; "para cerrar sus mensajes de error"
Ricket
Pero @ Mark, esta pregunta se trata de dejar que la lean: p
Bart van Heukelom el
2

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.

Lasse V. Karlsen
fuente
2

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

Jim
fuente
2

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.

7wp
fuente
1
Puede buscar una caricatura relevante de Dilbert aquí: bfmartin.ca/finder
SLaks
¿Diez segundos? Mire un reloj y cuente diez segundos. Es una eternidad cuando tratas de hacer un maldito trabajo.
Mike Daniels
1
Mike, estaba destinado a ser un ejemplo, no escrito en piedra. Elija el tiempo de espera que desee. Alternativamente, ¿alguna vez has instalado un adon de Firefox? ¿Esa cuenta regresiva realmente te molesta tanto? No he escuchado a mucha gente quejarse de eso.
7wp
@Roberto - hablando de la cuenta regresiva del complemento de Firefox ... eso me molesta. Solo quiero hacer clic en instalar. ¿Por qué necesito una cuenta regresiva cuando hice clic en instalar un complemento y ahora tengo que esperar 10 segundos para confirmar la instalación?
Mark
1
@Mark precisamente por la razón por la que se hizo esta pregunta de desbordamiento de pila. Demasiadas personas son felices y no se molestan en leer los mensajes y sus consecuencias y terminan haciendo algo que no querían. Mark, sabes y entiendes en lo que haces clic. Sin embargo, después de haber trabajado en el soporte técnico de HP en el pasado, hay personas que hacen clic en las cosas solo porque pueden. La demora obliga al usuario a detenerse y echar un vistazo al mensaje, en lugar de decir "sí, sí, lo que sea que haga clic en Aceptar, ya está"
7wp
2

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 :)

Seleccionar0r
fuente
11
Estas "cuenta regresiva de JavaScript" son lo más molesto que puedes hacer. El usuario odiará "tener que esperar un reloj para contar hacia atrás" y apenas enfocarse en el mensaje de error que en su enojo.
bl4ckb0l7
2

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.

Tyzak
fuente
3
¿Y las personas daltónicas?
Natrium
1
Como alguien daltónico, ni siquiera estoy seguro de cómo se ve el color "rojo".
MikeJ
El rojo no se interpreta universalmente como una alerta. Algunas culturas lo interpretan como felicidad, por ejemplo. Tenga en cuenta quiénes son sus usuarios potenciales al elegir los colores.
Bryan Oakley
1
@MikeJ: claramente, Tyzak debería hacerlo parpadear, en su lugar. Eso sería mucho más útil. Hay una diferencia en el valor (brillo) entre los campos que otras personas dicen que son 'rojos' y los que dicen que son claros, ¿no es así?
Phil Miller
hm, no pensé en daltonismo, ese es un buen punto. Sí, el color se interpreta universalmente (China, India). Depende de la audiencia, correcto.
Tyzak
1

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.

Chuck Martin
fuente
1

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.

Joel Goodwin
fuente
1

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.

repetición
fuente
1

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

Mel Gerats
fuente
0

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.

naivistas
fuente
Sus dos párrafos parecen contradictorios: dar retroalimentación inmediata, ¿pero reunirla al final de la página?
F'x
@FX, la idea era que hicieras ambas cosas: advertir al usuario de inmediato, pero, dado que aún podría ignorarlo, reúne todos los errores al final de la página.
naivistas
0

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

JonnyBoats
fuente
El punto es que los usuarios manejen los errores ellos mismos, al menos cuando sea posible. Tal botón sería una declaración de fracaso total de la intención.
Seether
0

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,

F'x
fuente
0

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

anon235370
fuente
0

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:

¡Lee esto!

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

Elige la opción correcta

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

hombre sonriente
fuente