Intencionalidad en Experiencia de Usuario

by Fabio Devin in Experiencia de Usuario

This article is available in English at Intentionality in User Experience. Empathize with your users

(Nota: esta nota no tiene nada que ver con el concepto de intencionalidad manejado por sitios de auto-ayuda o mejoramiento personal)

Una de las palabras o concepto más comunes cuando estamos creando un caso de usuario o flujo es intención, o intencionalidad. Por supuesto, esto es completamente lógico ya que cada vez que creemos un modelo de caso de usuario (por caso, usando UML), sí o sí vamos a considerar actores, y esos actores van a tener roles que van a estar determinados por su intencionalidad. ¡Como podemos ver, no hay forma de evitarlo!

Sin embargo, es muy común ver cómo se ignora la intencionalidad del usuario en favor de un supuesto (o real) beneficio del cual el usuario puede no ser consciente.

Un ejemplo concreto es cuando un usuario se registra en un sitio, servicio o aplicación. La intencionalidad del usuario es usar el sitio o servicio, la intencionalidad de nuestro usuario interno o stakeholder es recabar datos sobre dicho usuario. Y ahí viene el problema: ya hemos logrado que el usuario use nuestro servicio, lo cual es muy difícil, y de repente empezamos a pedirle datos y datos que quizás el usuario no esté dispuesto a dar hasta no saber si el servicio le sirve. Lo que va a suceder es que aproximadamente 50% de esos usuarios que tanto nos costaron lograr desistan de usar nuestro servicio o aplicación. Y del 50% restante, hasta un 80% usará la aplicación una sola vez, porque no era lo que buscaba.

Para algunas personas, muy especialmente ejecutivos de marketing, la información provista por el usuario es muy valiosa (y claro que lo es), pero el hecho concreto y efectivo es que si 100 usuarios registrados nos costaron $100 cada uno, de repente se transformaron en $1000 cada uno. Y si el costo de adquisición aumenta 10 veces, estamos en serios problemas.

Por supuesto, el caso anterior es uno de tantos. Si quieren verlo en la realidad, prueben la aplicación Asana Rebel: primero el usuario deberá completar una serie de preguntas, y recién después de contestarlas, les va a salir el costo, el cual puede o no ser para lo que queríamos, ya que no tenemos idea de qué trata la aplicación. Este proceso conocido como progressive engagement es de gran utilidad cuando se usa bien, pero más a menudo es una forma de dark pattern.

Entonces… ¿qué hacemos con la intencionalidad?

Si conocen los procesos de la Teoría de Decisión, o modelos UML o similares, van a darse cuenta que en realidad la intencionalidad nos va a simplificar todo de una manera casi increíble. Una especie de Navaja de Ockham de la Experiencia de Usuario. La Navaja de Ockham o principio de parsimonia dice : En igualdad de condiciones, la explicación más sencilla suele ser la más probable. En nuestro principio de intencionalidad, podríamos decir: En igualdad de condiciones, la acción o deseo más sencillo suelen ser los correctos.

Para que se entienda: las acciones, intenciones y deseos de un usuario pueden ser casi infinitos en una ronda de discusión UX (aquellos que usen metodologías Agile sabrán a qué me refiero). Pero si el caso de usuario es “pagar una cuenta”, entonces sabemos que el camino más corto y directo a realizar dicha acción es… pagar una cuenta. De esa manera, acciones adicionales relacionas a dicho proceso no serán divergentes, sino convergentes.

Un ejemplo muy concreto está dado en Diagramas de Flujo de tareas: Ejemplo Práctico: allí podrán ver como la intencionalidad logra un flujo de tareas muy superior al existente en el caso a mejorar. Con sólo ver el diagrama van a notar que los pasos y opciones son realmente muy pocos y así y todo realiza la misma tarea que realiza el proceso con múltiples procesos divergentes, pero de modo más eficiente, efectivo y directo.

Si tomamos la Ley de Hicks:

El tiempo que lleva tomar una decisión aumenta con el número y la complejidad de las opciones.

es fácil ver que mientras más opciones tengamos, más tiempo nos va a costar que el usuario tome una decisión. Más aún, de acuerdo a estudios que bucean entre la relación de la Ley de Hick y el índice de coeficiente intelectual, la decisión no sólo tomará más tiempo, sino que se incrementarán las posibilidades de que el usuario cometa uno o más errores (nuevamente, esto es usado por algunos como un dark pattern lamentablemente).

Pero nosotros no queremos generar patrones oscuros ni engañar a nuestros usuarios. Lo que queremos es generar la mejor experiencia posible para no frustrar a nuestros usuarios y eventualmente perderlos. Por lo cual, volvemos al ejemplo citado anteriormente: pagar una cuenta. El usuario sólo quiere pagar una cuenta. No necesita hacer absolutamente nada más, y ciertamente no quiere comprar otro servicio (en serio: con la carga cognitiva de pagar una cuenta ¿todavía hay gente que cree que quieren aumentarla gastando aún más?). ¿Qué hacemos entonces? Pues….

bienvenido --> ¿qué desea hacer? [presenta opciones] --> ingrese sus datos --> su saldo es $$ --> elija medio de pago --> pagar.

Y listo. Como puede verse, a partir de la presentación de opciones determinamos la intencionalidad y presentamos al usuario un proceso lineal y sin complicaciones ni carga cognitiva. ¿Simple? Pues bien, una amplia mayoría de los procesos remotos o incluso algunos presenciales no logran acertar con esta simpleza.

Resumiendo

Reconocer la intencionalidad del usuario nos permitirá generar más confianza en el mismo, conservarlo por más tiempo y ahorrar tiempo y dinero al no desarrollar procesos complejos innecesarios, inefectivos y con una carga negativa fácilmente demostrable.