¿Qué es la historia de usuario?
Las historias de usuario con una práctica clásica para colaborar con los usuarios en el entendimiento de sus necesidades y la entrega de soluciones efectivas.
Sin embargo a menudo se utilizan como una variación ágil de la “especificación de requisitos”. En este artículo explicamos cómo utilizar esta práctica centrada en el diseño de experiencias de usuario (UX).
Contenidos del artículo
- 1 ¿Qué es la historia de usuario?
- 2 Analizar las necesidades del usuario
- 3 Revisitando el formato
- 4 💌 Recibe estos artículos en tu buzón cada semana
- 5 Equipos centrados en el usuario o feature factories
- 6 Definir y medir resultados (outcomes)
- 7 Definir y medir beneficios (benefits)
- 8 Usar historias de usuario en el contexto del diseño de UX
Cursos relacionados
| Fecha | Ciudad | Curso |
|---|---|---|
| 14/01 | Curso virtual | Professional Scrum Product Owner (PSPO) |
| 03/02 | Curso virtual | Professional Scrum Product Owner – Advanced (PSPO-A) |
Analizar las necesidades del usuario
En la ingeniería de software clásica, basada en el ciclo de vida en cascada (waterfall), se analizan las necesidades de los usuarios para obtener dos tipos de requisitos:
- Requisitos de usuario: cuáles son las necesidades que tienen dichos usuarios, sin considerar cómo se van a satisfacer.
- Requisitos de sistema: que características funcionales (funcionalidades) y técnicas “requiere” el sistema para satisfacer los requisitos de usuario.
En cualquier caso, ambos tipos de requisitos suelen analizarse y documentarse para crear sendas “especificaciones“. Aunque la RAE define especificación como “Información proporcionada por el fabricante de un producto, la cual describe sus componentes, características y funcionamiento“, en el ámbito de la ingeniería se pretende que dichos requisitos sean correctos y estables para evitar los retrabajos a los equipos de desarrolladores y la necesidad de comunicarse con otros roles. Al separar al máximo las etapas de análisis y desarrollo, se facilita que éstas puedan realizarse por equipos y empresas diferentes, y potencialmente de manera remota.
Aunque estos conceptos suenen algo anticuados hoy en día, siguen siendo utilizados en muchos proyectos, y su inercia se filtra también en la manera en las que se llevan a cabo las prácticas ágiles.
Las historias de usuario nacieron a finales de los 90 precisamente para romper las barreras de comunicación que ponen los procesos clásicos entre quienes utilizaran los sistemas y quienes los desarrollan.
No son una manera de documentar los requisitos, sino una práctica para mantener una comunicación fluida, efectiva y eficiente entre todos los roles que participan en el desarrollo de los sistemas. Suponen una colaboración “constante”, no porque los roles tengan que discutirlos constantemente o porque caigan en el descontrol, sino porque están sujetos a potenciales mejoras en cuanto se descubra y decida que merece la pena el cambio.
Revisitando el formato
El formato más habitual de documentar las User Stories es el de Connextra, una empresa británica que las popularizó en 2001.
- Plantilla: Como <rol> quiero <capacidad> para <obtener beneficio>.
- Ejemplo no UX: Como cliente bancario quiero sacar dinero del cajero.
- Ejemplo si UX: Como Raúl, cliente bancario veinteañero quiero obtener dinero rápidamente para tener más tiempo libre.
Habitualmente el “poder hacer algo” se sustituye por el nombre de una funcionalidad. Ya comenzamos mal: estamos diciendo como queremos implementar la capacidad que quiere tener el usuario, y por tanto restringiendo otras posibles implementaciones mejores (p.e. obtener dinero una aplicación de pago por móvil). Además pasamos a centrarnos en la funcionalidad y potencialmente a olvidar la necesidad original.
Además, hablamos de un “rol” genérico, cuando en UX podemos definir “Personas” o “Proto-personas” y entender mejor las necesidades de diferentes perfiles de usuario.
Por otro lado, también es frecuente no darle importancia la parte de “beneficio esperado” o directamente eliminarla. Podemos pensar “si ya entendemos la funcionalidad, ¿por qué pensar en el beneficio que obtendrá el usuario? Él sabrá porque la ha pedido”. Aunque no siempre tiene sentido pensar en esta parte, hacerlo nos puede dar varios beneficios:
- Al entender (y cuantificar) el valor de diferentes historias, podemos comparar efectivamente su prioridad.
- Si tenemos una estimación del valor aportado, podemos monitorizarla durante las entregas de funcionalidades y decidir si se ha alcanzado dicho valor, merece la pena invertir más o por el contrario, no.
Veremos estas preguntas en las siguientes secciones.
💌 Recibe estos artículos en tu buzón cada semana
Equipos centrados en el usuario o feature factories
Uno de los temas más recurrentes últimamente en los ámbitos Agile y del diseño de experiencias de usuario es la preocupación porque muchos equipos Agile se han convertido en “fábricas de funcionalidades” (feature factories en inglés).
Si los equipos se preocupan excesivamente por la “productividad”, medida como la cantidad de funcionalidades entregadas, podemos olvidarnos del resultado que ofreceremos al usuario. En las organizaciones donde hay mucho foco, incluso obsesión con métricas como la Velocity, es más fácil encontrar estos equipos. Hay que destacar, especialmente al management, que más producto no implica necesariamente más valor, sino que en las feature factories pasa justo al revés. Dado que nos centramos en entregar producto, podemos:
- Dejar de priorizar funcionalidades valiosas pero costosas.
- No arriesgar para aprender, ni invertir en entender las necesidades del usuario.
Es importante recalcar que la cadena de proceso > producto > resultados > beneficios está construida de hipótesis que pueden fallar, y que se han de validar. Definir historias de usuario con foco en los resultados y los beneficios, es un buen comienzo para entrar en una buena dinámica orientada a entregar valor.
Definir y medir resultados (outcomes)
El resultado (outcome en inglés) es el grado de respuesta a la necesidad del usuario que le proporciona la funcionalidad que le entregamos. En una historia de usuario orientada a UX, definiremos el “quiero” como una necesidad que se pueda medir. Además podemos intentar cuantificar esta necesidad, p.e. en el ejemplo siguiente no sabemos que quiere decir “rápidamente”, es una necesidad cualitativa.
- Resultado sin cuantificar: Como … quiero obtener dinero rápidamente para …
- Resultado cuantificado: Como … quiero obtener dinero en menos de 5 minutos para …
Habitualmente estos objetivos se definen en los “criterios de aceptación” de la historia. Si los colocamos en el campo de la necesidad, les damos mayor visibilidad y los enfoca como una meta que podamos medir una vez entreguemos la funcionalidad. Esto permite establecer un diálogo con el usuario (y el Product Owner) sobre las expectativas y el esfuerzo que se está dispuesto a invertir.
Definir y medir beneficios (benefits)
Cuantificar y medir los beneficios es muy útil para racionalizar la demanda y las expectativas de los usuarios, además de priorizar la demanda.
En este ejemplo sencillo, se comprueba como cuantificación de beneficios ayuda a priorizar la demanda con perspectiva de usuario:
- Historia 1: Como … quiero obtener un informe mensual de ventas para ahorrar 4 horas al mes.
- Historia 2: Como … quiero obtener un informe diario de pagos para ahorrar 15 horas al mes.
Lógicamente es necesario también tener una estimación del esfuerzo para poder comparar el coste y beneficio, incluso si se trata de evaluar el sentido de invertir en esta historia.
Usar historias de usuario en el contexto del diseño de UX
Como hemos visto en este artículo, como usamos las historias de usuario puede contribuir significativamente a hacer el desarrollo de producto más orientado a las necesidades del usuario y a la entrega de valor.
Como resumen:
- Las historias de usuario rompen el ciclo de vida de cascada: ¡cada historia tiene su ciclo de vida!
- Las historias no son una tarjeta, sino una técnica para mantener el diálogo con todos los roles afectados.
- Es bueno que todos los roles entiendan el resultado y el beneficio que ofrece la historia. Su formato está pensado para ello.
- Cuantificar el resultado y el beneficio ayuda a dar un uso más “user centric” a las historias de usuario.
¿Quieres recibir más información y recursos de calidad?
¡Suscríbete a nuestra newsletter mensual!
Cada mes enviamos una newsletter a más de 1.200 personas con contenidos, recursos y ofertas especiales de nuestros cursos. Queremos ofrecer contenido de calidad y sin spam.
