Design thinking paso a paso y dónde suele fallar

El design thinking es una forma de resolver problemas que parte de las personas que los sufren. En la práctica se desarrolla en cinco pasos: comprender a las personas, definir el problema, generar ideas, hacer un prototipo tosco y probarlo con usuarios reales, volviendo atrás cada vez que la prueba enseña algo. Los pasos son sencillos; los equipos se equivocan en lugares previsibles, y este artículo muestra dónde y cómo evitar cada error.

La versión de cinco pasos es la que enseña la d.school de Stanford (empatizar, definir, idear, prototipar, testear). El Double Diamond del Design Council británico, creado en 2003 y difundido públicamente desde 2004, describe el mismo recorrido en cuatro fases: descubrir, definir, desarrollar y entregar. Usa el vocabulario que tu organización ya conozca. Lo que importa es el orden de las preguntas, no los nombres de las diapositivas.

Si estás valorando si el design thinking es siquiera el enfoque adecuado, lee primero design thinking vs lean vs agile vs design sprint. Para el mapa completo de herramientas, consulta ¿qué herramienta de innovación usar?.

Antes de empezar: plantear el reto

El design thinking fracasa sobre todo antes del primer paso. Hay que dejar resueltas tres cosas antes de la primera entrevista.

1. Un patrocinador que sea dueño de la decisión. Nombra a la persona que actuará con el resultado. Si nadie puede dar el sí al desenlace, el proyecto acaba en un informe.
2. Un encargo que nombre un ámbito problemático, no una solución. «Mejorar cómo supera el personal nuevo su primer mes» es un encargo. «Crear una app de onboarding» es una solución disfrazada que cierra el proyecto antes de abrirlo.
3. Un equipo núcleo pequeño y diverso, con tiempo protegido. Entre cuatro y seis personas, incluida alguien que presta el servicio a diario. Media jornada a la semana durante seis semanas rinde más que un heroico retiro de tres días al que nadie da seguimiento.

Paso 1: Comprender a las personas (empatizar)

Qué se hace. Ir a las personas que conviven con el problema. Hacer entrevistas a partes interesadas con entre ocho y doce personas que cubran todo el abanico de usuarios, no solo los más amables. Sumar observación contextual: ver cómo se realiza la tarea allí donde ocurre.

Qué sale. Notas con las palabras de la propia gente, fotos del entorno real y un primer mapa de empatía para cada tipo principal de usuario.

Dónde falla.

• El equipo entrevista a compañeros o a mandos sobre los usuarios en lugar de a los propios usuarios.
• Las preguntas piden a la gente que prediga su comportamiento futuro («¿Usarías…?»), algo que se nos da mal.
• La investigación se externaliza y el equipo lee un resumen en lugar de escuchar directamente a las personas. El cambio de mentalidad ocurre en la sala, no en el informe.

Solución. Preguntar por la última vez que pasó algo («Cuéntame la última vez que…») y asegurarse de que cada miembro del equipo núcleo asiste al menos a dos entrevistas. Más en 5 errores de investigación que echan a perder tus entrevistas.

Paso 2: Definir el problema

Qué se hace. Desplegar los hallazgos y agruparlos con un diagrama de afinidad. Buscar tensiones y sorpresas, no solo las quejas frecuentes. Redactar un enunciado de punto de vista: un usuario concreto, una necesidad y una idea clave sobre por qué importa. Convertirlo en dos o tres preguntas ¿Cómo podríamos?.

Qué sale. Un enunciado del problema consensuado y un breve conjunto de preguntas «¿Cómo podríamos?», validados por el patrocinador.

Dónde falla.

• El equipo se salta este paso porque «ya conocemos el problema». Normalmente conoce el síntoma.
• El enunciado es tan amplio («¿Cómo podríamos mejorar la experiencia del cliente?») que cualquier idea encaja, o tan estrecho («¿Cómo podríamos añadir un chatbot?») que cuela la respuesta.
• Al patrocinador no se le enseña el enunciado y más tarde rechaza ideas porque tenía otro problema en la cabeza.

Solución. Tratar la validación del enunciado del problema como una puerta que hay que cruzar. La guía completa está en tu enunciado del problema es todo el proyecto.

Paso 3: Generar ideas (idear)

Qué se hace. Empezar en silencio. Usar brainwriting o Crazy 8s para que cada persona genere ideas por su cuenta antes de que el grupo debata. Primero, cantidad. Después, agrupar, construir sobre las ideas de los demás y acotar con una matriz impacto-esfuerzo o una herramienta similar.

Qué sale. Dos o tres ideas que merezca la pena prototipar, cada una vinculada a la pregunta «¿Cómo podríamos?» a la que responde.

Dónde falla.

• Debate abierto desde el primer minuto, de modo que la persona de más rango o la que más alto habla marca el rumbo.
• El equipo se enamora de una idea y deja de generar.
• Las ideas se eligen a mano alzada, sin preguntarse cuáles responden mejor al enunciado del problema.

Solución. Separar generar de juzgar, en el tiempo y en las reglas. Para los argumentos contra la lluvia de ideas abierta y qué usar en su lugar, consulta el brainstorming no funciona: esto sí.

Paso 4: Prototipar

Qué se hace. Hacer lo más barato posible que permita a una persona real reaccionar ante la idea. Un prototipo en papel de una pantalla o un formulario, un storyboard de un servicio, una carta simulada, una conversación de mostrador escenificada. Antes de construir, enumerar los supuestos más arriesgados con un mapa de supuestos y asegurarse de que el prototipo los pone a prueba.

