En Garage Labs trabajamos con metodologías ágiles y Lean que nos permiten crear desarrollos escalables, flexibles y modulares de alto impacto en cortos periodos de tiempo, manteniendo buenos estándares de calidad y diseño del software final.

Sabemos que las metodologías ágiles son adaptativas, por lo que en este artículo me dedicaré a explicar cómo aplicamos la metodología del Design Sprint a la Garage Labs para entender problemas y bosquejar posibles soluciones en conjunto con nuestros clientes para posteriormente comenzar con el desarrollo del producto.

Primero debemos entender qué es un Design Sprint. El Design Sprint es una metodología ágil creada en el 2010 por Google Ventures por Jake Knapp, John Zeratsky y Braden Kowitz, la cual se aplicó para crear la priorización de correos de Gmail, mejoras en Hangouts, Google Search, Google X, entre otras. Sin embargo, esta metodología ha sido implantada en diferentes sectores del mercado, como el de telefonía móvil, comercio electrónico, finanzas e incluso en áreas de la salud. No es exclusiva del área de los productos tecnológicos.

El Design Sprint permite prototipar y validar ideas con usuarios finales de manera rápida y efectiva o como dice Jake Knapp en el libro de Sprint “Un método único e infalible de cinco días para solventar problemas complicados”. Esta metodología también sirve para definir o refinar el roadmap de un producto o servicio.

‍

Las 5 etapas fundamentales del Design Sprint

Esta metodología posee 5 etapas fundamentales: Entender, Bosquejar, Decidir, Prototipar y Validar y, como lo plantea Jake Knapp en el libro de Sprint, cada etapa se debe realizar en un día de la semana para así completar los 5 días.

• Lunes: Se comienza por el final, esto es estableciendo un objetivo, luego se realizan preguntas de cuestionamiento, se establecen las protopersonas y al final del día se realizará un mapa del desafío.
  ‍
• Martes: Luego de comprender el problema y elegir un objetivo, el día martes se comienza con una revisión de ideas para que luego cada persona dibuje soluciones, siguiendo un proceso de cuatro pasos.
  ‍
• Miércoles: Se evalúa cada solución y se decidirá cuáles tienen la mejor oportunidad de lograr el objetivo a largo plazo.
  ‍
• Jueves: Se adopta una filosofía de falsificación para convertir lo de los otros días en un prototipo, una fachada realista con todo lo que se necesite probar con los clientes y/o usuarios.
  ‍
• Viernes: Se entrevista a los usuarios y se aprende al verlos reaccionar al prototipo, para luego validar la solución.

‍

Pero…¿Cómo lo aplicamos en Garage Labs?

Hay diferentes formas de ejecutar este método. Shopify ha adaptado esta metodología para realizarlo en 4 horas, llegando sólo hasta la etapa de “Decidir”.

Por otro lado Telefónica ha validado prototipos digitales al tercer día, comprimiendo todas las etapas. O como Continuum que realiza todas las etapas fundamentales pero reduciendo el tiempo de cada una.

Así es como diferentes empresas y startups han adaptado la metodología de acuerdo a sus tiempos y en el caso de Garage Labs llegamos hasta la etapa de Decidir, esto porque entendemos que tenemos un tiempo reducido al empezar un desarrollo.

Una vez que el área comercial haya hecho el traspaso al equipo de desarrollo, se comienza con el Sprint 0. Aquí es en donde nos tomamos nuestro tiempo para aplicar el Design Sprint.

Antes de empezar con cualquier sesión de Design Sprint debes contar con lo siguientes elementos que a nuestro parecer son fundamentales y no excluyentes.

• Desafío: ¿Cuál es el problema que se quiere solucionar? Si han decidido realizar un Design Sprint lo más probable es que ya tengas un GRAN DESAFÍO lleno de incógnitas y un sinfín de supuestos.
  ‍
• Equipo: Es necesario contar con el equipo adecuado y que éste sea interdisciplinario. En nuestro caso de parte de Garage siempre está presente un Diseñador UX, un Desarrollador Full Stack y un Product Owner. Acá son libres de incluir a quienes quieran, siempre y cuando haya, por lo menos, un Decisor por parte del/los clientes. Tip: Ojalá que el equipo sea pequeño, máximo 7 a 10 personas, para que así sea manejable la dinámica grupal.
  ‍
• Tiempo: Es necesario controlar el tiempo, ya que sólo dispondremos de 4 horas por día para ejecutar cada etapa. Tip: Ideal tener un timer que pueda estar a la vista de todos los participantes para llevar el tiempo de la sesión, pero también puedes usar el temporizador de tu celular.
  ‍
• Espacio: Ideal que el equipo esté de forma presencial y en un espacio amplio para que puedan moverse y jugar en la dinámica.

