El usuario (II)

Recordemos la definición ad-hoc de usuario que había presentado en la primera parte de este artículo:

[...] es el que opera el sistema en una situación real para alcanzar un objetivo determinado que coincide con el que fue requerido al desarrollar el sistema.

Luego lo caracterizaba, un poco maliciosamente, diciendo que

El usuario es tonto o malicioso a menos que se demuestre lo contrario.

para luego mencionar algunas de las características más comunes que todos adoptamos cuando somos usuarios de un sistema:

• Distracción: no leemos, no miramos.
• Falta de memoria: no registramos nuestras acciones ni sus resultados.
• Descontextualización: no interpretamos lo que vemos en su contexto, sino que tendemos a trasladarlo literalmente al nuestro.
• Mecanicismo: repetimos secuencias automáticas de acciones mecánicas que nos han dado resultado.

El origen (siempre de acuerdo a mi modesto entender en estas cuestiones, de las que no soy un gran teórico) es que el usuario no está utilizando el sistema. ¿Cómo?

No. El usuario no utiliza el sistema. Nadie dice, "mi trabajo es utilizar un sistema" o "estoy un poco aburrido, voy a utilizar el sistema". El usuario quiere hacer otra cosa. Querrá pagar una factura, vender un boleto, consultar el horario de una película, actualizar el stock, divertirse...

Los seres humanos no somos demasiado buenos ejecutando varias tareas al mismo tiempo. Nuestro cerebro tenderá a siempre a concentrarse en aquélla que juzgue más importante o le demande más atención. No es ésta la verdad revelada, precisamente. Es, por ejemplo, la razón principal de que no utilicemos el celular cuando manejamos (no deberíamos, por lo menos) o de que apaguemos la radio del auto cuando nos perdemos. En estas conductas vemos otro punto sutil: tampoco somos muy buenos concentrando nuestra atención conscientemente. El celular y la radio nos distraen, aunque lo neguemos o querramos evitarlo.

Entonces el sistema es una herramienta que, si bien el usuario quiere o debe utilizar, lo distrae inevitablemente de su objetivo principal. Como no puede apagarlo hace lo que hace: le presta la menor atención posible. Cuando somos usuarios desarrollamos toda una serie de conductas que tienden a reducir al mínimo la cuota que nuestro cerebro debe dedicarle al sistema en sí.

Así que tenemos que estar conscientes de que cuando el sistema trata de atraer la atención del usuario está molestando. Siempre. Así que más vale que lo haga por algo importante.

Si están de acuerdo con en el razonamiento que me llevó a la frase anterior, tendrán que coincidir con que los errores respecto de este tema son muy, pero muy comunes en casi todo software:

Molestar con bobadas:

• Propaganda intrusiva e irrelevante, sobre todo en Internet. Si el usuario quiere leer el diario ¿por qué demoraría más de un segundo en cerrar esa imagen molesta que le impide hacerlo?

  Se me dirá que ese tipo de propaganda funciona. Es verdad. Funciona desde el punto de vista del anunciante, que actúa más o menos como un spammer: molesta a varios cientos de miles para alcanzar a ese par de decenas de usuarios que tienen algún interés en el producto o servicio promocionado.

  Por otro lado ¿no funciona mejor la propaganda contextual? Ese sistema se basa en lograr un encuentro entre lo que el usuario busca y lo que el sistema le ofrece. Si el usuario busca pasajes baratos, encontrará la frase "Viaje casi Gratis" así esté ubicada en el extremo inferior izquierdo de la pantalla, en azul con fondo negro y letra chica.

• Intentando meterse compulsivamente en lo que el usuario quiere hacer, o insistiendo en enseñarle lo que no quiere aprender. Software que parece un chico de 3 años que demanda atención o quiere demostrar que sabe. Que haga tal cosa si desea hacer tal otra, que mejor si lo hace así, que por qué no lo hace asá.

  El momento en que el usuario está utilizando el software para otra cosa no es precisamente el mejor para brindar capacitación.

  Hay que darle al usuario la posibilidad de que haga lo que quiera hacer de la manera en que lo desee. Lo divertido de los programas que cometen los errores mencionados (Microsoft se lleva las palmas, y el paquete Office el premio mayor) es que cuando el usuario realmente quiere propaganda o capacitación o consejos útiles o ayuda o información detallada no la encuentra, porque si el sistema no la ofrece automáticamente (y de forma molesta) no hay detective que pueda ubicarla.

Molestar con información a destiempo o fuera de contexto.

La medida de lo importante la da el objetivo del usuario: si el usuario está ingresando una factura, poco le importará que se ha ingresado un nuevo producto al stock, por más relevante que esto pueda ser para él en otro momento.

