¿Cómo escribir historias de usuario con enfoque UX?
Tiempo de lectura: 6 minutos
Las historias de usuario son una práctica clásica para colaborar con los usuarios en el entendimiento de sus necesidades y la entrega de soluciones efectivas. El problema es que a menudo se usan como una simple variación ágil de la "especificación de requisitos" — perdiendo justo lo que las hace valiosas. Aquí te explico cómo escribirlas con un enfoque centrado en el diseño de experiencia de usuario (UX).
Qué es la historia de usuario
En la ingeniería de software clásica (waterfall) se analizan las necesidades del usuario para obtener requisitos de usuario (qué necesita, sin decidir cómo) y requisitos de sistema (qué funcionalidades técnicas los satisfacen). Ambos se documentan como "especificaciones" estables, pensadas para evitar retrabajos separando al máximo análisis y desarrollo.
Las historias de usuario nacieron a finales de los 90 precisamente para romper esa barrera de comunicación entre quienes usan los sistemas y quienes los desarrollan. No son una forma de documentar requisitos: son una práctica para mantener un diálogo fluido y constante entre todos los roles implicados, abierta a mejoras en cuanto se descubre que merece la pena un cambio.
Analizar necesidades
El formato más habitual —Como \
Además, hablamos de un "rol" genérico, cuando en UX podemos definir personas o proto-personas para entender mejor las necesidades de perfiles de usuario distintos.
Revisitando el formato
También es frecuente restar importancia a la parte de "beneficio esperado", o eliminarla directamente — total, si ya entendemos la funcionalidad, ¿para qué pensar en el beneficio? Pero cuantificar el beneficio nos da algo valioso: podemos comparar la prioridad real de distintas historias, y monitorizar después si ese valor se alcanzó de verdad.
Feature factories
Uno de los temas más recurrentes en Agile y UX es la preocupación de que muchos equipos se han convertido en "fábricas de funcionalidades" (feature factories). Cuando un equipo se obsesiona con la "productividad" medida en velocity, es fácil olvidar el resultado real que se ofrece al usuario — y más producto no implica más valor; en las feature factories suele pasar justo lo contrario: se deja de priorizar lo valioso-pero-costoso y se deja de invertir en entender al usuario.
Outcomes
El resultado (outcome) es el grado de respuesta a la necesidad del usuario que le da la funcionalidad entregada. En una historia orientada a UX, el "quiero" debería ser una necesidad medible, no una funcionalidad. Compara: "quiero obtener dinero rápidamente" (sin cuantificar) frente a "quiero obtener dinero en menos de 5 minutos" (cuantificado). Colocar esto en el campo de la necesidad —no solo en los criterios de aceptación— le da visibilidad y lo convierte en una meta medible tras la entrega.
Benefits
Cuantificar el beneficio ayuda a racionalizar expectativas y priorizar con criterio. Compara: "quiero un informe mensual de ventas para ahorrar 4 horas al mes" frente a "quiero un informe diario de pagos para ahorrar 15 horas al mes". Con una estimación del esfuerzo al lado, la comparación de coste-beneficio deja de ser intuición para ser un dato.
Contexto de UX
En resumen: las historias de usuario rompen el ciclo de vida en cascada —cada una tiene el suyo propio—, no son una tarjeta sino una técnica para mantener el diálogo, y su formato está pensado para que todos los roles entiendan el resultado y el beneficio que ofrecen. Cuantificarlos es lo que da un uso realmente user centric a la práctica.
Si quieres seguir profundizando en cómo conectar Scrum y diseño de UX, sigue con cómo integrar UX y Scrum con Dual-Track o revisa la guía definitiva para escribir buenas historias de usuario. El curso Professional Scrum with UX profundiza en todo esto de forma práctica.