User stories: cómo describir lo que tu producto debe hacer

Cuando describes una funcionalidad como "necesitamos un sistema de filtros", dejas mucho a la interpretación. ¿Filtros para qué? ¿Para quién? ¿Por qué los necesita? Las user stories nacieron justo para resolver esto: poner al usuario en el centro de cada cosa que construyes.

En Plaka Studio las usamos a diario porque traducen ideas técnicas a lenguaje humano. Y eso, cuando hablas con founders que no son técnicos, lo cambia todo. Te enseñamos a escribirlas bien.

La fórmula que nunca falla

Una user story sigue una estructura sencilla: "Como [tipo de usuario], quiero [hacer algo] para [conseguir un beneficio]". Por ejemplo: "Como cliente nuevo, quiero guardar mis datos de pago para no tener que escribirlos cada vez".

Fíjate en lo que aporta el formato. No describe una pantalla ni un botón. Describe una necesidad. El cómo lo resuelve el equipo de diseño y desarrollo, y muchas veces encuentran una solución mejor que la que tú imaginabas.

El detalle vive en los criterios de aceptación

La historia es el titular. Los criterios de aceptación son la letra pequeña. Son la lista de condiciones que deben cumplirse para dar la historia por terminada.

• Qué pasa cuando el usuario hace lo esperado.
• Qué pasa cuando se equivoca o deja un campo vacío.
• Qué mensajes ve y en qué momento.

Sin criterios de aceptación, cada persona dará por "terminada" la historia en un punto distinto.

Pequeñas, independientes y testables

Una buena user story se puede construir en pocos días, no en meses. Si la tuya abarca medio producto, divídela. Tampoco debería depender de otras diez historias para tener sentido. Y, sobre todo, debe poder comprobarse: o se cumple o no se cumple.