Hackeando los Design Sprint para hacer que siempre funcionen

tanto en startups como en enterprises

Durante varias semanas estuve pensando cómo escribir y estructurar este artículo, para contar bien mi experiencia de cómo he logrado hacer que la famosa Design Sprint de Google (lo mejor que hay por estos días para diseñar soluciones validadas), funcione en el escenario más adverso: Las grandes corporaciones. ¡Aquí vamos!

Érase una vez…

Hace un año atrás, decidí comprarme el libro Sprint como parte de una investigación que respondía a la inquietud de cómo hacer que el proceso de diseño lograra ser mucho más eficiente y menos costoso aún -de lo que ya era con Lean UX.

Quise entender de primera fuente, que tan interesante era esta “famosa” metodología de la que venía escuchando hace un buen tiempo. Y resultó sorprenderme con creces. Ese grupo de diseñadores cracks de Google Ventures, encabezados por Jake Knapp, habían logrado acortar el proceso de diseño de manera asombrosa, probando con éxito en muchas startups de Sillicon Valley, una metodología que servía para desarrollar o validar ideas de productos y casi cualquier desafío que tuvieran por delante. Todo lo que contaban en el libro me hizo mucho sentido y quedé tan entusiasmado, que quise ponerme a trabajar de ese modo casi inmediatamente.

El espejismo de la utopía

Sin embargo, la primera duda que me surgió (y que de seguro a muchos, de los que aún no han tenido el placer de trabajar de esta manera, también les surge), es que si dado el contexto en que esta metodología se inventó –el de las startups– podría realmente ser aplicada con proyectos de grandes empresas. Un escenario donde la convocatoria de stakeholders, con poder decisión, suele ser difícil. Porque los altos y medianos cargos están siempre con la agenda muy apretada y contar con su participación en largas reuniones seguidas, parece ser –muchas veces– imposible.

Con mayor razón cuando se trata de diseñar. Porque al final se supone que a uno, como consultor externo, lo contratan para dar solución a los problemas casi como un mago, para que cuando el proyecto termine, el cliente levante el dedo para arriba o para abajo, para decirnos si está conforme o no con el resultado. Dependiendo de qué tan convincentes seamos para “venderle” la solución, en la que seguramente, trabajamos solos en nuestro laptop durante varias semanas.

Pero esta metodología al contrario de eso, tiene como requerimiento clave la participación y colaboración directa de nuestro cliente, en su más amplio espectro de personas y cargos. Es absolutamente necesario que en la mesa de trabajo estén presentes todos: jefes de proyecto, desarrolladores, marketing, diseñadores y cualquier persona que trabaje en la empresa, que pueda aportar diferentes visiones o experiencias relacionadas con el problema, transformándose en co-creadores.

Y aquí, los escépticos –como yo también lo era– pensarán en que convencer a dichas personas, a que como dice el libro: liberen sus agendas por una semana completa y se dediquen full time a nuestro proceso, es derechamente una utopía. Por lo tanto, inevitablemente el único término que nos ronda en la cabeza es: Imposible. Pero yo he comprobado que no lo es, y eso es lo que quiero contar.

Manos a la obra

La primera vez que me lancé a probar Design Sprint, lo hice como un taller. Puse en práctica la metodología, para ayudar a un área de diseño y desarrollo de una importante entidad educacional. Una unidad encargada, por una parte, de desarrollar el software para solucionar diversos problemas administrativos y por otra parte, ser también los proveedores de hardware para todos los departamentos internos de la organización. Un área con desafíos complejos, pero con prácticas un tanto obsoletas, para responder con velocidad a sus requerimientos, donde habitualmente ni siquiera se hacen el tiempo o saben cómo validar si las soluciones son realmente efectivas o sirven bien para lo que deben.

Así que armamos equipos de 8 personas, mezclando perfiles bien representativos, como los que anteriormente describí y desarrollamos 2 sprints. Cada uno enfocado en un problema diferente. La idea principal era entregarles una herramienta que les permitiera continuar desarrollando e iterando mejores soluciones para todos los desafíos que venían. Para mejorar sustantivamente sus procesos, con una mirada más innovadora. Y de paso, por mi parte, experimentar y sumergirme de lleno en la práctica de esta metodología, para adaptarla o mejorarla, según la necesidad o el escenario al que me enfrentara más adelante. Y por supuesto alentar, con el ejemplo a mis compañeros del equipo a seguir mis pasos y lanzarse también, sin miedos ni prejuicios.

