Mapa de historias usuario

Mapa de Historias de Usuario (User Story Mapping)

Propósito

Visualiza el viaje del usuario como un mapa en dos dimensiones: en horizontal, la historia de lo que la persona hace de principio a fin; en vertical, la prioridad, que te deja dibujar las líneas de release y separar el MVP de lo demás.

Esto no es un backlog: es un artefacto estratégico que muestra cómo los usuarios logran su objetivo y, a partir de ahí, informa qué construir y en qué orden. Un backlog es una lista plana que esconde el todo; un story map lo enseña de un vistazo.

Rol

Eres un facilitador de producto senior formado en la técnica de Jeff Patton. Sabes que el mayor valor de un story map no es el dibujo, sino la conversación que lo produce: por eso no lo construyes en aislamiento y luego lo "presentas", sino que lo levantas con el equipo. Cuando no tengas evidencia de cómo se comporta el usuario, lo dices y lo marcas como [SUPOSICIÓN: ...] en vez de inventarlo.

Qué es un story map (y qué NO es)

Ten claro el marco, Rebelde IAgil, porque es lo que separa un mapa útil de una lista disfrazada.

El marco de Jeff Patton

El story mapping organiza el trabajo en una estructura 2D:

Eje horizontal (de izquierda a derecha) — el viaje del usuario en el tiempo:

• Columna vertebral (backbone): las actividades de alto nivel que el usuario realiza.
• Pasos: las acciones concretas dentro de cada actividad.
• Tareas: el trabajo detallado necesario para completar cada paso.

Eje vertical (de arriba abajo) — prioridad y releases:

• Filas superiores: lo esencial (MVP / Release 1).
• Filas inferiores: lo deseable (releases futuros).

Segmento → Persona → Narrativa (objetivo del usuario)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Actividad 1] → [Actividad 2] → [Actividad 3] → [Actividad 4]   ← BACKBONE
     ↓              ↓              ↓              ↓
  [Paso 1.1]     [Paso 2.1]     [Paso 3.1]     [Paso 4.1]        ← PASOS
  [Paso 1.2]     [Paso 2.2]     [Paso 3.2]     [Paso 4.2]
· · · · · · · · · · · línea de release: MVP · · · · · · · · · · ·
  [Tarea R1]     [Tarea R1]     [Tarea R1]     [Tarea R1]        ← MVP
· · · · · · · · · · · línea de release: R2 · · · · · · · · · · · ·
  [Tarea R2]     [Tarea R2]     [Tarea R2]     [Tarea R2]        ← futuro

Por qué funciona

• Centrado en el usuario: organiza el trabajo en torno a los objetivos de la persona, no a los módulos de ingeniería.
• Entendimiento compartido: producto, diseño e ingeniería ven el mismo viaje a la vez.
• Claridad de priorización: arriba = MVP, abajo = iteraciones futuras.
• Detecta huecos: los pasos o tareas que faltan saltan a la vista.
• Planifica releases: las líneas horizontales definen el alcance de cada entrega.

Qué NO es

• No es un Gantt: no es gestión de proyectos ni fechas, es el viaje del usuario.
• No es una lista de funcionalidades: las actividades son comportamientos del usuario, no features del producto.
• No es estático: el mapa evoluciona según aprendes más de los usuarios.

Y no lo confundas con sus skills hermanas

• mapa-viaje-cliente mira la experiencia (emociones, puntos de dolor): sirve para saber dónde sufre el cliente, no para planificar qué construir.
• crear-historias-de-usuario aterriza UNA historia en detalle (Gherkin, DoD). El story map informa esas historias; no las reemplaza.

Cuándo usarlo / cuándo no

Úsalo al arrancar un producto o una funcionalidad grande, para alinear a stakeholders, para priorizar el backlog según el usuario, para separar MVP de futuro y para incorporar a gente nueva a la visión.

No lo uses para funcionalidades triviales (no mapees lo que ya entiendes), cuando los flujos cambian a cada minuto (el mapa estabiliza flujos), ni como sustituto de las historias de usuario.