No saber atraer la atención del usuario cuando es necesario.

Si soy un contador y estoy apurado para cerrar ese balance con mi jefe mirando por encima del hombro, el mensaje "se está quedando sin espacio en la partición primaria de la unidad Z" titilando en letras rojas pasará absolutamente desapercibido, por más catastrófico que le pueda parecer a cualquier administrador del sistema.

Esto es un completo despropósito, sobre todo teniendo en cuenta que, en general, ése tipo de alarmas contiene un mensaje más pequeño a continuación, que usualmente reza "Guarde sus trabajo en una ubicación alternativa para evitar pérdida de datos".

¿Qué es más importante para el usuario y tiene más posibilidades de atraer su atención? ¿Que la unidad Z se queda sin espacio o que está a punto de perder su balance casi terminado?

Después el analista funcional no entiende cómo el usuario no vio eso.

Los mensajes tienen que estar orientados al usuario que los lee, y en lo posible (aunque ésto es mucho más difícil) relacionados con la tarea que está realizando. Una buena regla para la redacción de mensajes es que en vez de decirle al usuario lo que le pasa al sistema (que poco le importa) hay que decirle lo que a él le está pasando o le va a pasar.

Mensajes de error incomprensibles.

Este punto es típico, terriblemente típico (vinculé una linda colección de delirios en la entrada Mensajes de error), y que encima se nos vuelve en contra, porque aquí los que solemos quedar como idiotas somos nosotros, los desarrolladores.

Yo tengo dos reglas básicas:

• La primera es de redacción: el título del mensaje de error es siempre "No se pudo [hacer lo que el usuario iba a hacer]", en palabras del usuario: "No se pudo ingresar la factura", "No se pudo imprimir el tícket", etc. Un mal ejemplo es "El recurso de impresion \\ADMNET\Imp\EPS345 no está disponible".

  El detalle, más pequeño, tiene que responder siempre a la pregunta "¿por qué?", también en palabras del usuario. Es como un diálogo: título - ¿por qué? - detalle del error. "No se pudo cerrar el balance" (¿por qué?) "No hay espacio suficiente en disco". ¿Ven que queda mejor?

• La segunda tiene que ver con los errores no manejados, es decir, con los errores de programación. Cualquier intento de brindar información al usuario es peligroso, porque el sistema está en un estado desconocido, y puede pasar cualquier cosa (como muestran los ejemplos de la entrada anterior).

  Creo que lo mejor en este caso es el típico "Se ha producido un error inesperado" o algo así, y brindar un curso de acción (número de soporte, reintente tal cosa, pruebe tal otra). Pero ojo, no estupideces, sino cursos de acción razonables teniendo en cuenta que el usuario quiere completar una tarea. Es decir, llamar a soporte técnico es una opción, pero no la mejor en este sentido.

  Lo que voy a poner es brutalmente difícil, yo nunca lo implementé: pero si tengo un error inesperado, tengo que dar una solución de negocio de acuerdo a la operación que el usuario está haciendo. Ejemplo: si estoy en la carga de la factura, tengo que explicarle al usuario que tiene que verificar si se registró la factura ingresada, facturar a mano, y luego llamar a soporte o lo que sea. Es decir, primero le resuelvo el problema al tipo.

  Pero claro, lo anterior implica prácticamente un manual de incidencias para cada funcionalidad. Dije que era brutalmente difícil.

Una última aclaración: cuando el personal de soporte técnico está revisando la instalación, también es de alguna manera un usuario. Lo mismo cuando lo está instalando o cuando el administrador lo está configurando. Al igual que en los ejemplos anteriores, aquí también tenemos que utilizar el lenguaje del usuario, que en este caso es más técnico.

El mismo mensaje ambiguo de error inesperado que para el usuario común es más amable, para éste tipo de usuario es casi ofensivo, ya que la falta de información, que antes se traducía en simpleza, ahora le impide saber qué es lo que está pasando.

En general se utilizan ejemplos mencionando usuarios "comunes", pero no debemos olvidar que también hay usuarios u operarios (si les gusta la diferencia) que juegan un papel más técnico y que por ello deben recibir más información técnica. Como siempre, lo lógico, aunque también lo más difícil, es responder correctamente de acuerdo a la situación.

Para cerrar, digamos que es terrible crear un buen sistema que la pifie justo en el momento en que el usuario realmente lo está utilizando para algo. Y sobre todo si, como en el caso de los mensajes de error, es una cuestión fácilmente evitable durante el desarrollo. Simplemente es cuestión de pensar dos segundos antes de escribir esa frase maldita (o con faltas de ortografía) que nos hará quedar como bobos ante el cliente. ¿No vale la pena?