Historias de usuario para diseñadores: formato, criterios y errores
Una historia de usuario dice quién necesita algo, qué quiere hacer y para qué. Cómo escribirla, qué criterios usar (INVEST) y dónde aporta el diseño.
¿Qué es y de dónde viene?
Mike Cohn, en Mountain Goat Software, atribuye a Ron Jeffries la fórmula de tres palabras: tarjeta, conversación y confirmación. Lo que importa es la conversación: la frase escrita es un recordatorio para hablar, y el requisito completo surge de esa charla.
La plantilla de tres partes es posterior. Agile Alliance la llama formato Connextra, por la empresa británica donde se inventó en 2001, y la presenta así: quién quiere lograr algo, qué quiere lograr y por qué. Martin Fowler la describe de forma parecida: “As a” indica quién, “I want” qué, y “so that” por qué. Para evaluar la calidad hay otra herramienta, INVEST, que según Agile Alliance sale de un artículo de Bill Wake y aparece entre las técnicas que recomienda Cohn en su libro User Stories Applied (2004).
Un ejemplo de Agile Alliance, traducido: “Como cliente de un banco, quiero retirar dinero de un cajero, para no depender del horario de atención ni de las filas en la ventanilla”. La historia no dice cómo se debe construir el cajero. Solo dice qué necesita la persona y por qué.
¿Por qué le importa a un diseñador?
Porque el “para qué” es donde el diseño suele aportar más. Un equipo de desarrollo puede construir “un formulario de solicitud” sin preguntarse si la persona entiende lo que le piden. Una historia que dice “para saber si puedo pagar la cuota sin pedir ayuda” ya tiene un criterio de experiencia dentro.
Fowler señala que la cláusula “para qué” aporta contexto para entender lo que realmente se necesita, no solo lo que el cliente cree que quiere. Ese es el punto donde la investigación de usuario y el enfoque de trabajos por hacer (JTBD) se encuentran con la historia. Si lo que importa es la situación y no el rol, mira las job stories.
¿Cómo se escribe una buena historia?
Fowler recuerda que las historias se dejan a propósito sin mucho detalle hasta que están listas para desarrollarse. Un buen punto de partida es seguir la plantilla y luego revisar la calidad con INVEST:
- Independent (independiente). Se puede entregar sin depender de otra historia para tener sentido.
- Negotiable (negociable). Es una necesidad, no un contrato de funcionalidad cerrado. El equipo puede discutir cómo resolverla.
- Valuable (valiosa). Aporta valor a alguien. Si nadie gana nada, no es una historia.
- Estimable (estimable). El equipo puede calcular aproximadamente su tamaño.
- Small (pequeña). Cabe en una iteración.
- Testable (comprobable). Hay forma de saber si se cumplió.
Agile Alliance dice que estos formatos están pensados más como listas de verificación, que gastar mucho tiempo en cumplir la plantilla tiene poco sentido y que sirve como “rueditas de apoyo” para equipos que aprenden a pensar a quién sirve una función y por qué. Cohn coincide: la plantilla ayuda cuando mejora la conversación, pero no debe volverse un ritual. La pregunta importante no es si la frase tiene la forma correcta, sino si el equipo entiende a quién sirve y qué debe pasar para considerarla lista.
Los criterios de aceptación son las condiciones concretas que una historia debe cumplir para darse por terminada; son una práctica habitual del trabajo con historias, aunque no forman parte de la plantilla. Ahí entra el diseño: estados, mensajes de error, comportamiento en móvil o con teclado. Una historia que llega con esos criterios deja menos preguntas abiertas para la conversación con desarrollo.
¿Cómo se usa junto al diseño?
Las historias no reemplazan los diseños, pero los enlazan con el trabajo del equipo. Una práctica útil es asociar cada historia con su pantalla o su flujo, por ejemplo con user flows o wireframes, y dejar el diseño como la respuesta visible al criterio de la historia.
Hay que tener cuidado con la redacción. Una historia escrita como “Como usuario, quiero un botón azul de 48 píxeles” no describe una necesidad, describe una solución. Eso reduce la negociación y la vuelve más difícil de verificar. El diseño debería aparecer como criterio (“el botón principal se identifica sin leer su texto”) y no como especificación.
Una prueba rápida para revisar una historia es intentar describir cómo sabrías que el “para qué” se cumple. Si la respuesta es que no lo sabrías, el problema suele estar en la historia y no en la implementación, y conviene reescribirla antes de construir.
¿Cuándo NO conviene?
- Cuando el problema todavía no está claro. Una historia sobre una solución que nadie ha validado es una opinión con formato.
- Cuando el trabajo es técnico y no tiene usuario directo, como una migración. Una tarea puede ser suficiente.
- Cuando la historia se convierte en un contrato. Si el equipo no puede negociar el alcance, pierde el sentido de la palabra “negociable”.
- Cuando se escriben cientos sin revisar. Un backlog lleno de historias vagas es más difícil de gestionar que uno corto.
Ejemplo
Ejemplo ilustrativo: un equipo de una app de facturas quiere mejorar el envío de recordatorios a clientes. Una historia inicial dice: “Como emisor de facturas, quiero enviar recordatorios, para cobrar más rápido”. El diseñador propone revisarla con el equipo y el resultado es: “Como emisor de facturas con pagos atrasados, quiero enviar un recordatorio con el monto y la fecha límite, para que el cliente pague sin tener que llamarle”. Los criterios de aceptación incluyen: el recordatorio muestra el monto y la fecha, el emisor puede editar el texto antes de enviarlo y el envío queda registrado en la factura. La historia es más pequeña, más clara y más comprobable.
Para tu próximo backlog: toma tres historias, reescribe cada una con quién, qué y para qué, y comprueba si puedes escribir un criterio que alguien pueda verificar.
Errores comunes
- Escribir soluciones en lugar de necesidades.
- Usar “como usuario” para todo, sin distinguir perfiles.
- Omitir el “para qué”, que es donde está el contexto.
- Dejar historias sin criterios de aceptación.
- Historias demasiado grandes que no caben en una iteración.
- Aplicar la plantilla de forma mecánica, sin conversación con el equipo.