Una vez que ya contamos con lo esencial, iniciamos con la dinámica del Design Sprint.

‍

Sesión 1: Empatizamos. Entendemos (4 horas).

Lo primero que realizamos es la identificación de las protopersonas. Las protopersonas son las personas/usuarios que tendrán que interactuar con el software que se desarrollará posteriormente. No es necesaria una descripción completa, pero si es necesario identificarlos por su rol (¿son usuarios finales o backoffice?), rango etario y principales problemas.

Una vez realizado esto, se debe establecer un Objetivo:

• ¿Por qué queremos solucionar estos problemas?
  ‍
• ¿Para qué lo estamos haciendo?
  ‍
• ¿Cuál es el objetivo del desarrollo del software?

Por ejemplo, la finalidad de tener que desarrollar un e-commerce podría ser elevar las ventas de la empresa a través de un catálogo y un checkout simple.

Luego, cada miembro individualmente comienza a realizar las preguntas del tipo ¿Cómo podríamos llegar a tal objetivo?. Acá es en donde sacamos los post it y nos empezamos a cuestionar. Siguiendo con el mismo ejemplo de un e-commerce, las preguntas a realizar serían del tipo:

• ¿Cómo podríamos diferenciar un producto de otro más allá del nombre?
  ‍
• ¿Cómo podríamos exponer los productos en un catálogo simple?
  ‍
• ¿Cómo podríamos realizar un comparador de productos de la forma más sencilla posible?.

Lo importante de esta parte es poder identificar los Pain Points, estos son los puntos clave que impiden que el flujo operacional o el funcionamiento de la empresa ocurra de forma ideal.

Al finalizar las 4 horas de la primera sesión te darás cuenta que tienes todo un flujo de operación. Aquí es en donde entra el trabajo individualmente en equipo, en donde nosotros los Product Owner nos encargamos de recopilar toda la información de la primera sesión para realizar un Mapa de Usuario, anotando a la izquierda a los actores o roles que se relacionan, escribir al final a la derecha el objetivo, y en medio los hitos importantes del flujo, uniendo todo con flechas y palabras. Esto es lo que se analizará al día siguiente.

Sesión 2: Divergemos. Convergemos (4 horas).

En la segunda sesión, comenzamos realizando un resumen o un ayuda memoria de lo que se revisó el día anterior, en donde se dan unos minutos para notas e ideas.

Luego se comienza con la dinámica, aquí necesitarás harto papel, plumones y pegatinas de colores. Se realiza el Desvarío en 8 pasos. Cada persona del equipo trabaja individualmente, eligiendo 4 preguntas del tipo ¿Cómo Podríamos…? para poder bosquejar 8 posibles soluciones sobre esa pregunta o Pain Point.

Una vez terminado el tiempo, es hora de juntar el trabajo con el equipo en la pizarra. Uno a uno expone explicando en pocas palabras sus soluciones a ese Pain Point.

Una vez se hayan expuesto todos los bosquejos o dibujos, se procede a votar:

• Revisamos individualmente la lista de ideas, reduciéndola a dos o tres ideas, escogiendo las mejores.
  ‍
• Luego cada miembro del equipo dice en voz alta su preferida, poniendo una pegatina sobre la idea.
  ‍
• Se pueden poner las pegatinas sobre los elementos que más nos gustan de los bosquejos y así se generará un mapa térmico.

¿Qué solución, según a mi parecer, me parece más factible para cumplir con el objetivo? ¿Qué solución, según mi parecer, me parece que solucionará el/los problemas de las protopersonas?. Acá la variedad de expertise de las diferentes áreas del equipo es clave. Para mí como Product Owner puede ser más importante cumplir con el modelo de negocio del cliente, sin embargo para un Diseñador UX o para Marketing es más importante la experiencia de usuario.

Una vez se haya terminado con la votación, te darás cuenta que tienes un Bosquejo Final preliminar para poder desarrollar una solución.

Finalmente, el equipo de Garage entra a la oficina, y comienzan a redactar las Historias de Usuarios en conjunto en base a la votación antes realizada. No obstante, lo volvemos a realizar si encontramos nuevos Paint Points a lo largo del desarrollo y así vamos descubriendo cómo solucionar los problemas.

Como mencioné anteriormente, Garage se centra en las etapas de entender, bosquejar y decidir para el Design Sprint. Esto porque dentro de la metodología de Triple track nos centramos en prototipar, y validar con anticipación con los usuarios. Es importante recalcar que el trabajo individualmente en equipo es fundamental en el Design Sprint.

Si tu equipo no puede dedicar los 5 días de la semana para realizar de forma intensiva un Design Sprint, siempre puedes adaptar el marco original al contexto operativo de la empresa para así poder resolver problemas y probar nuevas ideas.