Los usuarios no piensan en tareas

En pocas palabras: La teoría del establecimiento de metas muestra que la gente organiza su comportamiento en torno a resultados, no a tareas de interfaz. A los usuarios no les importa completar tu flujo a menos que los acerque al cambio que realmente quieren.

Has estado diseñando flujos: de tareas, de usuarios, de bienvenida. Has trazado cada paso, etiquetado cada pantalla y medido cada tasa de finalización. Cuando pasas suficiente tiempo mirando pasos, pantallas y puntos de abandono, resulta muy fácil empezar a pensar que el paso es la verdadera unidad del diseño. Normalmente no lo es.

Los usuarios no abren tu producto porque les importe completar tareas. Lo abren porque algo en su vida tiene que cambiar. Quieren sentir menos ansiedad por el dinero, mantener el contacto con quienes quieren o hacer algo para poder dejar de pensar en ello. A veces solo quieren enviar la factura, pagar el recibo, reservar el viaje y seguir con su día. Tu flujo solo ayuda con una pequeña parte de esa meta mayor. La tarea es el mecanismo. Lo que les importa es qué cambia para ellos cuando está hecha.

Las metas importan más que las tareas

En 2002, Edwin Locke y Gary Latham publicaron un resumen de 35 años de investigación sobre cómo las metas impulsan el comportamiento. Su conclusión era clara: las metas conscientes son la causa motivacional inmediata de la mayoría de las acciones humanas. Cuando la gente tiene metas claras y concretas, su comportamiento se organiza para alcanzarlas. Cuando no, va a la deriva.

La teoría de la autodeterminación de Richard Ryan y Edward Deci añade una capa más profunda. Las personas no solo se orientan a metas. Se organizan en torno a tres necesidades psicológicas fundamentales: autonomía (controlo mis acciones), competencia (mejoro en algo que importa) y vinculación (estoy conectado con otras personas). No son necesidades al nivel de una pantalla. Elegir una opción en un menú desplegable no es algo que la gente viva como un avance significativo en sí mismo. Estas necesidades están por encima del nivel de la tarea.

El diseño tiende por defecto al nivel de la tarea. El análisis de tareas descompone el comportamiento del usuario en acciones individuales y observables. Eso es útil. Se convierte en una trampa cuando completar algo se trata como éxito, en vez de como un paso hacia algo mayor.

El estudio de los batidos lo mostró

En la década de 1990, contrataron al equipo de investigación de Clayton Christensen para ayudar a una cadena de comida rápida a vender más batidos. El enfoque habitual habría sido preguntar a los clientes qué querían de un batido: sabor, espesor, precio. El equipo hizo otra cosa. Pasó un día en el restaurante observando cuándo se compraban batidos y quién los compraba.

Lo que encontró apuntaba más allá del batido. Casi la mitad de todos los batidos vendidos salía del local antes de las 9 de la mañana, comprada por personas que conducían solas. Los investigadores indagaron. ¿Para qué trabajo, preguntaron, estaban contratando estas personas al batido? La respuesta era el trayecto al trabajo: un viaje largo, una mano libre, algo que ocupara el tiempo y que también saciara hasta el almuerzo. El batido duraba, cabía en el portavasos y apenas exigía atención. La gente no solo compraba una bebida. Resolvía un problema de la mañana.

El equipo había estado preguntando por la bebida. Los usuarios intentaban resolver un problema del trayecto al trabajo.

Completar no es lo mismo que obtener valor

Puedes construir un producto en el que los usuarios completen todos los pasos y aun así se vayan. La mecánica funciona, pero la meta no se cumple. Se van no porque tu bienvenida esté rota, sino porque el cambio que querían en su vida nunca llegó.

Esta distancia aparece en aplicaciones de ejercicio donde registrar los entrenamientos es fácil, pero la gente deja de entrenar. También en herramientas de presupuesto donde clasificar movimientos es rápido, pero los usuarios siguen sintiendo que no controlan sus finanzas. La ves en programas de gestión de proyectos donde se puede asignar cada tarea y fijar cada fecha, pero la gente sigue sintiéndose desorganizada. El producto funciona al nivel de la tarea. El resultado que la gente buscaba sigue sin llegar.

El marco de análisis de tareas de Nielsen Norman Group es explícito sobre esta distinción: una tarea es una actividad observable con un inicio y un final, y difiere de una meta. Rellenar un formulario es una tarea. Conseguir que aprueben un préstamo es una meta. La meta es aquello para lo que el usuario contrató el producto. El formulario es solo el mecanismo.

Empieza por la meta

No dejes de trazar flujos. Los flujos son útiles. Solo tienes que nombrar la meta antes de dibujar el primer recuadro.

No el objetivo de una tarea dentro de la interfaz. No «completar la compra» ni «crear una cuenta». Su meta en la vida. ¿Qué cambia en su vida si tu producto funciona? ¿Qué cosa concreta intenta cambiar, evitar o conseguir? Escríbelo en una frase y hazlo concreto. Después mira tu flujo y haz una pregunta directa: ¿cada paso acerca al usuario al objetivo de esa frase o sirve principalmente a las necesidades del producto?

Haz esa comprobación antes de cualquier decisión importante de diseño. Pregunta si cada función sirve a la meta, no solo al flujo. Después pregunta si tu tasa de finalización del 90% significa que los usuarios consiguieron realmente lo que buscaban. Esa pregunta se omite más de lo que debería.

Los diseñadores que se quedan al nivel de la tarea pueden construir productos que funcionan y aun así fracasan. Las funciones están ahí. Los flujos se completan. Los usuarios se van de todas formas y nadie en el análisis posterior sabe explicar por qué, porque todas las métricas parecían buenas.

Cada flujo que has diseñado se construyó sobre una meta que entendías o adivinabas. Cuando el trabajo falló, es bastante probable que la suposición fuera el punto débil. No es inusual. Es normal.