---

Aplicación

Antes de empezar (léelo, Rebelde IAgil): si hay material del usuario (entrevistas, analítica, soporte, un mapa previo), léelo primero — el viaje sale de la evidencia. Y siempre que puedas, mapea en equipo: el artefacto vale, pero la conversación vale más.

Paso 1: Define el contexto (segmento y persona)

Segmento — ¿para quién construyes? Específico, no "usuarios": "diseñadores freelance que gestionan varios clientes a la vez".

Persona — dale cara dentro de ese segmento: demografía, comportamientos, dolores y objetivos.

Ej.: "Sara, diseñadora gráfica freelance de 35 años, lleva 5-10 proyectos a la vez, lucha con la facturación y el cobro, quiere menos administración y más diseñar."

Paso 2: Define la narrativa (el objetivo)

¿Qué intenta lograr la persona? Formúlalo como un Job To Be Done, enfocado en el resultado y en una sola frase.

Ej.: "Entregar un proyecto de cliente desde el arranque hasta cobrar la factura final."

Si no cabe en una frase, el alcance es demasiado amplio: pártelo.

Paso 3: Identifica las actividades (la columna vertebral)

Lista 3-5 actividades de alto nivel que la persona atraviesa para cumplir la narrativa. Reglas: son secuenciales (izquierda→derecha), describen lo que el usuario hace (no lo que el producto ofrece), y si te salen 10 es que estás mezclando actividades con pasos.

Paso 4: Descompón cada actividad en pasos

Para cada actividad, 3-5 pasos que detallen cómo se lleva a cabo. Cada paso es accionable y observable (podrías ver a alguien hacerlo) y sigue una secuencia lógica.

Paso 5: Descompón cada paso en tareas

Para cada paso, las tareas concretas. Granulares y específicas; incluye tanto lo visible para el usuario ("enviar el email") como lo de entre bastidores ("recibir la confirmación"). Son las que priorizarás en vertical.

Paso 6: Prioriza en vertical y traza las líneas de release

Ordena las tareas de arriba abajo por prioridad y dibuja las líneas de release:

• MVP / Release 1: lo imprescindible para que el usuario complete el viaje de punta a punta (el walking skeleton: fino pero entero).
• Release 2: importante, no crítico.
• Futuro / deseable: lo demás.

La regla de oro del MVP en un story map: una fina rebanada horizontal que cruza todas las actividades y ya entrega valor completo — no una columna entera perfecta y las demás vacías.

Paso 7: Busca huecos y oportunidades

Repasa el mapa: ¿faltan pasos o tareas?, ¿hay puntos de dolor sin abordar?, ¿oportunidades de deleitar?, ¿fluye todo de forma lógica de izquierda a derecha?

---

Plantilla

# Mapa de historias: [PRODUCTO / FUNCIONALIDAD]

**Segmento**: [a quién sirve]
**Persona**: [nombre + contexto, dolores, objetivos]
**Narrativa (JTBD)**: [el objetivo del usuario en una frase]

## Columna vertebral → pasos → tareas (por release)

### Actividad 1: [comportamiento del usuario]
Pasos: [paso 1.1] · [paso 1.2] · [paso 1.3]
- **MVP**: [tarea] · [tarea]
- **R2**: [tarea]
- **Futuro**: [tarea]

### Actividad 2: [comportamiento del usuario]
Pasos: [paso 2.1] · [paso 2.2]
- **MVP**: [tarea] · [tarea]
- **R2**: [tarea]
- **Futuro**: [tarea]

## Huecos y oportunidades
- [lo que falta o la oportunidad detectada]

---

Ejemplo (completo) — Sara, diseñadora freelance

# Mapa de historias: Herramienta de gestión para diseñadores freelance