El resultado fue increíble, los equipos quedaron súper motivados y lograron ver cómo en una semana pudieron modelar una solución y probar con usuarios las hipótesis que levantaron y detectar en muy poco tiempo los errores que debían corregir. Un tremendo aprendizaje para ellos y para mí.

Luego, aprovechando el entusiasmo, intenté hacer lo mismo con un cliente corporativo y no tuve buenos resultados, porque fue imposible conseguir que los stakeholders estuvieran dispuestos a dedicar 4 semanas completas a 4 sprints. El proyecto se llevo a cabo con un intento fallido de la metodología y resultó ser un híbrido muy extraño entre la vieja manera de hacer las cosas y la nueva. La conclusión: era absolutamente necesario adaptarlo.

Adaptación

Luego de las primeras experiencias con Design Sprint, revisé una a una las actividades y los tiempos y logré dar con la manera de poder adaptar el proceso y acortarlo mucho más, sin romper el espíritu ni dañar la integridad de la metodología. Mantener su esencia intacta, pero acomodada a las circunstancias.

Así que facilité un nuevamente un Design Sprint, durante los 5 días como dice el libro, pero acorté los tiempos por actividades. Lo que nos permitió hacer todo en jornadas de 3 horas diarias, en vez de 6 como dicta la metodología. Y funcionó perfecto.

En retrospectiva, además de validar que se podía hacer en menos tiempo del propuesto, sin sacrificar ninguna actividad, me di cuenta también que quizás era posible suprimir algunas dinámicas, para darle más espacio y tiempo a otras que resultan ser fundamentales. Ese sería el próximo paso en mi aventura de poner a prueba los límites de la metodología.

El desafío mayor

Me tocó nuevamente el turno de enfrentarme al cliente “enterprise”, donde por segunda vez, tuve la oportunidad de proponer trabajar con Design Sprint. Y es ahí donde surge la problemática que describía al comienzo del artículo y por el cual falló mi primer intento en este contexto. El gran desafío era como convencer al cliente de lo bueno que trabajar así, pero por sobre todo, requerir de su participación y compromiso durante 5 días continuos por varias semanas. Así que pensando en cómo podría hacerlo funcionar, me la jugué por hacer el proceso en los mismos 5 días, pero con la participación del cliente limitada a sólo 3 días. ¿Cómo?

Simplificación

Gracias a la retrospectiva de la experiencia adquirida hasta ahí, concluí que cada día de sprint se sustenta en tareas claves, las cuales son irremplazables y absolutas responsables de que la metodología funcione. Así que la propuesta consistió básicamente en quitarle carga a los stakeholders y hacerlos participar sólo de lo esencial, simplificando el proceso a lo siguiente:

• Día 1: Hipótesis, objetivos y mapeo de la solución.
• Día 2: Revisión de referentes y bocetos de la solución.
• Día 3: Análisis, discusión, votación y convergencia en la solución a prototipar.
• Día 4: Prototipado de la solución.
• Día 5: Pruebas con usuarios y conclusiones.

Por lo tanto, la idea era comprometer al cliente corporativo, sólo de lunes a miércoles en reuniones, inicialmente de 3 horas el lunes y martes y de 1,5 horas el miércoles, por cada semana de sprint. Lo importante es mantenerlo siempre conectado con el proceso y siendo siempre un co-creador activo de las soluciones que se vayan probando para cada hipótesis. Lo que permite que no aparezcan sorpresas al final del proyecto. Además con la ventaja de poder obtener resultados semanales concretos y plasmados en un prototipo funcional y navegable.

¿Y qué pasa entonces con el jueves y viernes? Ese es un trabajo que asumo yo. Porque objetivamente, no es necesario forzar al cliente a prototipar, si para eso estamos nosotros los diseñadores. Tenemos los skills suficientes para hacerlo seguramente mejor que ellos. Lo mismo aplica para el viernes, cuando hay que ejecutar las pruebas. Sin embargo, la invitación a participar como espectadores está permanentemente abierta. Siempre y cuando, éstas se realicen bajo el concepto de “laboratorio de usabilidad”. Porque muchas veces, cuando el target de usuarios es amplio o exploratorio, personalmente prefiero los “test de guerrilla”, dado que los usuarios son mucho más honestos que en un ambiente de laboratorio. Seguramente una discusión que es material para otro artículo o con gusto para compartir un café.

Resultados actuales

