Tabla de contenidos
Introducción
¿Cuántas veces te has encontrado intentando dividir una eature importante dando algún valor al usuario en cada momento? Esto es algo a lo que nos enfrentamos en nuestro día a día y que queremos compartir con vosotros.
Dentro de este artículo expondremos los problemas que encontramos (tal vez tú también los encontraste), y las decisiones que tomamos para enfrentarlos, siempre previendo una historia de usuario INVEST (Independent, Negotiable, Valuable, Estimable, Small, and Testable).
Esperamos que disfrutes de la lectura tanto como nosotros del proceso de escritura.
Escenario del problema
Imaginemos que trabajamos en el departamento de productos de una empresa llamada ‘Frame Store’. Vendemos frames (lo sabemos, ¡muy inteligente, verdad!) a múltiples tiendas físicas.
Recibimos proveedores de todo tipo y los distribuimos.
Lo que solemos recibir de nuestra gente de negocios es una gran idea, inspiradora (¡a veces no 100% realista y racional!) de una característica muy bonita y genial que puede mejorar algún aspecto de su producto de software. Algo así:
Hagamos evolucionar nuestra home page para facilitar su uso a nuestras diferentes personas.
Nuestros usuarios navegan por el menú de la izquierda, seleccionando una sección y después un submenú.
Después de un poco de refinamiento con el Negocio, imaginemos que finalmente fuimos capaces de acordar la definición de la feature, y termina pareciendo:
| Contexto | Nuestro Frame Store Portal tiene diferentes personas (1) que acceden a la aplicación y ven el mismo menú. Cada persona tiene un objetivo diferente al trabajar con nuestro portal. 1. Mary como Contable > necesita acceder a nuestro Frame Store Portal para comprobar y enviar las facturas a los diferentes proveedores. 2. Susan como Stock manager utiliza el portal para gestionar el stock de todas nuestras tiendas y distribuir los proveedores de los alrededores. 3. Laura como Warehouse manager utiliza el portal para obtener la lista de proveedores que su equipo necesita enviar a cada tienda. Cada vez que necesitan realizar una acción en nuestra plataforma, tienen que navegar por el menú y encontrar la opción que necesitan. La mayoría de las veces, sólo utilizan 3 opciones del menú e ignoran las demás. Los roles y permisos no son útiles en esta situación porque, algunas personas tienen el mismo rol dentro de la aplicación, pero la acción que realizan es diferente. |
| Valor de Negocio | Mejorar la navegación a través de nuestro portal permitirá a nuestros usuarios ser más eficientes y también poder centrarse en lo que realmente necesitan. Estas son las premisas que queremos conseguir con este proceso (2): – Si los usuarios son capaces de personalizar su menú, serán capaces de encontrarlos fácilmente, mejorando el rendimiento y la satisfacción. – Si los usuarios pueden buscar las opciones del menú, podrán encontrarlas fácilmente, mejorando el rendimiento y la satisfacción. Esperamos aumentar la satisfacción de los usuarios en un 10% (calculado a través de la encuesta NPS) y el número de operaciones cerradas al día en un 5% (calculado a través de nuestro sistema de análisis). |
| Criterio de aceptación | – El usuario debe ser capaz de encontrar las acciones del menú principal en menos de 1 clic. – El usuario no debe verse abrumado por cientos de opciones. |
(1) Ten en cuenta que las diferentes personas deben ser claras y deben ser transversales (ver artículo sobre cómo definir Personas aquí) (2) En este punto, ya hemos validado las hipótesis, véase el artículo Hypothesis validation para más detalles sobre cómo hacerlo.
Cómo dividir la historia de usuario
Después de algunas pruebas de usuario, refinamientos de UX,… el equipo de producto llega a la siguiente maqueta que todos están de acuerdo en que ayudará a lograr el beneficio que estamos buscando.
Mirando la propuesta de wire-frame, una consideración inmediata sería mirar el campo de entrada de búsqueda como una característica separada. Por lo tanto, una historia de usuario diferente. Esta inmediatez proviene directamente del hecho de que un campo de entrada de búsqueda es un componente genérico de la interfaz de usuario que se puede utilizar siempre que sea necesario. A partir de aquí, la siguiente reflexión sería cómo configurar bajo demanda los criterios por los que queremos filtrar.
Pero un momento: ¿de dónde sacamos esta «siguiente idea»? Bien, revisando el título de la Historia de Usuario «Como usuario, me gustaría poder buscar cualquier opción de menú y submenú a través de un campo de búsqueda«, la conjunción y sirve para indicar que ambos criterios descritos (menú y submenú) están conectados. Y pensando un poco más allá, esta conexión entre criterios podría ser genérica no sólo entre menú y submenú.
Nuestra lista que hay que implementar para conseguir la AC de la función podría ser algo así como…
- Como usuario quiero gestionar mis acciones favoritas para poder acceder a ellas más rápidamente
- Como usuario quiero poder buscar cualquier opción del menú a través de un campo de búsqueda en tiempo real en menos de 3 segundos para poder tener una respuesta rápida
- Como usuario me gustaría añadir opciones de menú y submenú a la barra de favoritos para poder ahorrar tiempo en encontrarlas.
- …
Como puedes ver, ninguno de ellos alcanza el estatus de INVEST.
En algunos casos, lo que ocurre es que la historia de usuario creada coincide con el paradigma INVEST y en su propia singularidad puede ser entregable porque realmente representa un valor tangible para el usuario final.
En el siguiente ejemplo, consideramos un pequeño grupo de Historias de Usuario, que alcanzan y satisfacen tanto los criterios de aceptación como los requisitos del negocio, para ofrecer el mayor valor al cliente.
¿La historia describe un flujo de trabajo?
Identifiquemos primero nuestro flujo de trabajo principal:
¿Obtiene la historia gran parte de su complejidad de la satisfacción de requisitos no funcionales como el rendimiento?
¿La historia tiene un núcleo simple que proporciona la mayor parte del valor y/o el aprendizaje?
Cuando se aplica la división obvia, ¿la historia que se hace primero es la más difícil?
¿Obtiene la historia el mismo tipo de datos a través de múltiples interfaces?
¿La historia tiene una interfaz compleja?
¿Hace la historia lo mismo con diferentes tipos de datos?
¿Tiene la historia una variedad de reglas de negocio?
¿Incluye la historia múltiples operaciones (gestión, configuración,..)?
Ver aquí un ejemplo adicional usando CRUD (el método es una técnica que sigue la acción del acrónimo. Crear, Leer, Actualizar y Borrar puede ayudarnos a descomponer una historia de usuario «mayor» en otras diferentes):
| Ejemplo | Como usuario quiero gestionar mis acciones favoritas para poder acceder a ellas más rápidamente. |
| Split | Como usuario me gustaría poder crear cualquier elemento del menú a mi lista de Favoritos. Como usuario me gustaría poder leer mi lista de Favoritos. Como usuario me gustaría actualizar mis listas de Favoritos con los elementos adecuados. Como usuario, me gustaría poder eliminar cualquier elemento del menú de mi lista de favoritos. |
Conclusiones
En este artículo, aplicamos diferentes preguntas a diferentes NOSOTROS para dividirlas y que tengan sentido. La práctica le ayudará a identificar más rápidamente qué pregunta deberá hacerse en cada escenario. Esperamos que nuestros ejemplos le ayuden a entender mejor lo que buscamos en cada caso. No todas las preguntas se aplican a todos los escenarios y, además, es normal que te sientas más cómodo utilizando algunas de ellas en lugar de otras.
La metodología puede darte una guía, pero necesitas conocer tu negocio y tu equipo para que funcione.
Además, no confíes sólo en un único paradigma. Mezcla y combina, combínalos para lograr una historia de usuario clara, estimable y útil, e historia de usuario con el paradigma INVEST.
¡Esperamos verte por aquí!
¡Buena suerte!
