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

Siempre tendrá un porcentaje significativo de usuarios que ignora muchos o todos los mensajes de error. Incluso cuando llaman al soporte técnico, tienen el mensaje de error frente a ellos y afirman haberlo leído, es muy posible que no hayan asimilado el contenido del mensaje. Por lo tanto, debe esforzarse mucho para evitar tener que colocar un cuadro de diálogo de error.

Además del consejo dado en Acerca de la cara (vea la respuesta de Aaron Lerch), es una buena idea registrar todos los mensajes de tal manera que puedan ser inspeccionados después. No confíe en que el usuario sepa lo que dice el mensaje de error, o incluso qué botón presionó para deshacerse del cuadro de diálogo.

Si los usuarios no son técnicos, sugeriría uno de dos enfoques:

1. Solo deles información de contacto para hablar con alguien. Básicamente, elimine la oportunidad de que incluso intenten solucionar el problema porque si no son lo suficientemente hábiles como para seguir las instrucciones, no importa cuán fácil las haga, no se moleste en dárselas. Dales un número de ayuda 1-800 o correo electrónico en el que se pueda hacer clic o algo así.

2. Si realmente debe darles instrucciones, entonces deben ser no técnicas (también escritas por su Madre, suponiendo que su Madre no sea técnica). Incluso el ejemplo que da "No se puede conectar al servidor. Compruebe su conexión a Internet". podría ser demasiado técnico para el usuario doméstico informal. ¿Cómo verifico mi conexión a Internet? ¿Cuál es mi conexión a internet? Recuerde, estas son personas que llaman a la computadora la "máquina" y al monitor la "televisión". Muéstreles fotos, explíquelas en términos simples, etc. Es mejor conseguir a alguien que no sepa nada sobre computadoras, si va a seguir esta ruta, la documentación de muestra o la información de error que planea presentar y ver si comprende (Yo llamo a esto la prueba de la suegra, si ella puede entenderlo, cualquiera puede).

Para que la gente lea el mensaje importante que tiene en mente, primero debe buscar en la aplicación todos los mensajes sin valor, "¡Comuníquese con su administrador (que en realidad no existe)!" y eliminarlos o reemplazarlos con información honesta. Una vez que se haya eliminado el ruido del flujo de mensajes, pasarán meses antes de que la base de usuarios notará que la relación ruido/mensaje ha mejorado hasta el punto en que es útil volver a leer los mensajes.

¡Ubicación, ubicación, ubicación!

Asegúrese de que el mensaje de error se encuentre en una ubicación que, por un lado, no perturbe el flujo de trabajo, pero por otro, se note fácilmente.

Si el mensaje está en el medio de la pantalla y bloquea el acceso al formulario principal, el usuario lo cerrará de inmediato, probablemente sin leerlo, pero si no grita, es posible que el usuario ni siquiera lo note.

(Parece que algo de lo que tengo que decir aquí fue respondido por otros antes de publicarlo; alguna buena información arriba, particularmente el Sr. Lerch).

Creo que la desafortunada respuesta rápida es "No lo harán". De manera similar al fenómeno de los usuarios que poseen manuales de productos pero se niegan a abrirlos, un mensaje repentino, sorprendente y fuera de contexto (bueno, al menos para el usuario base) será repentino, sorprendente y fuera de contexto. .

Dejando de lado mi pesimismo, he encontrado un éxito anecdótico con el espíritu de sus sugerencias. WRT el primer punto, estoy de acuerdo con "corto" pero no tanto "preciso". El usuario no técnico tendrá problemas con cualquier mensaje de error. Un mensaje "preciso" aún más, porque el usuario no técnico necesita no menos información, sino más (es decir, necesita un poco de educación) para comprender realmente lo que sucedió.

Como ejemplo, en el segundo punto, el usuario no técnico tendrá problemas con la primera parte de su mensaje de muestra.

• ¿A qué se conecta?
• ¿Que servidor?
• ¿Por qué es incapaz?
• ¿Hice algo mal?
• ¿El software hizo algo mal?

Algunas o todas estas preguntas pasarán por su cabeza antes de que realmente comprendan la respuesta sugerida. Cuando recuperen la compostura y lean la segunda parte, tendrán otra serie de preguntas sobre cómo verificar su conexión a Internet. Algunos lo interpretarán como un problema de módem o enrutador y apagarán toda la pila (no es broma).

Un montón de esto no es realmente solucionable en el mensaje de error; las personas tienen un nivel de conocimientos informáticos y su aplicación probablemente no tendrá un impacto significativo en eso. Pero si tuvieras que

• Proporcione primero una oración tan simple que pueda explicar por qué están viendo el mensaje. 5-7 palabras.
• Use un lenguaje simple y conversacional para explicar con un poco más de detalle.
• Ofrecer (si es culpa del sitio) una disculpa
• Encuentre una manera inteligente de decirles que no se asusten
• Asegúreles que las cosas mejorarán

puede hacer que la experiencia sea un poco más placentera.