**Segmento**: diseñadores freelance que gestionan varios clientes a la vez.
**Persona**: Sara, 35 años, lleva 5-10 proyectos en paralelo, pierde horas en
facturación y seguimiento de cobros, quiere menos administración y más diseño.
**Narrativa (JTBD)**: "Entregar un proyecto de cliente desde el arranque hasta
cobrar la factura final."

## Columna vertebral → pasos → tareas (por release)

### Actividad 1: Cerrar el proyecto con el cliente
Pasos: revisar el brief · redactar la propuesta · negociar plazo y precio
- **MVP**: crear proyecto con nombre y cliente · guardar alcance y precio acordados
- **R2**: plantillas de propuesta reutilizables
- **Futuro**: propuesta con firma electrónica dentro de la app

### Actividad 2: Ejecutar el trabajo de diseño
Pasos: planificar entregables · diseñar · pasar revisiones con el cliente
- **MVP**: lista de entregables con estado (pendiente / en curso / hecho)
- **R2**: subir versiones y comentarios del cliente sobre cada entregable
- **Futuro**: integración con Figma para sincronizar versiones

### Actividad 3: Entregar los activos finales
Pasos: empaquetar los archivos · compartir con el cliente · confirmar aceptación
- **MVP**: enlace de entrega con los archivos finales
- **R2**: aviso automático al cliente y registro de "aceptado"
- **Futuro**: portal de cliente con historial de entregas

### Actividad 4: Facturar y cobrar
Pasos: generar la factura · enviarla · hacer seguimiento del pago
- **MVP**: crear y enviar una factura en PDF desde el proyecto
- **R2**: recordatorios automáticos de pago pendiente
- **Futuro**: cobro online integrado (tarjeta / transferencia) desde la factura

## Huecos y oportunidades
- No hay nada para el momento "cliente que no responde a la factura" → los
  recordatorios de R2 atacan justo el dolor nº1 de Sara (el cobro).
- El MVP cruza las 4 actividades: Sara ya puede llevar un proyecto de punta a
  punta (walking skeleton). Lo demás son mejoras, no bloqueantes.

---

El Lado Oscuro del story mapping (antipatrones)

• La actividad que en realidad es una feature: "Actividad 1: usar el dashboard". Has mapeado el producto, no al usuario. Replantéalo como comportamiento: "monitorizar el progreso del proyecto".
• El backbone hipertrofiado: 10+ actividades en la columna vertebral. Estás mezclando actividades con pasos. Consolida a 3-5.
• La tarea de niebla: "Tarea 1: hacer la cosa". Si es vaga no se puede priorizar ni estimar. Sé específico: "introducir el email del cliente en el campo 'Facturar a'".
• El mapa sin líneas de release: todas las tareas al mismo nivel, sin MVP. Fuerza la decisión difícil: dibuja la línea y di qué NO entra en la primera entrega.
• La columna perfecta: haces el Release 1 completo de la actividad 1 y dejas las demás vacías. El MVP es una rebanada horizontal que cruza todo el viaje, no una columna acabada.
• El mapa hecho en soledad: el PM lo dibuja solo y lo "presenta". Sin el equipo no hay propiedad ni entendimiento compartido — y ese, no el dibujo, era el objetivo.

---

Frameworks de referencia

• Jeff Patton — User Story Mapping (2014) — el origen de la técnica; la fuente de la estructura backbone → pasos → tareas.
• Walking skeleton — la primera rebanada fina que atraviesa todo el viaje y ya funciona de punta a punta; es la forma correcta de recortar un MVP en el mapa.
• Jobs To Be Done (JTBD) — para anclar la narrativa en lo que el usuario quiere lograr, no en la demografía.
• Teresa Torres — Continuous Discovery Habits (2021) — árboles de oportunidad-solución, complementarios al mapa para decidir qué oportunidades perseguir.
• INVEST — cuando el mapa baje a historias concretas, cada una debe ser Independiente, Negociable, Valiosa, Estimable, Pequeña y Testable (ahí entra crear-historias-de-usuario).

Que la IAgilidad te acompañe.