No te olvides de poner al usuario en el centro
No te olvides de poner al usuario en el centro
¿Cómo identificar a tu user persona a mitad de camino?
As a < type of user >, I want < some goal > so that < some reason >.
Es la fórmula mágica para escribir user stories . Si has trabajado en agile, probablemente te hayas cruzado con las historias de usuario. Las historias de usuario son una herramienta que ayuda a poner al usuario en el centro del proceso de desarrollo. Ayuda a entender la finalidad para la que se desarrolla una funcionalidad. De esta forma, en vez de desarrollar:
Crear botón de borrado
El equipo trabajaría una historia con la siguiente estructura:
Como usuario, quiero borrar una carpeta al acabar un proyecto, para liberar espacio de disco duro.
Gracias al contexto de cuándo y para qué, el equipo puede tomar decisiones de manera autónoma. En el caso de que surjan preguntas como ¿qué hacemos con los archivos que hay dentro? pueden decidir borrarlos. El objetivo final del usuario es liberar espacio en la aplicación, cómo queda en manos del equipo para resolverlo de la mejor manera.
Hoy os voy a contar cómo mejorar la calidad de estas historias de usuario utilizando user personas para definir al usuario. Las user personas son arquetipos de usuario que nos ayudan a dar un mejor contexto a la hora de definir historias de usuario.
Para crear una user persona, tienes que definir un personaje ficticio que represente a uno de los segmentos de usuarios que utiliza tu aplicación. Por ejemplo, aquí podéis conocer a Sara:
¿Para qué nos sirve definir a Sara en nuestro producto? Para poder tener conversaciones más ricas a la hora de definir funcionalidades y flujos. En marketing y ventas se trabaja con una herramienta parecida definiendo al buyer persona. En producto es igual, pero definiendo al usuario ideal.
Cuando veo historias de usuario que empiezan con un As a user I want to … me generan cierto rechazo. Y yo soy el primero, que, por prisas, las escribe a veces. Pero no me gustan. Se alejan de la intención de ponerse en los pies del usuario. El usuario se convierte en algo frío e impersonal. Cuando en su lugar veo As Sara I want to … la película cambia por completo. Sara, tiene unos problemas específicos que se quieren resolver, una serie capacidades, que podemos explotar. ¿Cómo ayudo a Sara a disfrutar esta historia de usuario?
Cuando desarrollamos herramientas para empresas podemos caer en la tentación de desarrollar funcionalidades que atraigan a más empresas para comprar el producto, pero que no estén bien diseñados para que los empleados (los usuarios de verdad) las usen en el día a día.
¿Creas espacios de trabajo para cada tipo de usuario, o agrupas las funcionalidades por módulos?
Crear la experiencia perfecta para todos los usuarios, no es fácil. Empiezas con un MVP, recibes feedback con funcionalidades que faltan de distintos stakeholders y las vas implementando. Si esas funcionalidades acaban en el roadmap como historias de usuario y a cada una le asignas una persona, el producto tendrá más coherencia para el usuario. Si todas las historias de usuario empiezan con As a user… lo más probable es que el equipo de desarrollo genere inconsistencias con el resto de la solución. Si sigues por ese camino es probable que, al cabo de un tiempo, sólo el product manager sea capaz de utilizar bien la aplicación.
En los libros de diseño, se recomienda definir a estas personas durante una fase temprana del producto, idealmente antes de empezar a programar. Si crees que llegas tarde a esta fase, te doy algunos consejos para encontrar distintas user personas en tu producto, haciendo ingeniería inversa.
Para empezar, supongamos que tienes un producto con varios módulos (o funcionalidades principales) y que lo usan bastantes usuarios (varios cientos o idealmente miles). Si no has trabajado con user personas antes, puedes tener la tentación de asignar una a cada módulo de tu producto. Es un buen primer paso, pero la magia aparece cuando eres capaz de definir usuarios que utilizan varios módulos de tu aplicación. Esto te permite elaborar casos de uso más complejos y a la larga, tener un producto robusto y difícil de imitar.
La forma cualitativa de llevar a cabo esta investigación es bastante directa. Montas un esquema de entrevista, agendas reuniones con distintos usuarios de cada módulo, y por último sintetizas la información y defines esas personas. Este proceso lleva tiempo y es bastante complejo.
Si quieres obtener información preliminar que te ayude a reducir el tiempo invertido en las entrevistas, puedes sacar algo de información cuantitativa de antemano. Te propongo que analices el comportamiento de los usuarios, cruzando cuánto tiempo utiliza cada módulo y cuántas veces entra en un periodo de tiempo. Una vez has recolectado la información, puedes aplicar estadística básica para definir unos primeros grupos de user personas. Puedes segmentarlos en base a los percentiles de uso de los módulos o analizar medias de las frecuencias de uso para generar algunos patrones. Si en tu equipo tenéis capacidades de data analytics, puedes realizar un análisis PCA seguido de un clustering usando Kmeans para poder sacar grupos con comportamientos similares y de esta forma extrapolar las características de algunos grupos de usuarios. Estos análisis los puedes realizar sobre cada tipo de dato o combinando ambas fuentes de datos en una matriz con este formato.
Esto no es un método infalible para identificar user personas, es una herramienta analítica que te ayuda en el proceso de definición. Además, cuando se aplican técnicas de machine learning no supervisadas, hay que trabajar los resultados para poder sacar conclusiones relevantes. Quieres encontrar 2 o 3 conjuntos de usuarios, que presenten patrones similares de uso y que luego puedas utilizarlos para crear historias de usuario. No sirve de nada tener un modelo de clustering con distancias muy bajas que acabe generando 57 user personas para tu producto.
Una vez definidos esos grupos, crea una entrevista con una serie de preguntas que te ayuden a entender las motivaciones de los usuarios, por ejemplo:
¿Cuál es su trabajo?
¿Cómo trabajaban antes de usar el producto?
¿Por qué usan el producto?
¿Qué actividades hacen en el día a día, fuera de la herramienta?
Cuando las respuestas empiecen a repetirse en las entrevistas, quiere decir que estas yendo por buen camino. Cuando ya tienes tu user persona, y ahora, ¿qué hago para mejorar el producto? Optimizar al máximo su happy path. ¿Qué acción tiene que realizar en tu producto? Optimízala a muerte. ¿Validar gastos? Dile cuántos gastos le quedan por validar al llegar a la aplicación y haz que con un click pueda empezar a trabajar. Diseña una interfaz que le motive seguir validando. Coloca los botones para minimizar tiempos, clicks, problemas, ….
¿Y la funcionalidad que cuadra automáticamente las cuentas que usa una vez al mes? La entierras. Pero es que es la que más vende. Pues la pones en la web en grande, pero en el producto la entierras. Porque para una vez que consolida gastos al mes, no le molestes los otros 29 días con una pantalla que no le aporta valor a su trabajo principal que es: validar gastos.
Y así con el resto de personas:
A su jefe enséñale las aprobaciones y un cuadro de mandos
A la gente de soporte incidencias
…
Tener buenas user personas que aporten valor al desarrollo de producto es trabajo. No son dos semanas de un proyecto aislado. Hay que estar continuamente refinando las personas, concretar mejor sus problemas, mejorar las soluciones y adaptarlas, equivocarse en el proceso de optimización, dedicarle tiempo a crear funcionalidades que “no aportan funcionalidad” al producto.