Fuck wireframes!

¿Cómo aprender a trabajar con la incertidumbre?

Uno de mis principios de diseño favoritos se relaciona con la incertidumbre (Embrace ambiguity, IDEO). Si queremos resultados de calidad en nuestros proyectos, si queremos soluciones diferentes que respondan a necesidades reales, tenemos que retarnos a navegar lo desconocido.

Hablar de divergencia es hablar de incertidumbre. Cuando empezamos una
investigación, a medida que profundizamos en el tema nos damos cuenta de lo poco que sabemos y de la necesidad de leer, hablar con personas y avanzar sin tener muy claro el destino. Cuando ideamos, nos obligamos a lanzar conceptos abstractos o irracionales esperando que conecte con algo y se convierta en nuestra gran disrupción.

Hace unos meses caí en un proyecto con uno de nuestros clientes de banca en el que pusimos en práctica una metodología de trabajo basada en la gestión de la incertidumbre. Más allá de los buenos resultados conseguidos, me acercó a una forma de pensar (y a varias herramientas) que influye mucho en la manera en la que enfoco mis diseños a día de hoy. Fue un proyecto liderado por Pablo Gil y aquí traigo algunas de las cosas que aprendí de él.

El equipo confuso, intentando entender nuestras nuevas funciones. Pablo, transmitiendo las actitudes necesarias para afrontar el proyecto.

Output vs. outcome

Este proyecto se planteó con toda la intención (y los recursos) de crear un servicio de referencia dentro y fuera del sector financiero. Partíamos de una idea sencilla conceptualizada en una fase previa del proyecto y nuestro cometido era llegar a la fecha del lanzamiento maximizando el valor que podía aportar dicho servicio a pequeñas y medianas empresas, minimizando la posibilidad de fallo.

“So long as teams stay curious, uncertainty isn’t cause for alarm.” John Campbell, Experience Design Content Strategist at Airbnb and a poet.

Algunas veces nos enfrentamos a proyectos sencillos y otras a retos más complejos. Sea cual sea nuestro caso, los resultados del proyecto van a ir directamente relacionados con nuestra capacidad para cuestionar el status quo, y con el grado en el que consigamos involucrar a las personas — los empresarios que se enfrentan al problema cada día.

Así pues, depende de nosotros. Podemos dar unas pinceladas de diseño a las ideas que nos trasmiten los encargados del negocio, o poner a funcionar nuestra maquinaria creativa y forzarnos a mirar todas las alternativas posibles.

Una frase lo resume todo: ciclos de aprendizaje iterativo

En base a metodologías de Diseño de Producto, Lean Startup y Dual Track diseñamos el camino metodológico más apropiado para el reto que teníamos delante.

Lo primero fue dividir nuestro servicio en pequeñas porciones. El User Story Mapping es la herramienta perfecta ello. Nos ayuda a definir todo el camino de las empresas (nuestros usuarios en este caso) a través del servicio y ordenar de menor a mayor complejidad todas las soluciones alternativas para cada uno de sus pasos. Para definir nuestro MVP, establecimos hasta qué grado de incertidumbre estábamos dispuestos a asumir según los recursos y tiempo disponible para cada caso (nota: en este momento hay que ser extremadamente honestos. A medida que los sprints se acumulan, los equipos pueden llegar a saturarse si cogen demasiada carga, o perder la motivación en el caso contrario).

Reproducción de un User Story Mapping

Una vez aclarado cuál era nuestro MVP, planificamos los sprints de diseño. Empezaríamos llevando a test aquellas porciones que más dudas nos planteaban. A medida que despejábamos la incertidumbre, construíamos sobre lo aprendido añadiendo nuevas partes del servicio.

La toma de decisiones

Si hablar de divergencia es hablar de incertidumbre, la convergencia se aprovecha de todo ese camino recorrido para aplicar el razonamiento crítico y tomar las mejores decisiones.

Una vez más juntos, analizando las opiniones (literales) de las personas con las que habíamos testado nuestro prototipo

Aunque nada nos gustaba más que darle vueltas y repensar soluciones, los tiempos y resultados esperados ejercen mucha presión. En la planificación del proyecto, como es habitual, se entrecruza la elaboración de entregables y la construcción de narrativas que ayudan a comunicar de manera eficaz los avances el proyecto. Tan importante es una cosa como la otra.

¿Cómo tomar las decisiones necesarias para avanzar a un ritmo adecuado en este contexto? Todos a una. Cada test que hacíamos podía cambiar por completo el rumbo del proyecto por lo que nuestra apuesta debía ser completa. Teníamos una semana para construir la porción de servicio escogida hasta el último detalle. No presentábamos conceptos ni wireframes sino un prototipo que, en caso de validar nuestras hipótesis, pasaría a ser directamente nuestro producto final.

Pensando soluciones alternativas para evaluar nuestras hipótesis, uno de esos espacios de encuentro para todas las personas implicadas directa o indirectamente en el proyecto.

Como equipo aprendimos a sumarnos, desde nuestras distintas perspectivas
(Research, UX, Visual, Creative Technology,… ), fuese cual fuese el momento del proceso de construcción. Utilizando las hipótesis de la misma forma que usamos las instrucciones de un mueble de Ikea, cocreábamos y construíamos nuestro prototipo a validar.

Incertidumbre = cambios = aprendizaje

Desde mi punto de vista, la piedra angular de la metodología era una reunión que hacíamos cada dos viernes y a la que llamamos “sesión de aprendizajes”. Esta reunión involucraba a todas las personas relacionadas con el proyecto. Los equipos de diseño, desarrollo, negocio, legal, … nos juntábamos a evaluar el trabajo realizado y decidir lo que vendría en las 2 semanas siguientes. Era el momento de compartir toda la información generada durante la semana desde los 3 motores (clientes, negocio, tecnología) y decidir como si fuéramos una única persona (en lugar de tratar de convencernos los unos a los otros). Liderando esta reunión, otra herramienta estrella:

Matriz de evaluación de hipótesis. A la izquierda, las hipótesis. Después, razones para el sí y para el no (basadas en las opiniones de los empresarios a los que enfrentábamos nuestro prototipo) y en el círculo la nota: verde = queda validada; amarillo = la hipótesis podría tener sentido, aunque debemos seguir trabajando para validarla; roja = rechazada, es el momento de replantear el servicio (o una parte del mismo).

Conectando las dos herramientas, la matriz de hipótesis nos permitía medir la certeza alcanzada para cada momento del User Story Mapping y decidir si estábamos suficientemente satisfechos como para seguir avanzando.

En Garaje siempre hablamos de que, como diseñadores, tenemos la obligación
de mantenernos hambrientos (curiosos, ambiciosos). Este proyecto supuso la
oportunidad de sumergirnos en un entorno disruptivo, con herramientas
totalmente nuevas y trabajando codo con codo con nuestro cliente. De hecho,
fue la confianza del propio cliente en el equipo la que nos impulsó a reimaginar nuestras funciones y descubrir nuevas habilidades.

Soy Service Designer en Garaje de Ideas — un estudio de Diseño Estratégico y Experiencia de Usuario. www.garajedeideas.com