De una petición de funcionalidad imprecisa a un plan de entrega claro
Sigue un ejemplo de incorporación de usuarios desde una pregunta abierta hasta una mejora pequeña y comprobable, con un mapa mental que crece a medida que se aclaran las decisiones.
Alguien dice: «Tenemos que facilitar la incorporación de nuevos usuarios».
Todo el mundo está de acuerdo. Entonces llegan las sugerencias: añadir una lista de tareas, acortar la configuración, escribir mejores instrucciones, enviar un correo de bienvenida.
Enseguida hay ideas suficientes para llenar un sprint. Lo que no está tan claro es qué problema intenta resolver el equipo.
Es un buen momento para crear un mapa mental. Ofrece al equipo un espacio donde explorar la petición, conectar ideas y mantener visibles las preguntas sin respuesta antes de decidir qué desarrollar.
En esta guía seguiremos a un equipo ficticio que trabaja en un producto con espacios de trabajo compartidos. Los nuevos clientes crean una cuenta, configuran un espacio de trabajo e invitan a sus compañeros. Se ha pedido al equipo que mejore esa experiencia.
Llevaremos la petición desde una conversación abierta hasta una pequeña tarea claramente descrita en Jira. Puedes seguir el mismo proceso con cualquier herramienta de mapas mentales.
1. Empieza por la petición, sin tratarla como la respuesta
«Facilitar la incorporación» expresa una intención. Todavía no nos dice dónde encuentran dificultades las personas ni qué debería cambiar.
El equipo sitúa Mejorar la incorporación en el centro del mapa y añade cuatro ramas:
- Crear una cuenta
- Configurar un espacio de trabajo
- Invitar a compañeros
- Realizar juntos una primera acción útil
Esto da estructura a la conversación. En lugar de hablar de la «incorporación» como un único gran problema, las personas pueden señalar una parte concreta de la experiencia.
El equipo añade lo que sabe hasta ahora junto a las ramas correspondientes. En nuestro ejemplo ficticio, el equipo de soporte ha recibido preguntas sobre dónde invitar a compañeros. Durante una sesión de observación, una persona que acaba de crear un espacio de trabajo busca una opción de invitación en la pantalla de inicio del espacio. La opción existe, pero está dentro de la configuración del espacio de trabajo.
Estas observaciones indican por dónde investigar. No demuestran que haya que reconstruir todo el proceso de incorporación.
El equipo deja las otras ramas en el mapa y centra su atención en Invitar a compañeros.
2. Separa lo que sabes de lo que supones
Es fácil que una explicación empiece a parecer un hecho cuando alguien la expresa con seguridad.
«La gente no invita a sus compañeros porque el proceso de invitación es demasiado complicado».
Quizá. Pero ¿les cuesta encontrar el formulario de invitación, completarlo o entender por qué deberían invitar a alguien en ese momento? Son problemas distintos.
Dentro de la rama de invitaciones, el equipo crea tres grupos.
Observado
- El equipo de soporte ha recibido preguntas sobre dónde invitar a compañeros.
- El propietario de un espacio de trabajo buscó las invitaciones en la pantalla de inicio.
- La opción de invitación actual está dentro de la configuración del espacio de trabajo.
Supuesto
- Un punto de acceso más visible ayudaría a encontrarla.
- Es posible que algunos propietarios no sepan que invitar a compañeros es un siguiente paso útil.
Todavía no está claro
- ¿Pueden los propietarios completar el formulario existente una vez que lo encuentran?
- ¿Entienden las personas que reciben una invitación qué deben hacer a continuación?
Las etiquetas importan más que el estilo visual. Cualquier persona que mire el mapa debe poder distinguir una observación de una posible explicación.
Antes de elegir una solución, el equipo pide a algunos nuevos propietarios de espacios de trabajo que intenten invitar a un compañero. Observa dónde buscan y pregunta qué esperan que ocurra, sin enseñarles primero la opción de invitación.
En este ejemplo, las sesiones sugieren que encontrar el formulario es el obstáculo inmediato. Una vez que se les muestra el punto de acceso, los propietarios pueden completarlo. La experiencia del destinatario todavía requiere una revisión aparte.
Ahora el equipo puede describir un problema más concreto:
“Los nuevos propietarios de espacios de trabajo no encuentran fácilmente dónde invitar a sus compañeros.”
Es lo bastante específico como para orientar la siguiente conversación. También es algo que el equipo puede revisar después de introducir un cambio.
3. Explora varias respuestas al mismo problema
Con el problema más claro, el equipo vuelve a las posibles mejoras. Añade tres opciones al mapa:
- Poner una acción Invitar a compañeros en la pantalla de inicio del espacio de trabajo.
- Añadir un paso de invitación al proceso de configuración inicial.
- Enviar un correo de seguimiento que explique cómo invitar a compañeros.
Todas las opciones podrían ayudar, pero cada una llega al propietario en un momento distinto.
La acción en la pantalla de inicio estaría disponible cuando alguien volviera a su espacio de trabajo. Un paso durante la configuración presentaría las invitaciones desde el principio, pero algunos propietarios quizá no estén listos para invitar a otras personas todavía. Un correo podría servir de recordatorio, aunque el propietario tendría que volver al producto.
El equipo escribe una breve nota junto a cada opción para explicar qué pretende facilitar. Así la conversación sigue vinculada al problema, en lugar de convertirse en una votación sobre la funcionalidad favorita de cada persona.
No hace falta incluir en el mapa todas las soluciones imaginables. Empieza con unas pocas respuestas plausibles y pregunta:
- ¿Aborda esto la dificultad que observamos?
- ¿Ayudará en el momento en que el propietario lo necesite?
- ¿Qué tendríamos que averiguar o cambiar para que funcione?
Un mapa útil facilita la conversación sobre estas decisiones. Tener más ramas no lo hace automáticamente mejor.
4. Elige un primer paso útil
El equipo decide probar una acción de invitación visible en la pantalla de inicio del espacio de trabajo.
¿Por qué esta opción? Responde directamente al lugar donde buscaban los propietarios y permite usar el formulario de invitación existente. Además, la acción sigue disponible para quienes decidan invitar a compañeros más adelante.
Es un punto de partida, no una afirmación de que todos los problemas de incorporación estén resueltos.
El equipo amplía la rama seleccionada con el alcance acordado y anota junto al plan las ideas aplazadas y la investigación pendiente:
En esta mejora
- Añadir una acción de invitación con una etiqueta clara en la pantalla de inicio del espacio de trabajo.
- Abrir el formulario de invitación existente desde esa acción.
- Mantener los permisos de invitación y el comportamiento de envío existentes.
Más adelante
- Valorar si conviene incluir un paso de invitación en la configuración inicial.
- Valorar si sería útil un recordatorio posterior.
Por investigar
- Revisar la experiencia de recibir y aceptar una invitación.
Mantener estos grupos visibles ayuda a evitar que la conversación reabra una y otra vez las mismas decisiones. La idea del correo no ha desaparecido. La experiencia del destinatario no se ha olvidado. Simplemente no forman parte de esta primera mejora.
En este punto, el equipo también consulta a las personas que implementarán el cambio. Reutilizar un formulario existente parece sencillo, pero puede haber restricciones que afecten al enfoque. Es mejor descubrirlas antes de dar por cerrado el alcance.
5. Describe qué debería poder hacer una persona
«Añadir un botón de invitación» describe un cambio en la interfaz. Dice menos sobre la experiencia que el equipo quiere crear.
Una pregunta más útil es:
“¿Qué debería poder hacer el propietario de un espacio de trabajo cuando esta mejora esté terminada?”
El equipo acuerda una breve lista de comprobaciones:
- Un propietario con permiso para invitar a compañeros puede encontrar una acción Invitar a compañeros en la pantalla de inicio del espacio de trabajo.
- Al seleccionarla, se abre el formulario de invitación existente para el espacio de trabajo actual.
- El propietario puede completar la invitación utilizando el proceso existente.
- Una persona sin permiso para invitar no obtiene acceso mediante la nueva acción.
- La acción se puede usar en los tamaños de pantalla compatibles con el producto y se puede acceder a ella con el teclado.
Estos son criterios de aceptación: condiciones observables que el equipo puede usar para comprobar su trabajo. No tienen por qué parecer una especificación técnica.
También hay dos preguntas distintas que conviene separar. ¿Hemos entregado el cambio acordado? Se responde comprobando estas condiciones. ¿El cambio ha facilitado encontrar las invitaciones? Requiere observar cómo lo usan las personas.
Un botón puede funcionar exactamente según lo especificado y aun así pasar desapercibido.
6. Traslada el trabajo acordado a Jira
El mapa ha ayudado al equipo a explorar la petición y tomar una decisión. Ahora la mejora seleccionada está lista para convertirse en un trabajo que alguien pueda asumir.
El equipo crea un ticket de Jira para el resultado acordado. No crea un ticket por cada rama del mapa.
Esto es lo que podría contener ese ticket:
Título: Hacer accesibles las invitaciones a compañeros desde la pantalla de inicio del espacio de trabajo
Por qué importa: Los nuevos propietarios de espacios de trabajo han tenido dificultades para encontrar la opción de invitación en la configuración. Queremos que puedan iniciar una invitación desde la pantalla de inicio, donde ya la buscan.
Alcance: Añadir una acción Invitar a compañeros que abra el formulario de invitación existente para el espacio de trabajo actual. Mantener las reglas de permisos y el funcionamiento de las invitaciones existentes.
No incluido: Un nuevo proceso de configuración, correos de recordatorio o cambios en la experiencia de aceptar una invitación.
Criterios de aceptación: Incluir las comprobaciones acordadas en la sección anterior.
Contexto de planificación: Añadir un enlace al mapa para que cualquiera que trabaje en el ticket pueda ver las observaciones, las alternativas y la decisión sobre el alcance.
Según cómo trabaje el equipo, el diseño y la implementación pueden convertirse en tareas separadas. Divide el trabajo cuando eso aclare las responsabilidades o la entrega, en lugar de copiar automáticamente la estructura del mapa en Jira.
Una rama organiza el pensamiento. Un ticket describe un trabajo. No necesitan una correspondencia uno a uno.
Si tu herramienta de mapas mentales se conecta con Jira, quizá puedas crear el ticket desde el nodo seleccionado y mantener la conexión visible en el mapa. Si no, puedes crear el ticket por separado y añadir un enlace. En cualquier caso, revisa el ticket antes de pasárselo a otra persona: la etiqueta breve de un nodo rara vez contiene todo el contexto necesario.
Una vez que empiece la ejecución, mantén el estado y las responsabilidades en Jira. Usa el mapa para el problema general, el razonamiento detrás de la decisión y las preguntas que siguen abiertas. Así cada espacio tiene una función clara y se reduce la tentación de mantener dos listas de tareas separadas.
7. Comprueba si el problema original se ha reducido
Después de publicar el cambio, el equipo vuelve a la frase que escribió antes:
“Los nuevos propietarios de espacios de trabajo no encuentran fácilmente dónde invitar a sus compañeros.”
¿Pueden ahora los nuevos propietarios encontrar la acción de invitación sin que se les indique dónde está? ¿Pueden continuar por el formulario existente? ¿Las conversaciones con soporte sugieren que sigue existiendo la misma confusión?
Si el equipo dispone de métricas de producto adecuadas, también puede observar cuántos nuevos propietarios de espacios de trabajo inician y completan una invitación. Esas cifras necesitan contexto: algunos propietarios pueden trabajar solos por decisión propia y otros cambios pueden afectar a los resultados.
Para esta historia ficticia no necesitamos inventar un resultado exitoso. El siguiente paso útil es observar qué ocurre y añadir ese aprendizaje al mapa.
Si los propietarios encuentran la acción pero se bloquean más adelante, el equipo tiene un problema más específico que explorar. Si el cambio ayuda, puede decidir si merece la pena abordar otra mejora.
La petición original era amplia. El plan resultante es concreto: un problema claro, una respuesta elegida, un alcance manejable y una forma de comprobar si ha ayudado.
Eso es lo que hace útil al mapa. Lleva la conversación de «deberíamos mejorar esto» a un siguiente paso acordado, manteniendo a la vista el razonamiento y las preguntas pendientes.
Artículos relacionados
Hablemos
¿Tienes preguntas sobre este artículo? Hablemos de tus objetivos técnicos.