Qué sale. Un prototipo tosco por idea, más una nota escrita de lo que se espera aprender con él.

Dónde falla.

• El prototipo está demasiado pulido. La gente es educada con lo que parece terminado y deja de dar opiniones sinceras, y al equipo le cuesta tirar un trabajo que le ha llevado semanas.
• El prototipo prueba la parte fácil (el aspecto de la pantalla) en lugar de la arriesgada (si alguien traería los documentos correctos).
• Se encarga a sistemas o a un proveedor que construya un piloto, y el proyecto se convierte sin hacer ruido en una implantación.

Solución. Fijar un límite de uno o dos días por prototipo. Si lleva más, es demasiado detallado.

Paso 5: Probar y volver atrás

Qué se hace. Poner el prototipo delante de unos cinco usuarios reales. Hacer una prueba de usabilidad moderada: darles una tarea, observar y callar. Recoger los resultados en una matriz de captura de retroalimentación: qué funcionó, qué no, qué preguntas surgieron y qué ideas nuevas aparecieron.

Qué sale. Una decisión clara para cada idea: afinarla, descartarla o llevarla a un piloto. A menudo también se descubre que el problema estaba algo mal planteado, lo que obliga a volver al paso 2.

Dónde falla.

• El equipo explica el prototipo antes de la prueba y luego mide lo bien que la gente entendió la explicación.
• La prueba se trata como un examen final que hay que aprobar, así que los resultados negativos se justifican.
• Tras la prueba no hay ningún camino hacia la ejecución y el prototipo acaba en un cajón.

Solución. Acordar de antemano qué resultado haría descartar la idea. Y antes de probar, acordar con el patrocinador quién llevará una idea exitosa a la ejecución y con qué partida presupuestaria.

Un ejemplo práctico

Ilustrativo. La biblioteca de una universidad de una gran ciudad quiere que más estudiantes usen su servicio de apoyo a la investigación. El uso es bajo, y la jefa de servicios bibliotecarios da por hecho que el problema es de notoriedad.

Comprender. El equipo, de cinco personas, entrevista a diez estudiantes y observa el mostrador de ayuda durante tres tardes. Los estudiantes saben que el servicio existe. Lo que les frena es que para reservar tienen que describir su tema de investigación en un formulario, y muchos sienten que su tema todavía no es «lo bastante bueno» para enseñárselo a un bibliotecario.

Definir. El punto de vista queda así: «Los estudiantes de primer año de posgrado necesitan una forma poco comprometida de pedir ayuda pronto, porque se sienten juzgados cuando su idea de investigación aún no está clara». La pregunta «¿Cómo podríamos?»: «¿Cómo podríamos hacer que pedir ayuda resulte normal antes de que el tema esté claro?».

Idear. Una ronda de brainwriting produce cuarenta ideas. La matriz impacto-esfuerzo deja tres: horas de consulta sin cita para «temas aún sin definir», un formulario de reserva con un único campo opcional y visitas de bibliotecarios al primer seminario de cada programa.

Prototipar. Un cartel impreso para las horas sin cita y una versión en papel del formulario abreviado, ambos hechos en una mañana.

Probar. En dos semanas, las horas sin cita atraen un flujo constante de estudiantes, mientras que el formulario abreviado apenas cambia nada. El equipo descarta el formulario, mantiene las horas sin cita para un piloto de un trimestre y acuerda con la jefa de servicios bibliotecarios qué horas de personal lo cubrirán.

El supuesto inicial, que los estudiantes no conocían el servicio, habría dado lugar a una campaña de carteles. El proceso dio una respuesta distinta.

Qué hacer y qué evitar

Qué hacer

• Conseguir un patrocinador con nombre y un encargo sin solución antes del primer paso.
• Hacer que el equipo núcleo escuche directamente a los usuarios.
• Validar el enunciado del problema antes de idear.
• Prototipar en horas, no en semanas.
• Planificar el camino hacia la ejecución antes de probar.

Qué evitar

• Tratar el design thinking como un taller. Un solo día puede cubrir la ideación; el proceso completo lleva semanas.
• Saltarse la definición para ganar tiempo. Luego cuesta más tiempo.
• Pulir los prototipos o explicarlos antes de probarlos.
• Aplicar el proceso para justificar una decisión ya tomada. La gente lo nota y la pierdes para el siguiente proyecto.
• Pensar en los pasos como algo estrictamente lineal. Volver atrás es el método funcionando.

Preguntas frecuentes

¿Cuáles son las 5 fases del design thinking? En el modelo de la d.school de Stanford: empatizar, definir, idear, prototipar y testear. El Double Diamond del Design Council agrupa el mismo trabajo en cuatro fases: descubrir, definir, desarrollar y entregar.

¿Cuánto dura un proyecto de design thinking? Para un problema de servicio acotado, cabe esperar entre cuatro y diez semanas de trabajo a tiempo parcial de un equipo núcleo pequeño. Un design sprint puede condensar los últimos pasos en cinco días, pero solo cuando el problema ya se entiende razonablemente bien.

¿Por qué falla el design thinking en las organizaciones? Normalmente por motivos organizativos, no de método: no hay un patrocinador dueño del resultado, el encargo ya contiene la solución, la investigación se omite o se externaliza y no existe un camino desde el prototipo probado hasta la ejecución.

Por dónde seguir

Las guías de método para cada paso: entrevistas a partes interesadas para el paso 1, enunciado de punto de vista y preguntas ¿Cómo podríamos? para el paso 2, brainwriting para el paso 3 y prototipo en papel para los pasos 4 y 5. Para profundizar en las pruebas, lee cómo probar una idea antes de construirla.