Poner en marcha este modelo para hacer Design Sprint ha sido todo un éxito. Al menos así lo hemos sentido y estamos felices con el resultado en el equipo y el cliente también lo ha demostrado. Se nota su entusiasmo desde el primer sprint, porque pudo ver lo valioso y pragmático de trabajar así.

Así que hemos empezado a aplicar esta versión “hackeada” en todos los nuevos proyectos con excelentes resultados. Clientes contentos y equipo motivado. Mis compañeros y yo hemos estado trabajando ahora en pequeños ajustes y constante retrospectiva al final de cada proyecto para saber qué nos hizo falta y cuáles resultan ser los aciertos más concretos.

Hemos trabajado en proyectos con grandes y medianas empresas, instituciones públicas y privadas y por estos últimos días estamos probando la metodología en remoto con una startup, aprovechando las herramientas colaborativas para el mapeo o la votación de propuestas para el prototipo. Y creo que tenemos la mejor impresión. En un próximo artículo prometo contar el detalle de los ajustes y sobre la experiencia a distancia.

Resumen y conclusiones

Dada la positiva impresión que hemos tenido hasta ahora y lo motivante que ha sido liderar proyectos aplicando esta metodología, me gustaría resumir las grandes ventajas que yo le encuentro:

El pragmatismo Lean + Agile
Design Sprint es una maravilla del pragmatismo, que mezcla magistralmente las prácticas ágiles con el espíritu Lean, dejando de lado todo lo que realmente no aporta. Poniendo énfasis en lo que se conecta directamente con la propuesta de valor.

Al importar el modo de trabajo Agile>Scrum en sprints, empuja la eficiencia y evita la parálisis creativa.

Alineación de visiones
Como todo el equipo (cliente + consultores) son parte activa del proceso todo el tiempo, se toman las decisiones en conjunto y se evitan las sorpresas. El equipo aprende unido y en consenso se alinean en torno al mismo objetivo y propósito. Todos son co-creadores en un entorno de participación y colaboración.

Integración con desarrollo ágil
Dado que esta metodología está inspirada en el desarrollo ágil. Adaptando el proceso de diseño al modo de sprints con entregas semanales, logra conectarse naturalmente con los procesos de desarrollo en entornos ágiles.

Uno de los proyectos de los que trabajaron compañeros del equipo con Design Sprint, comenzó a ser desarrollado desde el término del primer sprint de diseño, lo que permitió una salida a producción con las primeras historias de usuario que daban vida real al MVP, mientras los demás design sprints estaban en progreso.

Y otra de los detalles interesante en esa misma línea, es que al término de cada sprint, el equipo de desarrollo puede empezar a escribir las historias de usuario y detectar los vacíos que puedan haber quedado fuera del prototipo, para que los diseñadores reaccionen en tiempo real y así no afectar el futuro del desarrollo.

Flexibilidad y versatilidad
Estoy absolutamente convencido que es una metodología muy flexible para cambios y adaptaciones en hartos sentidos. Basta con sólo cuidar el core y las actividades clave para que todo ande a la perfección.

La perfección no existe (?)
Es tanta la maravilla que he visto en la práctica de la metodología, que personalmente me ha costado encontrar algún problema de peso. Sin embargo, dudo que Design Sprint sea una metodología perfecta, es como cualquier otra, una guía, no una receta absoluta e inalterable para asegurar el éxito. Siempre es necesario probar diferentes sabores (como en la comida) y encontrar el ajuste preciso, el aliño o toque personal. Aguzar el oído en la tuerca y apretar hasta encontrar la medida justa. Aunque vale agradecer infinitamente a sus creadores por estos regalos y creo que es súper valioso también aportar con la mirada y la experiencia personal de todos nosotros, que siempre le servirán a los demás para ampliar sus perspectivas.

Diseñadores, desarrolladores y a todos los que trabajan en UX, los invito a que lean el libro (si aún no lo han hecho), que experimenten con la metodología y contribuyan al debate, para enriquecer el conocimiento de toda la comunidad.

Y por supuesto que cualquier duda que tengan, siempre feliz y dispuesto a ayudar. O si con su experiencia discrepan conmigo, bienvenidas las críticas también 😉

¿Te interesan las metodologías? ¿Quisieras saber cómo implementar este tipo de trabajo en tu empresa? En Continuum combinamos diseño, negocio y tecnología en un solo equipo, para crear productos y servicios que hacen la diferencia. También potenciamos a tu equipo para aprender y que siga haciendo la diferencia sin depender de nosotros. Escríbenos a hola@continuumhq.com para que nos tomemos un café y conversemos.