Saltar al contenido

Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores (heurística 10)

"Los mensajes de error deben expresarse en lenguaje habitual (no códigos o jerga), indicar con precisión el problema y sugerir constructivamente una solución." *

dos versiones de la pantalla azul de windows

Inclusive la tristemente famosa “Pantalla Azul de la Muerte” pudo mejorar en su capacidad de explicar qué sucedió y brindar ayuda al usuario sobre cómo seguir

Los usuarios se equivocan y cometen errores al interactuar con las interfaces que diseñamos. Las fuentes de estos errores son múltiples, e inclusive es interesante la discusión de si se tratan realmente de errores o solo de problemas de los sistemas , lo que implicaría que diseñadores y programadores traspasamos la responsabilidad de nuestras limitaciones a los usuarios bajo la categoría genérica de “errores”.

Pero desde el punto de vista del diseño el problema está allí y hay que darle una solución. La realidad es que es muy baja la probabilidad de que los usuarios recorran los flujos de interacción sin llegar a vías muertas o situaciones que requieran ir hacia atrás y realizar correcciones y cambios, y por tanto es imprescindible poner el foco en los mecanismos para realizar estas acciones, lo que genéricamente llamamos el sistema de manejo de errores.

Un buen sistema de manejo de errores debe mostrar con claridad que ocurrió un error y dónde ocurrió, explicar la causa y proponer un camino para resolverlo. Veámoslo en detalle.

Mostrar con claridad el lugar del error

El primer requisito para que el sistema de manejo de errores funcione es que sea capaz de alertar al usuario de que se requiere una acción correctiva para continuar. Tal vez cuando se trata de llenar un par de campos la solución es trivial, pero cuando los flujos de interacción dependen de datos que ingresó dos o tres diálogos más atrás y la información es cuantiosa, el problema cobra otro nivel de dificultad.

Sin embargo, la causa principal de dificultades en este punto parece ser la timidez de muchos diseñadores al diferenciar los diálogos que no tienen errores de los que sí los tienen. Los usuarios prestan muy poca atención consciente mientras interactúan, y están acostumbrados a las ventanas que explotan en su rostro, los banners enormes y todo tipo de mensajes agresivos que pueblan la selva de Internet, tanto en el navegador como en las apps. Un tibio subrayado o un mensaje pequeño, que muchas veces cae fuera del área visible pasan por tanto inadvertidos con mucha facilidad.

El sistema de errores debe ser eficiente para mostrar a nivel Miro y Entiendo que hay una situación de error, indicar si es solo uno o si se trata de varios errores, y señalar con precisión los lugares donde se cometieron o al menos un camino para acceder a ellos.

Conservar los datos

Son contados con los dedos de las manos los casos en que es justificado borrar los datos que ingresó el usuario. En general, sea cual sea el error, lo adecuado es conservar los datos erróneos y las decisiones inválidas del usuario, que serán muy probablemente el punto de partida sobre el que generará la nueva respuesta.

Las interfaces que quitan de los campos los contenidos inválidos son particularmente molestas.

Explicar la causa

La segunda tarea de un buen sistema de manejo de errores es explicar con claridad qué es lo que sucedió. Esto rara vez se puede realizar a nivel Miro y Entiendo, y requiere llegar a Leo y Entiendo, pero hay que evitar a toda costa el nivel Pienso y Entiendo.

Es una buena práctica trabajar sobre los mensajes y formas de explicar los errores junto con los diálogos y pantallas sin errores, y que sea el mismo diseñador que pensó el flujo de lo que está bien el que explica por qué las cosas salieron mal. El uso corriente de dejarlos para el final o muchas veces delegarlos en el área de desarrollo produce mensajes de error pobres e incluso crípticos, que poco tienen que ver con cómo el usuario percibe la interacción y brindan por tanto una ayuda pobre o nula.

El cajero automático es el líder absoluto en mensajes de error escuetos, inútiles e irritantes.

Un campo no es inválido, sino que el programa le exige un formato que el usuario no respetó. La primera es la perspectiva del sistema, la segunda es la del usuario. Siempre vale la pena de pensar la interfaz desde la segunda, y si consideramos que la probabilidad de que un usuario se tope con un mensaje de error es muy alta, más aún. (ver al respecto Prevenir los errores – heurística 5 )

Proponer una solución

La tercera y última tarea para un buen sistema de manejo de errores es proponer una solución al problema en cada caso, para todos y cada uno de los errores. No hacerlo supone de alguna manera cargar al usuario con el fardo, no solo mostrando poca empatía, sino además condenándolo a invertir un esfuerzo enorme en encontrar una solución que se podría haber incluido con muy poco esfuerzo de diseño.

El abanico de las situaciones de error es inabarcable, y va desde nimiedades hasta problemas que supondrán semanas de trabajo, pero el criterio es el mismo para todos: las dificultades deben surgir de la tarea, no de la interacción con la interfaz, y para ello los diseñadores de las interacciones debemos intentar siempre ponernos en los zapatos de los usuarios y bajar los niveles de dificultad de las interfaces que diseñamos.

Por ejemplo, son muchísimos los casos en que agregar un vínculo a la ayuda, explicación o diálogo para corregir el error resuelve la mitad o más del problema. Y sin embargo es menos frecuente de lo esperable la presencia de ese sencillo vínculo.

Mostrar ejemplos

Una de las recomendaciones más sencillas es mostrar ejemplos de las soluciones correctas o de las correcciones a realizar. En vez de explicar hablando de números de dígitos, caracteres especiales, rellenado con ceros, y caracteres alfanuméricos (todos términos habituales de la jerga del programador) mostrar un par de ejemplos como 2.345.678-9 o 0001-00219929 pueden resolver el problema rápidamente y con poco esfuerzo.

Hay muchas guías detalladas para el manejo de errores que profundizan en estas ideas, como por ejemplo la incluida en el capítulo 6 de Miro y Entiendo. Guía práctica de Usabilidad Web. Todas ellas son valiosas, todas ellas son útiles, y sobre todas las cosas, todas ellas siguen la idea de los tres requisitos: mostrar con claridad el lugar del error, explicar la causa y proponer una solución.


* En base a: “Heuristic evaluation of user interfaces” Nielsen, J., and Molich, R. (1990) Traducido y adaptado por Concreta

___

Taller Intensivo de Diseño de la Interacción

En 5 semanas, a través de 1 proyecto práctico de 4 etapas y mucha, mucha iteración podés dar un salto en tu formación como Diseñador de Experiencias de Usuario.

Próximo comienzo: 2 de marzo de 2021
Consultas: capacitacion@concreta.com.uy

Inscripciones abiertas.