Todo parte de una necesidad: los desarrolladores no se sentían partícipes de la solución que implementaban, no sentían que habían colaborado en su creación.
Dentro del equipo de desarrollo hay diferentes caminos (tracks) que se deben trabajar en paralelo. El track de delivery o business as usual es dónde el equipo piensa en el hoy, en lo que solucionarán y desarrollarán a corto plazo. En el track de discovery se investigan y detectan necesidades que deben servir para el largo plazo, el futuro. Es habitual que el equipo esté enfocado en desarrollar la solución y no tanto en pensar e investigar qué construir a medio y largo plazo. Pero hay un nexo que une ambos caminos: la definición y creación de la solución recogiendo los aprendizajes detectados en la investigación para maximizar el valor entregado.
Este nexo en función del equipo se plasma como el “final” del discovery track o como el “principio” del delivery track. Pero, independientemente del camino al que pertenezca, hacer que los desarrolladores participen en el proceso de definición y diseño es muy enriquecedor. No solo porque la solución ofrecida dispone de más puntos de vista, sino también aumenta su implicación en el desarrollo de la misma, dado que la solución es compartida e ideada por todo el equipo.
Es por eso que durante Noviembre 2020 estuvimos trabajando en incorporar la metodología Design Sprint a nuestro ritmo de trabajo habitual implicando a los desarrolladores en el proceso de diseño desde el primer minuto. ¡Y además en remoto! ¿Quieres saber cómo lo hicimos?
¿Qué es el Design Sprint?
El Design Sprint es una metodología desarrollada en Google por Jake Knapp que permite crear soluciones y validarlas con usuarios reales en solo 5 días. Más que el límite temporal, lo interesante de la metodología es el proceso que se sigue para idear y testear la solución empezando con la detección del problema o necesidad, explorando posibles ideas, seleccionando las que mejor se ajustan, prototipándolas y testeándolas.
Imagen de The Sprint Book
Con esta metodología vimos una gran oportunidad para implicar a todo el equipo definiendo conjuntamente la solución desde 0, hecho que nos resolvía la problemática de hacer a los desarrolladores más partícipes de la solución final.
Dentro de nuestra forma de trabajo PEAK y nuestras rutinas de equipo enfocadas a la entrega continua de valor, no podíamos hacer que todo el equipo se centrara 5 días seguidos (como define la metodología) para obtener el resultado de diseño, pero sí podíamos realizar sesiones con partes del método encajándolas en nuestras dinámicas de equipo y procesos.
Trabajo previo: Set the Stage
Antes de empezar las sesiones de ideación recopilamos toda la información existente sobre el tema y revisamos el mercado en busca de buenas prácticas de la competencia directa o indirecta que nos pudieran ayudar a detectar oportunidades o necesidades no verbalizadas.
A nivel interno recogimos todas las quejas que los usuarios nos habían trasladado en el CSAT y NPS, analizamos las llamadas recibidas a través de Atención al cliente, revisamos los vídeos de interacción grabados en Hotjar para detectar posibles patrones de conducta erróneos e incluso analizamos a nivel cuantitativo el uso.
Y al ser en remoto, toda esta información obtenida de problemas y necesidades la preparamos para que pudiera ser consumida en Miro (herramienta de colaboración online) creando un lienzo para cada una de las sesiones.
Sesión 1: Mapeo de las funcionalidades
Esta fue la primera sesión con todo el equipo y era imprescindible alinearnos. Para ello, no solo debíamos compartir toda la información recopilada, sino que planteamos un ejercicio introductorio para estar todos en la misma página. La idea era definir entre todos cuál era el objetivo del proyecto, qué queríamos conseguir.
Una vez definido el objetivo y revisados todos los insights del discovery, les pedimos a todos los participantes que tradujeran los problemas y necesidades detectadas en How Might We Questions (HMW).
La técnica de preguntas HMW plantea los problemas como oportunidades de diseño y abre la mente para que encontremos diferentes soluciones a ese problema. El hecho de transformar el problema en pregunta estimula al participante a encontrar diferentes vías de resolución ejercitando el pensamiento creativo. ¡Y así fue!
Con los HMW creados realizamos un ejercicio de brainstorming individual de ideas y gracias al intentar extraer soluciones a esas preguntas se pudo llegar a una propuesta mucho más amplia y diversa.
Posteriormente compartimos las ideas y las organizamos por temáticas que se tendrían que solucionar dentro del proyecto. Esta sesión nos sirvió para sentar las bases de lo que sería la solución y lo que pedimos fue buscar ejemplos de cómo la competencia u otros sectores solucionaban las ideas propuestas para llevarlo trabajado para la próxima sesión.
"Una vez introducidos en este tipo de dinámicas y acostumbrados a la herramienta se hace tan ágil y útil como estar todos en la misma sala con post its"
– Alfredo Valenzuela, PO del equipo
Sesión 2: Sketch & Decide
Esta segunda sesión no se realizó el día siguiente como indica la metodología, sino que dimos un tiempo de margen para poder realizar el pre-work planteado. Otro cambio respecto a la metodología de Design Sprint, es que en ella los temas de Sketch y Decide se realizan en dos sesiones separadas y, en nuestro caso, decidimos acortarlo y juntar las dos dinámicas para no dilatar tanto los tiempos dado la complejidad de incorporarlo en el track de delivery.
Así, decidimos realizar un sketch day con el equipo empezando con el pre-work realizado. Para ello, realizamos un ejercicio llamado lightning demos dónde el equipo debía compartir las funcionalidades definidas en la sesión anterior con ejemplos de otras webs del sector o que no tuvieran nada que ver pero que ayudaran a ilustrar la idea. Si no encontraban el ejemplo haciendo benchmark también podían ejemplificar su idea a través de dibujos.
Una vez explicados todos los ejemplos, marcamos aquellas ideas que no habían sido ejemplificadas y decidimos seleccionar las funcionalidades más interesantes. Cada participante disponía de 3 votos y debíamos marcar aquellos 3 ejemplos que nos gustaría incorporar a nuestra solución. Sí, eso os recordará al libro Steal like an artist de Austin Kleon. Sé que no tiene mucho que ver con Design Sprint pero la explicación de este libro nos ayudó a incentivar los buenos criterios de elección de las funcionalidades.
Posteriormente escogimos las ideas que estaban más verdes para darles un poco más de forma y trabajarlas conjuntamente. Para ello, realizamos varios Crazy 8”. En este ejercicio cada participante disponía de un folio Din A-4 que debía doblar en 8 trozos. Debían escoger 1 de las ideas a trabajar y pensar en 8 minutos, 8 posibles soluciones. Una vez finalizado el tiempo debían introducir sus dibujos e ideas en el lienzo del tablero de Miro destinado para ello. Este ejercicio sirvió para ejercitar su mente y exprimir la imaginación con 8 posibles soluciones.
A parte de compartir, en este punto debíamos seleccionar varias ideas de las propuestas (las más viables) para diseñarlas un poco más en profundidad con la metodología de solution sketches. Aquí, no solo era importante el diseño sino que fuera lo más explicativa posible.
“La sesión fue bastante dinámica por lo que se me hizo entretenida, además surgieron muy buenas ideas.”
– Jesús Salas, Backend del equipo
Todo el material generado de la sesión, nos sirvió para plantear dos prototipos del proyecto.
Sesión 3: Prototipado
Aunque en la metodología de Design Sprint los prototipos los realizan todos los miembros conjuntamente, para optimizar el tiempo, decidimos que UX se encargaría de transformar todas las ideas surgidas en dos prototipos navegables. Una vez disponíamos de las dos propuestas las presentamos al equipo.
Esta sesión sirvió para iterar y mejorar en vivo las propuestas con todo el feedback recibido y probar varias ideas que surgieron de la visualización de los prototipos.
Sesión 4.1: Test con stakeholders internos
Antes de testearlo con usuarios reales, decidimos realizar el test con personas de otros departamentos de la empresa como Atención al cliente, comercial,... ya que nos podrían detectar posibles problemas o necesidades de nuestros usuarios dado su estrecha relación con ellos y podríamos llegar al test con los usuarios con un prototipo más consolidado.
Estas validaciones previas nos sirvieron para levantar dudas que les podían surgir también a los usuarios y solucionarlas antes de testearlo con ellos.
Sesión 4.2: Test con usuarios
Finalmente, y como último paso de la metodología testeamos los prototipos navegables en alta fidelidad con usuarios reales. El equipo podía asistir a todas las sesiones y, en caso de no poder, las sesiones se grababan para su posterior visualización. En este punto realizamos test de tareas para intentar que la experiencia fuera lo más real posible y lo combinamos también con entrevista para entender el uso real de las funcionalidades existentes.
Una vez realizadas las entrevistas se presentaron las conclusiones al equipo con visionado de clips de videos de los momentos más relevantes.
Retos y aprendizajes
Después de llevar a cabo todo el proceso del Design Sprint adaptando los ejercicios a nuestras rutinas de trabajo podemos decir que el feedback del equipo fue muy positivo y se sintieron partícipes de la solución realizada.
“De las dinámicas me ha gustado el hecho de aportar en el diseño y escuchar los puntos de vista de todos"
– Antonio Asenjo, Backend del equipo
Además, también destacan la gran cantidad y calidad de las ideas surgidas dado los diferentes puntos de vista.
“Me pareció muy interesante ya que salieron muchas buenas ideas, y me permitió enfocarlo desde otro punto de vista, más allá del punto de vista técnico”
– Emilio Villuendas, Frontend del equipo
Eso sí, si nos centramos en los retos, podemos decir que no pudimos hacer un Design Sprint al uso en 5 días consecutivos ya que debíamos combinar esta preparación de lo próximo con el día a día y la entrega de valor continúa.
A modo de recomendación, si queréis realizar una sesión de este tipo es necesario analizar el objetivo: ¿se quiere un cambio radical o únicamente queremos cambiar una funcionalidad? Si el objetivo es realizar un proyecto o una construcción de un bloque con varias funcionalidades, esta dinámica te será muy útil. Por lo contrario, si lo que queremos es mover métricas rápidamente o iterar una funcionalidad en específico hay otro tipo de dinámicas más adecuadas para ello.
Top comments (3)
¡Muy interesante!
Sweet!
Mil gracias por compartir esto, me chifla la organización de equipos y ver como encaja todo 😍