Tenga en cuenta que los últimos son fáciles de equivocar y terminan sonando condescendientes, así que tenga cuidado y pruebe primero con algunos amigos.

Haga que sean relevantes, concisos, simples en inglés y ubicados en una ubicación no muy lejos de donde el usuario está buscando. Explica qué sucedió y por qué sucedió, pero sin demasiada palabrería. Finalmente, pruebe o realice un prototipo de los estados de error de su aplicación, así como de otras partes. A menudo olvidamos y solo hacemos que los usuarios recorran un proceso antes de que hayamos incorporado todo nuestro manejo de errores, y eso deja de validar una parte crítica y posiblemente frustrante de la experiencia.

Visualmente, haga que se destaquen de otros elementos de la interfaz. La animación puede ayudar a crear conciencia; Técnica de desvanecimiento amarillo es un gran ejemplo de eso.

Gran parte del mejor consejo ya ha sido presentado. Quiero agregar que los mensajes de error deben estar en línea con el tono del resto del contenido de la interfaz. http://www.visual-ii.com/ , que tiene una sensación muy conversacional, un poco nerd y cuyo banner de la página principal dice "Uncomplexification", ha creado una página de error 404 en línea con su poco nerdy base: http://www.visual-ii.com/404 .

Para los errores de tipo de excepción no manejados, que son raros pero fatales cuando se ejecuta la aplicación, se nos ocurrió un cuadro de diálogo de error que tiene tres botones:

• 'Copiar al portapapeles'. Esto copia los detalles del error en el portapapeles como texto. Se supone que el usuario lo usará para enviar un correo electrónico al soporte técnico o para pegarlo en el Bloc de notas.
• 'Enviar reporte de error'. Envía los detalles del error al soporte técnico por correo electrónico. Este es el botón predeterminado.
• 'Cerca'. Cierra el diálogo. Este botón se deshabilita intencionalmente durante 10 segundos o hasta que el usuario haga clic en una de las acciones anteriores. La cuenta regresiva se muestra en la etiqueta del botón.

Como medida de seguridad, también registramos el mensaje de error en un archivo de texto local, en caso de que el usuario no realice ninguna acción, que luego puede ser inspeccionada por el soporte técnico en otro momento.

Cuando una aplicación da mensajes de error que son útiles para ayudarme a resolver el problema, los leo. Si una aplicación (o proveedor) tiene reputación de tener mensajes de error que no son útiles, dejo de leerlos.

Haga que NO parezca un mensaje de error.

No use alertas ni nada que deba cerrar con un botón. Errores de pago en un espacio estático reservado para ese fin (consulte webapps, paneles de administración de CMS, etc.)

Utiliza un lenguaje simple y divertido.

En lugar de "error interno del servidor 500" intente "Vaya. Parece que no esperábamos esa entrada. Es posible que desee volver y ver si pone algo inusual en el formulario".

En lugar de "error al inicializar el dispositivo" intente "No pudimos usar su [dispositivo, por ejemplo, módem GPRS]. ¿Está todo bien? Verifíquelo y vea qué hay en la configuración".

Utilice un efecto de caja de luz de reducción animada que centre la atención en el mensaje de error, junto con cualquier parte relevante de la pantalla. Tenga un texto que diga "(Haga clic aquí para eliminar el mensaje de error)" en lugar de un botón.

Si desea que le envíen datos sobre el error, incluso con sus entradas, dígalo. Use la palabra "necesidad". "Aquí hay datos sobre este error que necesitamos. Algunos de ellos pueden referirse personalmente a usted. Haga clic en -> aquí <- para enviárnoslo".

Hay toneladas de investigaciones que muestran que muchos usuarios finales no técnicos pedirán ayuda a alguien a su lado, o soporte técnico, en lugar de tratar de resolver los problemas por sí mismos. Esa es la naturaleza humana, y no estoy seguro de que podamos evitar eso. Pero los mensajes de error tienen una mala reputación entre los usuarios no técnicos que debemos superar.

Además de los puntos que mencionó anteriormente, asegúrese de que su mensaje de error sea:

• Claramente visible. Si es crítico, se debe requerir al usuario que interactúe con el mensaje antes de reanudar la interacción con la aplicación.
• Escrito en un tono amigable, casual, con lenguaje no técnico. Por ejemplo: mira los mensajes de Firefox.
• Proporcione una descripción concisa pero clara del problema y por qué ocurrió.
• Proporcione instrucciones claras para solucionar el problema y un enlace al lugar de inicio (si es posible).
• Inevitable. Es mucho mejor prevenir el error del usuario que intentar escribir un mensaje de error efectivo.

Uno de los medios más efectivos para mostrar una alerta de error es:

1. Coloque la nota de error al lado del elemento con el que el usuario puede interactuar para realizar la corrección
2. Desplace la página para enfocarse en el elemento y la nota de error
3. proporcionar una breve animación (movimiento del cuadro de nota de error) para llamar la atención del usuario cuando la página ya está centrada en el área del problema (por ejemplo, formularios cortos)

Esto orienta al usuario a la acción correctiva de una manera útil y no amenazante, pero también insistente.