La mentalidad del facilitador: pisar el pedal de freno
El Design Thinking no es solo una excusa para jugar con pósits; es un enfoque riguroso y estructurado para resolver problemas muy ambiguos a partir de un conocimiento profundo del usuario final. Como facilitador de este proceso, tienes que hacer de «pedal de freno» de la sala. Los equipos están programados por naturaleza para correr hacia las soluciones, sobre todo cuando en la sala abundan ingenieros, perfiles de operaciones o directivos. Tu trabajo principal es combatir ese instinto. Tienes que obligar al equipo a quedarse en la ambigüedad incómoda y turbia del espacio del problema hasta que la verdadera naturaleza del dolor del usuario sea innegable. Si intentan saltar a una solución antes de entender del todo las dificultades del usuario, tienes que hacerles volver con firmeza.
Cuándo funciona de verdad el método (y cuándo falla)
Este taller es más eficaz cuando te enfrentas a un problema «perverso» (wicked problem). Son retos notoriamente mal definidos, sin un precedente claro en tu organización, o que dependen mucho de comportamientos humanos complejos, como averiguar cómo hacer que un proceso de onboarding muy técnico resulte menos intimidante para un usuario no técnico.
El Design Thinking es la intervención adecuada cuando tus soluciones actuales parecen gastadas, o cuando sospechas que se basan en supuestos internos y en la política de la organización más que en pruebas empíricas sobre los usuarios. Además, es un mecanismo excelente para derribar silos departamentales enquistados, o para cuando un equipo está atrapado en el bucle del «lo de siempre» y necesita con urgencia desbloquear una innovación genuina y lateral. Falla, en cambio, cuando el problema es puramente técnico o cuando la solución ya se conoce y el taller solo se usa como una puesta en escena para conseguir apoyos.
Elegir a los participantes y preparar el terreno
La magia de un taller de Design Thinking viene por completo de una colaboración radical entre áreas. Apunta a un grupo reducido de cinco a ocho participantes. Este grupo tiene que incluir sin falta a un «Decisor», la persona con la autoridad y el presupuesto definitivos para dar luz verde al proyecto, para que el resultado no acabe en un cajón. También necesitas a un experto en el cliente, como un agente de soporte de primera línea o un investigador UX dedicado, que hable con el usuario final todos los días y conozca su vocabulario real, sin adornos. Completa la sala con «constructores» que entiendan las limitaciones técnicas y financieras, para que las ideas no pierdan el contacto con la realidad, y con un «comodín» de un departamento que no tenga nada que ver, que aporte una mirada fresca y sin sesgos.
No intentes una sesión de Design Thinking sin datos cualitativos en bruto; no se puede empatizar con una hoja de cálculo ni con un gráfico circular. Antes incluso de empezar la sesión, exige que cada participante vea al menos una entrevista grabada con un usuario o lea un lote de tickets de soporte reales. Igual de importante: deja claro de antemano que los participantes tienen que dejar en la puerta sus egos, sus cargos y sus supuestos. Están ahí para descubrir qué es verdad, no para confirmar lo que ya creen que es correcto.
Gestionar el caos: la fase de ejecución
Una sesión típica dura media jornada o una jornada completa y avanza con método por cuatro fases distintas. Empieza con la fase de Empatizar, en la que el equipo se sumerge en los datos de los usuarios para redactar un enunciado del problema claro y centrado en las personas. Si ese enunciado suena a requisito técnico, como «necesitamos una base de datos más rápida», tienes que obligar al equipo a reescribirlo desde la perspectiva del usuario, por ejemplo «el usuario abandona el carrito porque la larga pantalla de carga le genera inquietud por su tarjeta de crédito».
A partir de ahí, el equipo pasa a la fase de Idear, con una lluvia de ideas divergente. Aquí tienes que imponer sin piedad la regla de improvisación del «Sí, y además...» para proteger las ideas frágiles e incipientes de las críticas prematuras. Por último, el equipo tiene que pasar a la fase de Prototipar y Testear, en la que se le obliga a dejar de hablar y empezar a construir prototipos de baja fidelidad con materiales baratos, como papel o wireframes, y a ponerlos a prueba de inmediato frente a la realidad.
Provocar el avance decisivo
A lo largo de la sesión, tienes que mantener la honestidad intelectual del equipo con preguntas afiladas e incómodas. Cuestiona continuamente si de verdad están resolviendo el problema del usuario o solo diseñando una solución que les facilite sus propios procesos internos. Pídeles que identifiquen el supuesto más arriesgado de todos en el que se apoya su idea favorita, o cómo resolverían el problema si tuvieran cero presupuesto y solo una semana para lanzar. Cuando alguien critique con dureza una idea, no le dejes simplemente tumbarla; oblígale a explicar en qué condiciones concretas de mercado esa idea sí funcionaría.
Tienes que estar muy atento a los errores habituales. El más peligroso es saltarse por completo la fase de empatía y lanzarse directamente a idear, lo que una y otra vez lleva a un equipo a resolver de forma brillante el problema equivocado. También tienes que combatir la mentalidad del «Sí, pero...», que es la gran asesina de las primeras ideas. Protege el proceso del «diseño por comité», en el que las ideas audaces se fusionan para tener a todos contentos y el resultado son soluciones descafeinadas y mediocres; en su lugar, da al Decisor la potestad de tomar la decisión final, aunque sea difícil. Por último, evita que el equipo complique demasiado sus prototipos. El objetivo es aprender rápido, no construir a la perfección.
Sacar más partido a la sesión
Hay dos movimientos que profundizan este proceso. Durante la fase de empatía, pide a un miembro del equipo que interprete al usuario tipo en una entrevista simulada, para que el resto practique cómo indagar en sus puntos de dolor antes de hablar con usuarios reales. Durante la ideación, asigna a alguien el papel de abogado del diablo, que ponga a prueba las ideas con casos límite y fallos estructurales antes de empezar a prototipar.
El artefacto que creas en esta sesión no es un objeto valioso que haya que defender; no es más que una hipótesis a la espera de ser probada. La misión al salir de la sala es llevar estos prototipos de baja fidelidad, ponerlos delante de usuarios reales, fallar lo más rápido y barato posible y traer lo aprendido, en bruto, a la siguiente iteración. El trabajo de verdad empieza en el momento en que dejas el ego en la puerta y te pones en la piel de tus usuarios.
