Cuando un producto digital conecta dos tipos de usuarios, como quien compra y quien entrega, cualquier fricción en la experiencia puede hacer que uno de los dos abandone la plataforma. Entender cómo comunicar esos problemas al equipo de desarrollo de forma clara y centrada en el usuario es una habilidad fundamental para cualquier product manager. Aquí se explica cómo construir historias de usuario que realmente guíen al equipo hacia soluciones con impacto.
¿Cómo identificar la fricción en un producto con múltiples usuarios?
Para ilustrar el proceso, se plantea un escenario dentro de Rappi enfocado en compras de supermercado [0:08]. El flujo ideal, conocido como happy path [1:00], es sencillo: el usuario selecciona productos, hace el pedido, un rappitendero lo recoge en el supermercado, lo paga y lo envía a domicilio.
Pero el problema aparece cuando un producto no está disponible en el supermercado [1:15]. Sin una solución clara, se generaba una cadena de fricciones:
- El rappitendero escribía al usuario para proponer un reemplazo de forma manual.
- Si el reemplazo era más caro, surgía un problema de cobro.
- Si el usuario rechazaba el reemplazo, seguía pagando por un producto que no recibió.
- Al reportar productos faltantes, el rappitendero recibía mala calificación aunque estuviera haciendo su mejor esfuerzo [2:25].
Este caso ejemplifica un concepto importante: en plataformas donde existen un supply (rappitenderos disponibles) y una demanda (usuarios pidiendo productos) [2:40], ambos lados deben tener una buena experiencia para que el producto funcione. Si cualquiera de los dos desaparece, todo se detiene.
¿Qué solución se diseña antes de escribir historias de usuario?
La funcionalidad propuesta permite al rappitendero enviar una solicitud al usuario a través de la aplicación cuando un producto no está disponible [3:25]. El usuario recibe opciones de reemplazo, aprueba el cambio y su cuenta se ajusta automáticamente: se retira el cobro del producto no disponible y se agrega el del producto aceptado.
También se incluye la opción de no recibir ningún reemplazo [3:50]. Sin embargo, a nivel de negocio, interesa que el usuario elija un producto diferente en lugar de reducir su compra. Aquí entra el rol del product designer, quien debe crear una interfaz que incentive el cambio de producto sin ocultar la opción de no querer nada [4:10]. Es un equilibrio entre objetivos de negocio y experiencia de usuario.
¿Cómo se estructura una historia de usuario efectiva?
La historia de usuario tiene como función principal comunicar al desarrollador qué problema debe resolver, no cómo resolverlo técnicamente [4:40]. Se busca que el equipo de desarrollo genere empatía con el usuario y entienda la situación real que enfrenta.
La estructura clásica tiene tres componentes [5:15]:
- Quién es el usuario: "Como rappitendero..." — esto define a quién se atiende.
- Qué quiere hacer: "...quiero poder reportar que un producto no está disponible..."
- Para qué lo necesita: "...así el usuario me dice qué hacer respecto a su pedido."
Después de la historia, se comparte con el desarrollador cómo se ve la solución propuesta: la interfaz, la experiencia de usuario y todos los detalles relevantes [6:00]. Con esa información, el desarrollador crea su lista de tareas técnicas y estima cuánto esfuerzo y tiempo necesita.
¿Por qué no convertir tareas técnicas en historias de usuario?
Un error frecuente es fragmentar historias de usuario en micro-acciones como "quiero dar tap en un botón y llegar a la siguiente pantalla" [7:05]. Eso no describe un problema real del usuario. El usuario no tiene el problema de presionar un botón; tiene el problema que ya se describió arriba. Las acciones de interfaz son tareas, no historias.
La diferencia es clave: lo que importa no es el output (crear una pantalla), sino el outcome (resolver el problema del usuario) [6:40]. Si la solución implementada no elimina el problema del rappitendero, la historia de usuario persiste y hay que buscar una alternativa.
¿Qué sigue después de crear las historias de usuario?
Una vez definidas todas las historias, el equipo de ingeniería crea las tareas necesarias y estima tiempos [7:50]. Es normal que la primera estimación falle: el equipo puede sobreestimar o subestimar el esfuerzo requerido. Lo importante es llevar un registro del progreso de historias, tareas y estimaciones con el objetivo de aprender y mejorar en cada iteración [8:15].
Si estás comenzando a trabajar con un equipo nuevo, acepta que habrá ajustes. El valor real está en construir ese aprendizaje compartido sobre cómo medir y priorizar lo que importa. ¿Qué fricción has detectado en algún producto que uses y cómo la resolverías con una historia de usuario?
