up arrow

Guía definitiva de Design Thinking Aumentado

Post escrito por Juan Sobejano

Decía uno de los padres del racionalismo moderno, René Descartes, que “para investigar la verdad es preciso dudar, en cuanto sea posible, de todas las cosas”. Hay en el mundo empresarial demasiadas certezas, y no sólo porque, equivocadamente, muchos se crean en posesión de la verdad, sino porque toda la estrategia de la organización, todo el plan de acción gira en torno a una serie de certezas que son la base de la toma de decisiones. Y esto es un error

Ya no hay certezas, ya no hay principios inamovibles que permanecen eternos en las organizaciones y que son su ADN empresarial. Que se lo pregunten a Kodak, a Nokia, a Blockbuster. Pregúntaselo a la tienda de la esquina, la de toda la vida, la que cerró el mes pasado. Pregúntatelo a ti.

En un entorno en constante cambio, con la duda eterna y metodológica como uno de los fundamentos de nuestros desarrollo estratégico y gestión, el Design Thinking (DT) aparece como una metodología muy interesante sobre la que construir no ya nuestro futuro, sino nuestra existencia como empresa.

Qué es Design Thinking (y qué no)

    Pero empecemos por el principio, es decir, definiendo qué es DT. Simplificando el DT es una metodología creada para descubrir problemas y construir soluciones centradas en las personas. En esta definición, como decimos algo simple, hay algunos elementos importantes:

    1.-Se trata de descubrir problemas. Como veremos ahora, el DT es una metodología fundamentalmente de innovación y para las organizaciones. Pero para ello es necesario que comprendamos qué problemas son los que afectan a las personas. Como decimos también, qué dolor tienen.

    2.-Queremos construir soluciones. No es una metodología que se queda a medias detectando los problemas, sino que también construye y propone soluciones para resolver esos problemas.

    3.-Se centra en las personas. Y esta es una de las claves del DT: no sólo porque todo el proceso gira en torno al conocimiento y el beneficio de las personas, sino porque, como ya se habrá dado cuenta, hablamos de personas, no de clientes. No resolvemos problemas de clientes, resolvemos problemas de personas para que sean clientes. Queremos ser relevantes para ellos, si me apura, queremos ser necesarios para ellos.

    Se puede decir que el DT nació de entornos de ingeniería industrial y diseño, uniendo la búsqueda de funcionalidades y la creatividad. Por ejemplo, en 1962 se realizó una conferencia pionera llamada «The Conference on Systematic and Intuitive Methods in Engineering, Industrial Design, Architecture and Communications» que fue clave para el desarrollo del estudio sistemático del diseño como proceso, integrando la ingeniería industrial y el diseño como campos complementarios. Por otra parte, en ingeniería se desarrollaban metodologías para resolver problemas creativos y estructurados, como el Creative Problem Solving iniciado por Alex Osborn en los años 50. Estas metodologías de pensamiento estructurado para resolver problemas complejos fueron la base para el componente «Thinking» de Design Thinking.

    Posteriormente la evolución de este tipo de metodologías cristalizó en el DT cuando los profesores de ingeniería de Stanford Bernie Roth y David Kelley (fundador de la consultora IDEO) unieron el diseño centrado en el usuario con el pensamiento sistemático de ingeniería.

    Dicho esto, es importante, antes de analizar los distintos pasos que componen el DT, señalar cuáles son los principios clave:

    1.-Como ya hemos comentado, se centra en las personas o en el usuario. Se diseña desde las necesidades, emociones y comportamientos reales de las personas. Esto nos obliga a observar y entrevistar a los usuarios en su contexto, utilizando herramientas heredadas de la antropología y la sociología, y no quedarse en suposiciones y encuestas online.

    2.-Es co-creativo y multidisciplinar. La diversidad es un valor importante, y se enfocan los problemas desde una perspectiva holística, utilizando diversos puntos de vista y entendiendo y trabajando sobre la “experiencia completa” del usuario, no sólo sobre su condición de cliente.

    3.-Es iterativo y experimental. La utilización de prototipos en el proceso permite aprender, corregir y reintentar las soluciones que proponemos. Mejor “construir para pensar” que “pensar para construir”

    4.-Crea modelos y busca patrones. Se trata de encontrar aquello que se repite, tratando de encontrar patrones y repeticiones estadísticas. Como decimos en Innolandia: Una vez es un hecho, dos veces es una casualidad, tres veces es un patrón. Estos patrones o modelos son, por supuesto, indicios más que hechos consolidados, pero ya nos marcan el camino por el que continuar. Lo que nos lleva a…

    5.-La intuición es un arma fundamental. No todo es lógica y medición exhaustiva. Es importante detectar los indicios, las señales, esos patrones en estado larvario y, a partir de ahí, avanzar para confirmar, o no, lo que sospechamos.

    6.-El fallo no es un fracaso. Porque este tipo de metodologías considera el fallo como conocimiento. Hemos encontrado una forma en que no se hacen las cosas, en que el proyecto no funciona. Aprendemos y corregimos. No hay problema.

    Qué no es Design Thinking

    Vale, pero estos principios pueden trasladarse a otras metodologías, y es cierto que en ocasiones hay confusiones y mezclas metodológicas que llevan al DT a confundirse con modos de desarrollo estratégico, de gestión o de innovación que nada tienen que ver. Por eso es bueno analizar, aunque sea brevemente, qué no es DT.

    DT no es un “taller de post-its” desconectado de la realidad ni un sustituto de la estrategia. Tampoco es solo creatividad: sin investigación de usuarios y sin pruebas con evidencias, el resultado es humo. No es una reunión de amigos que improvisan un prototipo para pasar el rato. Todo lo que se hace en el proceso del DT tiene un sentido y un significado.  

    Hay metodologías que en ocasiones se confunden con DT o, al menos, tiene difuso los límites. Por ejemplo, la mejora continua (Kaizen) optimiza el proceso actual: elimina desperdicios, estandariza, afina. El DT, en cambio, invita a repensar desde cero la experiencia ideal del usuario y luego aterrizarla con restricciones reales. En Innolandia utilizamos el concepto “sunny day”: dibujar el flujo perfecto “en un día soleado” y, después, añadir capas de realidad (tecnología, normativa, organización) para construir un MVP viable. Esta lógica es especialmente útil cuando el proceso vigente está lleno de inercias y parches que impiden mejoras significativas.

    En este caso ambos enfoques se complementan: puedes abrir con Design Thinking para definir la experiencia objetivo y el prototipo funcional, y luego aplicar Lean/Kaizen para estabilizar y escalar la solución en la operación diaria. El error sería pretender transformar un servicio roto a base de micro-mejoras sin cuestionar el diseño de fondo.

    El proceso que usa Innolandia (modelo Stanford)

    Como hemos dicho antes, el DT en una metodología, pero como metodología requiere de uno proceso, de una serie de pasos ordenados que hay que dar para conseguir el resultado deseado. Hay varios enfoques del DT con distintos pasos, IDEO, por ejemplo, utiliza un modelo de 3 pasos: explorar, idear y empatizar. Nosotros, en Innolandia utilizamos el modelo de Stanford (de su d.school) compuesto de 5 fases: empatizar, definir, idear, prototipar y testar.

    Vamos a comentarlas brevemente:

    • Empatizar: En esta fase perfilamos arquetipos para conocer a nuestros usuarios, mapeamos comportamientos y, sobre todo, observamos y entrevistamos en el contexto real para captar necesidades y fricciones. 
    • DefinirAquí convertimos datos dispersos en un foco claro (insights, Point of View y preguntas “How Might We…?”) de modo que enmarque el reto de diseño sin prescribir la solución. 
    • Idear: En la fase de ideación generamos muchas opciones (divergencia), las agrupamos y seleccionamos con criterios, para finalmente “aterrizar” ideas para poder construir algo que se pueda probar. 
    • Prototipar: Con el prototipo construimos representaciones rápidas y baratas (storyboards, maquetas, role play) para poder aprender de los usuarios, no para “validar” una perfección inexistente. 
    • Testar: En esta última fase mostramos el prototipo a los usuarios para poder recoger feedback estructurado, detectar patrones y decidir si iterar, pivotar o avanzar. Integrar el test en el día a día es clave para acelerar. 

    Al final, si se analiza, estamos hablando de las mismas fases que utiliza IDEO: explorar, idear e implementar:

    Una última reflexión dentro de este apartado:

    ¿Por qué funciona?

    Sobre todo, porque reduce la incertidumbre donde los excels no llegan: estamos hablando de analizar comportamientosreales. Las entrevistas contextuales y la observación revelan trabajos por hacer, miedos y atajos que rara vez aparecen en un informe de escritorio. Cuando se conectan esos hallazgos con ideas tangibles y tests rápidos, los equipos toman decisiones con más señales y opiniones más formadas. 

    Además, Design Thinking no se limita a “crear cosas nuevas”; es útil para rediseñar servicios y operaciones. En procesos internos, empezar por el “sunny day” abre posibilidades que los enfoques incrementalistas (aquellos que se centran en la mejora de lo que ya hay) pasarían por alto; luego, con iteraciones y prototipos, se comprueba qué parte de esa visión puede implantarse con impacto real en tiempo y coste.

    Al final es una metodología que ofrece nuevos enfoques, se centra en la innovación, reduce la incertidumbre y a un bajo coste.

    Mentalidad y reglas del juego

    Cuando hablamos del DT estamos hablando, más que de un conjunto de técnicas, de una actitud frente a la incertidumbre. Los modelos tradicionales de diseño de la innovación o de creación de productos y servicios también parece que quieren evitar esta incertidumbre, pero se sumergen en estudios, números, estadísticas… es decir, lo de siempre. Sin embargo, tardan en salir al mundo real, tardan en enfrentarse directamente a esa incertidumbre que ven como una enemiga, mientras que el DT la ve más como una oportunidad.

    Una de las claves del DT es el uso de prototipos. Los prototipos, como luego veremos, nos ayudan a pensar desde lo tangible, es decir, a reducir la incertidumbre. La tangibilidad del prototipo permite al grupo de trabajo visualizar mejor los problemas, lo que funciona y lo que no, enfocar las visiones de cada uno y mejorar en la coordinación de ideas. 

    Del mismo modo que el prototipo nos ayuda a trabajar desde lo que se puede tocar, el DT privilegia el trabajo de campo “fuera de la oficina” sobre los estudios y análisis eternos de otros métodos. No es que no se utilicen las búsquedas de información online, por ejemplo, sino que no tienen un peso demasiado grande en el proceso. Del mismo modo el DT huye de los focus groups o encuestas, o al menos trata de minimizarlas. El motivo es simple: la gente dice una cosa y hace otra; los focus groups y las encuestas capturan opiniones, mientras que la observación revela fricciones y atajos reales. Buscamos comportamientos representativos, no significancia estadística.

    Con este tipo de análisis, más dinámico, más pegado a la realidad, menos dependiente de la cantidad de datos, realizamos un proceso de iteración en espiral. En Innolandia decimos que es como una caracola: avances acumulativos en vez de dar vueltas en el “círculo del prototipo infinito” (prototipo-test-prototipo sin decisiones). La espiral te obliga a concretar: o sigues iterando con mejoras claras, o abandonas/pivotas, o das el salto a propuesta de valor/MVP.

    Algunas píldoras de recordatorio antes de seguir:

    a.-Es importante que antes de cada experimento, prueba, observación o prototipo tengas claro el objetivo de aprendizaje: qué preguntas quieres responder con el siguiente prototipo, test o experimento. 

    b.-Ten muy claro cuáles son las hipótesis explícitas sobre usuario y problema (arquetipo, momentos de la verdad) que vas a contrastar (o esperas encontrar) en campo. Esto te va a indicar si estás avanzando o no

    c.-Cuando crees un prototipo piensa en crear lo-básico-que-sirva para provocar reacciones; recuerda: herramienta para aprender, no mini-producto. 

    d.-Ten en cuenta que el usuario es el actor más importante: has de tener un plan para enseñar y recoger feedback (matriz de feedback: positivo/negativo/dudas/ideas). 

    e.- Recuerda tener la espiral decidida: define de antemano el criterio para iterar / pivotar / avanzar después del test. 

    f.- Siempre, siempre ten en cuenta el antídoto anti-ego: recordar al equipo “no te enamores del prototipo” (o de tus ideas).

    Fase 1 – Empatizar

    Empecemos a trabajar. Para ello, como te decíamos antes, la primera fase en la de empatía. Empatizar es meterse en la piel del usuario, pensar como él piensa, tomar las decisiones que él tomaría. No hablamos solo de “saber quién es”, sino de ver lo que ve, oír lo que oye y, sobre todo, sentir lo que siente en el contexto real de uso o compra. No estamos hablando de un conocimiento numérico, sino que hablamos de un análisis de comportamiento (y de sentimientos) con un enfoque caramente etnográfico. A partir de la información que podamos conseguir en esta fase podremos marcar el camino que vamos a seguir a la hora de diseñar el producto o servicio.

    En Innolandia solemos dividir esta fase en 5 pasos prácticos, con sus lógicas variaciones y cambios dependiendo del tipo de proyecto, por supuesto (entre esas variaciones y cambios está el orden de ejecución):

    A.-El DT empieza con la empatía, como estamos diciendo, y por eso es importante que pongamos al usuario en el centro de la reflexión. No pensamos en él, en esta fase, como cliente, sino como usuario, como persona con una serie de necesidades que hemos de satisfacer. Por ello, solemos empezar en Innolandia utilizando la herramienta del Buyer Persona. El Buyer Persona es la definición de un arquetipo del tipo de usuario al que nos dirigimos. No es “la media del mercado”, sino la representación de una persona que encarna a un colectivo. Utilizamos para ello una ficha como esta:

    Existen más fichas para trabajar el Buyer Persona, sólo has de buscarlas en Google y elegir la que más te guste. Pero ten en cuenta una cosa: Esta ficha no es verdad revelada: es una apuesta inicial para salir al campo y refinarla con evidencias.

    Por cierto: si buscas oportunidades en clientes actuales, tu histórico te ayuda a completar la ficha; si exploras nuevos clientes, empatizar es todavía más crítico y la ficha será más hipotética al principio. Evita “plantillismo” vacío: el valor no está en la estética de la ficha, sino en que te sirve de guía para observar, entrevistar y decidir qué validar primero.

    B.-Puedes quedarte con el Buyer Persona o lo puedes completar con el Mapa de Empatía. Aquí tratamos de analizar al usuario desde una perspectiva 360, poniéndolo en su contexto y, sobre todo, teniendo muy en cuenta la parte emocional.

    Del análisis del Mapa de Empatía emergen pains (frustraciones/dolores) y gains (aspiraciones/beneficios) que luego usarás para enfocar el problema y, más tarde, para evaluar ideas y prototipos. Consejo de Innolandia: no te dejes llevar por “yo creo que…”; cada punto debe partir de datos de campo, no de tus suposiciones.

    Otra opción que, a nosotros, en Innolandia, nos gusta más, es trabajar con el lienzo de la propuesta de valor. En esta fase nos centramos en el círculo del gráfico inferior, con el que analizamos al segmento de usuarios, del que ya hemos hecho el buyer persona, y así analizamos qué cosas, trabajos o necesidades tiene, qué considera que sería una ganancia o un resultado positivo y qué una pérdida, dolor o resultado negativo.

    El resultado ha de ser un círculo repleto de trabajos (ya sean funcionales, sociales o emocionales), de dolores (obstáculos o riesgos) y de resultados o beneficios deseados, que nos van a guiar en construir una propuesta de valor (una solución) consistente y deseable por el usuario.

    C.-No podemos olvidar, como ya hemos comentado antes, el trabajo de campo. Como también dijimos, la gente no siempre dice lo que hace (ni hace lo que dice), o como también nos gusta decir: la gente miente cuando habla, pero no cuando actúa. Por eso es tan importante acercare al usuario, al potencial cliente, para observarle, sumergirse en su entorno y ver razones, motivos y causas de sus actos. 

    Hay tres técnicas que nos resultan interesantes en Innolandia:

    .-Shadowing / Observación: sigue al usuario en un momento de la verdad (informarse, elegir, usar) y documenta sin molestar. Verás fricciones y atajos que nadie te contaría (p. ej., por qué pasan poco tiempo ante un lineal refrigerado). Pide permiso si haces fotos. 

    .-“Un día en la vida”: trabaja codo a codo con el usuario (muy útil en B2B) durante 1–2 días. Descubrirás condicionantes del entorno (interrupciones, cargas, prioridades) que explican por qué una solución aparentemente “obvia” no encaja. 

    .-Entrevistas en contexto: café o conversación en el lugar de búsqueda, compra o uso. No es un interrogatorio: pregunta mucho “¿por qué?” para llegar a causas y no quedarte en hechos. Evita focus groups de laboratorio; aquí mandan los detalles situados.

    Unos consejos para organizar el trabajo de campo: planifica qué quieres aprender, a cuántas personas observar (busca extremos: novatos y expertos), en qué entorno y con qué técnica. Durante la ejecución, limita notas en caliente y sintetiza al final. Y, sobre todo, recuerda: buscas comportamientos representativos, no significancia estadística.

    Tras cada entrevista u observación, en Innolandia te proponemos cerrar con tres listas rápidas para evitar sesgos y capturar lo esencial:

    • 3 cosas que has aprendido que no sabías.
    • 3 cosas que has confirmado (hipótesis que se mantienen).
    • 3 cosas que te han sorprendido (frases repetidas, gestos, micro-acciones). 

    Ejemplo (ficticio, alta de servicio B2B):

    • Aprendido: (1) La “falta de tiempo” pesa más que el precio; (2) El usuario usa WhatsApp para coordinar tareas críticas; (3) La validación por email se pierde por filtros.
    • Confirmado: (1) El decisor no es el usuario; (2) El pico de trabajo es los lunes; (3) La implantación se hace “a ratos”.
    • Sorprendido: (1) El 80% de altas se hace desde móvil en la calle; (2) Nadie lee el tutorial inicial; (3) Dos usuarios imprimen pantallas para “enseñar a otros”.

    Con 5–8 sesiones así, suele aflorar patrón suficiente para enfocar Definir. 

    D.-Todo lo que hemos hecho, incluyendo otras posibles herramientas que podamos haber utilizado, no sirve de nada si no somos capaces de recopilar los datos que hayamos obtenido y analizarlos. Recordemos que estamos en la fase de empatía, por lo que nos interesa conocer al usuario. Por eso puede ser interesante apoyar todo lo aprendido hasta ahora con otros datos que podamos recopilar de fuentes externas (foros, redes, Google Trends…). Ya dijimos que el DT no rechaza este tipo de fuentes, pero sí que son secundarias, de apoyo.

    Al terminar la fase de Empatizar deberías tener:

    1. Un arquetipo actualizado (tu buyer persona revisado con evidencias reales).
    2. Un paquete de insights priorizados, surgidos de observar, conversar y recorrer el journey.

    Ese material alimenta la fase Definir, donde sintetizas causas (no solo hechos) y formulas el Point of View y las preguntas How Might We…? para abrir Ideación con foco.

     Antes de continuar aquí tienes algunas señales que te dirán si lo estás haciendo bien o mal:

    • Bien: tus notas están llenas de comportamientos concretos (“tirita el cursor cuando…”, “abandona el carrito cuando…”), frases literales repetidas, patrones que empiezan a emerger en 5–8 usuarios. Has mapeado pains/gains que explican momentos de fricción del journey. 
    • Mal: te quedas en “lo que ya sabías”, hiciste poca exploración o solo entrevistas y encuestas; te centras en hechos sueltos y no en porqués; sales con opiniones “bonitas” pero sin insights o aprendizajes. Antídoto de Innolandia: diversifica técnicas, dedica tiempo suficiente a campo y clasifica aprendizajes en Jobs/Pains/Gains. 

    Cuidado con el sesgo de confirmación: no selecciones usuarios que te vayan a dar la razón. Y recuerda que, para tomar primeras decisiones con prototipos tempranos, suele bastar con detectar patrones en torno a cinco personas (si 4 de 5 apuntan a lo mismo, hay señal).

    Para terminar esta fase, Empatizar no es un ritual de post-its: es salir, mirar, escuchar y sentir con método. Si inviertes bien aquí, todo lo demás se abarata y acelera: tendrás un arquetipo validado, un journey con puntos calientes bien localizados y insights que den dirección al resto del proceso. Como decimos en Innolandia, sin trabajo de campo el Design Thinking pierde gran parte de su potencial. Que no te pase.

    Fase 2 – Definir

    Puesto que ya hemos empatizado, ya conocemos a nuestro potencial cliente y tenemos suficiente información como para encontrar indicios de patrones, es hora de que demos forma al problema. Innovar, crear un producto o servicio, un nuevo proceso o un modelo de negocio único se hace siempre para lo mismo: resolver problemas de los clientes de la manera más eficaz y sostenible. Por eso es tan importante que toda la información recopilada se convierta en conocimiento y nos lleve a definir el problema que de verdad quita el sueño al usuario.

    Hay muchas técnicas para procesar esa información y sacarle partido. Lo primero que hacemos en Innolandia es convertir todas esas notas, fotos y frases de usuarios en insights que expliquen por qué pasan las cosas (no solo quépasa). Una herramienta que nos gusta mucho es el mural del cliente, que desarrollamos con dos movimientos: saturar y agrupar por nubes. Primero “empapelas” la sala con todo lo recogido en campo (post-its con citas literales, fotos, recortes…). Después, agrupas por temas emergentes (las “nubes”), poniéndoles un título que suele ser un pain o un gain. No buscamos significancia estadística; esto es investigación etnográfica centrada en comportamiento real. Cuando es necesario se da una vuelta extra: ordenar las nubes siguiendo el customer journey y mapear interrelaciones para llegar a causas.

    Hay un peligro en esta fase que hemos de sortear, quedarnos en el dato sin llegar al porqué. Si decimos “tardan 7 minutos en…”, lo que me importa no es que tarden 7 minutos, sino el porqué de esa tardanza (¿miedo a equivocarse? ¿falta de confianza? ¿mala visualización del producto?). Es importante recuperar aquí lo trabajado en el Canvas de la propuesta de valor y clasificar los aprendizajes en Jobs to be Done (trabajos), pains (barreras) y gains (aspiraciones) y tener así clara la relación causa-efecto entre los datos y su significado.

    Recordemos que queremos profundizar y consolidar el conocimiento a partir de los datos recogidos en la fase de empatizar para terminar definiendo el problema sobre el que vamos a trabajar.

    Para sintetizar toda la información y llegar a una definición manejable del problema podemos utilizar estas herramientas:

    1) Point of View (PoV)

    El PoV resume el problema en una frase con esta estructura: Usuario + Necesidad + Insight.

    • Describe a la persona (arquetipo).
    • Enuncia la necesidad con un verbo (lo que intenta lograr / evitar).
    • Explica el insight (la causa oculta que explica su comportamiento).

    El PoV es el embudo donde destilas “las nubes”. Es breve, accionable y, si está bien escrito, orienta decisiones de diseño sin encerrar la solución.

    2) How Might We (HMW)

    Del PoV pasas al HMW: transformar el problema en preguntas abiertas que activen la creatividad (ni tan amplias que se diluyan, ni tan estrechas que la bloqueen). El HMW fija el foco creativo de la siguiente fase y puedes redactarlo iterativamente hasta que “enganche” al equipo y a los usuarios. 

    3) Customer Journey

    Hay una herramienta que nos gusta mucho y que solemos utilizar en esta fase de empatizar, el Customer Journey. El Customer Journey es una línea temporal de actividades, puntos de contacto y emociones desde que surge la necesidad antes, durante y después del uso. Puedes analizar desde el proceso de compra hasta un día en la vida del usuario y potencia cliente.

    Lo interesante del Customer Journey es que te da una visión holística de la experiencia del usuario y te muestra picos y valles emocionales, momentos críticos y oportunidades de mejora. Es muy aconsejable hacerla en grupo, ya que las conversaciones y reflexiones que se generan son realmente valiosas y ofrecen mucha información útil.

    4) Jobs to be Done (JTBD)

    Puedes terminar con los Jobs to be Done (JTBD). Los Jobs explican qué intenta realmente resolver la persona cuando “contrata” una solución, y pueden ser:

    • Funcionales (tareas/acciones concretas),
    • Sociales (impacto ante otros) y
    • Emocionales (cómo quiere sentirse).

    Al clasificar tus hallazgos en Jobs–Pains–Gains, como hemos dicho antes, pones causalidad al centro: pains/gains son efectos alrededor de un trabajo principal. Esta lente evita soluciones cosméticas y te ayuda a priorizar problemas con potencial.

    A continuación, te vamos a mostrar un ejemplo de secuencia de acciones en esta fase:

    Proceso práctico: de datos a insight

    1. Satura el mural con todo lo recogido (citas en un post-it por idea; fotos; recortes). Sin orden ni filtro inicial: aquí prima cantidad y diversidad. 
    2. Agrupa en nubes por temas emergentes. Pon títulos que suenen a pain/gain (no a solución). Defiende el enfoque: no es estadística, es evidencia etnográfica. 
    3. Ordena por journey y busca relaciones (si hace falta): así emergerán causas (“llega tarde a… → evita registrarse… → miedo a perder el pedido”). 
    4. Destila en PoV (1–3 frases como máximo). Luego genera varias HMW derivadas y prueba su poder de atracción con el equipo/usuarios. 
    5. Enmarca con JTBD: verifica que tu PoV ataca un trabajo importante y prioriza. Si no hay “trabajo” de peso, mejor cambia de foco ahora.

    Hay una serie de “señales” que te indicarán que estás desarrollando adecuadamente la fase de Definir:

    • Tu PoV “late”: cualquier miembro del equipo lo lee y entiende a quién, qué necesita y por qué; nadie propone soluciones en la frase. 
    • Tus HMW atraen: cuando los lees, la gente quiere proponer ideas; si suenan a objetivo corporativo (“reducir costes”), revisa para centrarte en el usuario. 
    • Tus nubes conectan: ves causas (Jobs) que explican pains/gains, no listas de síntomas.

    Piensa que esta fase es crítica, ya que un problema mal formulado conduce a soluciones no deseadas o que nadie necesita. “Definir” es un embudo: de lo disperso a lo esencial; del qué observable al porqué que mueve la conducta; de “datos” a decisiones de diseño. Desarrollar adecuadamente esta fase crea una “plataforma de despegue” potente para la siguiente, la de ideación, de este modo Idear arranca con un foco creativo potente, Prototipar sabe qué aprendizaje buscar y Testar puede evaluar con criterios.

    Fase 3 – Idear

    Esta es una fase trampa, porque en realidad estamos ideando durante todo el proceso. Desde el principio se nos están ocurriendo posibles soluciones, y esto es muy peligroso, porque puede hacer que todo nuestro proceso reflexivo esté condicionado por esas ideas u ocurrencias nacidas en la fase de Empatizar o de Definir. Hemos de ser capaces de dirigir y concentrar todas nuestras actividades de ideación a esta fase, porque es ahora cuando disponemos de información consistente y podemos generar ideas con una mayor solidez.

    Ahora bien, Idear no va de “tener un momento eureka” en una sala llena de post-its. Va de preparar el cerebro y al equipo para que emerja mucho (cantidad), diferente (divergencia) y relevante (alineado al foco del usuario). Hay que desmontan el mito del brainstorming como origen mágico de las ideas: las buenas conexiones aparecen tras una incubación previa y una atención selectiva activada por un foco claro. De ahí las “3 Bs” de Steven Johnson —bath, bed, bus—: el cerebro ensambla piezas en momentos cotidianos, si antes le hemos dado foco creativo formulado como HMW (How might we…?).

    Es necesario desmontar, por tanto, una serie de mitos en cuanto a esta fase de Ideación:

    Mito 1: “Las ideas nacen en el brainstorming.” En realidad, la sesión sirve para sacar lo que ya estaba cociéndose. Ya dijimos antes que muchas de las mejores ideas nacen implícitamente en fases anteriores, pero hemos de esperar a esta fase para hacerlas explícitas. Por eso es bueno definir el HMW al cerrar Definir y dejar 1–2 semanas para que el cerebro filtre señales y vaya conectando puntos. Durante ese tiempo, el equipo comparte inputs inspiradores (tecnologías, casos de otros sectores) en un canal común. 

    Mito 2: “Cuanto más largo el taller, mejor.” Mejor varios impulsos breves y descanso que una maratón sin energía creativa. La creatividad no se puede “a tope” durante mucho tiempo. Su hype puede durar media hora o 1 hora como mucho. Es importante el trabajo previo y posterior a la sesión para sacarle el máximo partido.

    En Innolandia hemos estructurado la sesión de ideación en 4 bloques:

    1) Rompehielos (5–10′).
    Pueden ser juegos aleatorios, mindfulness ligero o yoga para centrar la atención y bajar la autocensura. Luego, divide al grupo en sub-equipos pequeños para fluir más rápido. 

    2) Divergencia (10–20′ por ronda).
    “Vomitar ideas”: primero busca volumen, cantidad, luego calidad. Marca un objetivo explícito (p. ej., “300 ideas en 10 minutos”) para romper frenos del tipo “esto aquí no va a funcionar”. Puedes combinar técnicas en rondas: brainwriting(cada persona escribe, pasa la hoja y el otro construye), brainstorming clásico, analogías forzadas, etc. La clave de esta ronda es la cantidad. 

    3) Agrupación (10–15′).
    Pega todas las ideas en una pared y agrúpalas (complementarias, similares, opuestas) para formar conceptos. En esta fase aparece la primera convergencia suave. 

    4) Moldes creativos (15–30′).
    Vuelve a divergir aplicando 4–5 “moldes” para retorcer los conceptos (eliminar, exagerar, invertir, combinar, sustituir, trasladar a otro contexto, etc.). Se trata de trabajar con las ideas potencialmente más interesantes y darles una vuelta, pero con método. Puedes hacer esta parte en otra sesión para evitar fatiga.

    Puede ocurrir que las ideas surgidas o elegidas sean o muy “normalitas” o muy locas. En esos casos en Innolandia podemos trabajar con 4 “cubos”, donde elegimos al menos una idea por cubo:

    Idea Lover (la que te emociona). Esa idea ambiciosa que, si saliera, te llenaría de orgullo. No pienses si es posible o no, sólo piensa que es la que te emociona.

    Idea Easy (la técnicamente sencilla). Aquella idea que puede ponerse en marcha rápido porque la tecnología y el know-how son conocidos. La idea que te acerca más rápidamente al mercado.

    Idea Shrek (la que “nunca harías”). Deliberadamente fea o incómoda; sirve para pensar diferente y estirar límites, especialmente cuando aplicas moldes. Es aquella idea que rechazarías nada más tenerla. No lo hagas y aprende de ella.

    Idea Killer (la que destruiría tu empresa si la lanzara un competidor). Te obliga a mirar disrupciones y a diseñar defensas/ataques. Es la que potencialmente cambiaría el mercado.

    No olvides que la idea o ideas elegidas son, en cierto modo, ideas en bruto, que hemos de refinar aplicando moldes u otras técnicas. El proceso Generar > Seleccionar > Refinar es muy potente para terminar esta fase con ideas consistentes.

    Te mencionamos algunas técnicas que pueden serte útiles en esta fase para idear o refinar. Sólo las vamos a mencionar porque hay mucha información en internet:

    Brainwriting 6-3-5 (o variantes rápidas): estructura volumen y construcción sobre ideas ajenas.

    Analogías forzadas: Por ejemplo, “¿Cómo resolvería esto una aerolínea de bajo coste / un hospital / un gamer?”

    SCAMPER (Sustituir, Combinar, Adaptar…): obliga a operar sobre la idea, no solo a opinar.

    Mapa de riesgos/hipótesis: vincula cada idea con los aprendizajes críticos que buscarás en prototipado/test.

    Es importante no perder el foco en la calidad de las ideas. Ya hemos dicho que primero buscamos cantidad, pero tras ese vuelco inicial de ideas hemos de quedarnos con las que desde el punto de vista de la calidad sean más adecuadas. Para ello seguimos los siguientes criterios de calidad:

    Alineación con el foco (HMW). Si una idea no responde al HMW, aparca o vuelve a formular el HMW. 

    Tensión útil: busca contrapesos en tu portafolio (una Easy + una Killer). Evita quedarte solo con la de menor fricción interna. 

    Claridad narrativa: si no puedes dibujarla en una servilleta (flujo, usuario, promesa), igual no está madura. Dibujar obliga a concretar.

    Vale, pero ¿cómo medimos el éxito de una sesión de ideación? Para ello ten en cuenta los siguientes puntos:

    Volumen: ¿se alcanzó (o superó) el objetivo de ideas por minuto/ronda? 

    Variedad: ¿aparecieron enfoques radicalmente distintos (por molde/analogía)? 

    Valor: ¿las ideas top conectan con el PoV/HMW y con insights de la fase 2?

    Velocidad a prototipo: ¿puedes transformar al menos una Easy en un boceto/storyboard ese mismo día?

    Fase 4 – Prototipar

    En la fase de prototipado empezamos a materializar la solución propuesta en la fase de ideación. Es posibles que hayamos terminado la fase anterior con una idea sobre la que vamos a trabajar, pero también es posible que tengamos 2 o 3 ideas que vemos interesantes y sobre las que no logramos decidir cuál es la mejor. En la fase de prototipado es cuando vamos a trabajar sobre cada una de ellas para poder tomar una decisión más consistente.

    Con el prototipo construimos la posible solución para mostrarla al cliente o a los actores que consideremos relevantes (usuarios, proveedores…). Pero recordemos que prototipar no es “hacer una mini-versión perfecta” de la solución. Es construir lo mínimo necesario para aprender del usuario cuanto antes. Un prototipo es, por definición, desechable: existe para responder una pregunta de aprendizaje (“¿entiende la promesa?”, “¿haría esto en la calle?”, “¿confía lo suficiente como para pagar?”). 

    Consideramos que el prototipo tiene dos fases de conocimiento:

    1.-El prototipo se construye por el equipo, y en esa fase de construcción vamos afinando, analizando y perfeccionando la idea. No hablamos de un Producto Mínimo Viable, sino de algo desechable, una herramienta de usar y tirar.

    2.-Una vez construido el prototipo lo enseñamos al usuario para aprender lo que tratamos de comprender desde la visión del usuario 

    La mentalidad adecuada de todo este proceso es construir para pensar, no pensar para construir. Antes de cortar cartón o abrir Figma, escribe en una frase qué quieres aprender y qué decidirás con ese aprendizaje (seguir/iterar/pivotar). Ponle un umbral de decisión (“si 4 de 5 usuarios hacen X sin ayuda, pasamos a la siguiente fidelidad”). Y recuerda la vacuna del ego: no te enamores del prototipo.

    Ahora bien, un prototipo puede ser de muchos tipos y la elección del mejor o más adecuado depende de muchas cosas. Imaginemos que estamos prototipando un packaging para llevar el almuerzo al colegio, lo normal es que sea un prototipo físico, en el que construyamos el producto materialmente para visualizarlo y mostrarlo de una manera más realista. Pero imaginemos que estamos trabajando en el cambio del check-in de un hotel. Aquí no es necesario construir nada físico, sino que nos centraremos en un prototipo experiencial, en el que representaremos y analizaremos las acciones que se hacen en un proceso de check-in.

    De este modo, podemos considerar que hay tres tipos de prototipado:

    Físico (objeto/interfaz).
    Lo que el usuario toca o ve: una pantalla, un botón, un envase, un dispositivo. Aquí compruebas ergonomía, legibilidad, flujo básico o señales de confianza (copy, iconos, estados). Ej.: un “click-through” en móvil, un envase impreso 1:1, una pieza hecha con impresora 3D.

    Experiencia (servicio/flujo).
    La secuencia de acciones, personas y evidencias que vive el usuario. Aquí validas momentos de la verdad, tiempos de espera, handoffs entre roles, qué pasa si…. Ej.: un storyboard de 8 viñetas, un service walkthrough con tarjetas, un script de atención y su “backstage”.

    Entorno (ecosistema/sistema).
    Lo que rodea a la experiencia: normas, espacio físico, colas, horarios, señalética, integraciones, restricciones. Aquí examinas fricciones estructurales. Ej.: un role-play en el lugar real con cinta en el suelo para simular colas; una señal temporal en tienda; un calendario simulado con reglas.

    Por supuesto, es posible que un determinado prototipo requiera de los tres tipos indicados. La propia entrada al hotel o a un hospital, o la experiencia en un restaurante puede requerir de prototipos físicos, experienciales y de entorno. Todo depende del nivel de análisis que estemos desarrollando y de qué queramos conocer.

    Mostramos ahora algunos ejemplos de prototipos que utilizamos en Innolandia, todos rápidos y baratos:

    1. Servilleta (sketch en 2–3 minutos)

    Qué valida: Idea núcleo, propuesta de valor, jerarquía visual, “de qué va esto”.
    Cómo: Dibuja el flujo en 4 cuadros o la home de una app en una servilleta/folio. Escribe la promesa en grande.
    Señales: ¿El usuario entiende en 10–15 segundos? ¿Señala el CTA correcto? ¿Dónde duda?

    • Maquetas (papel, cartón, impresión 3D, prototipo clicable)

    Qué valida: Forma, manipulación, estados básicos de una interfaz o producto.
    Cómo: Papel recortado para simular pantallas (paper prototyping), un clicable en Figma/PowerPoint, o pieza 3D simple.
    Señales: tasa de acierto en tareas triviales, tiempos, errores, comentarios espontáneos (“esto me confunde”).

    Qué valida: Secuencia y coherencia de la experiencia extremo a extremo.
    Cómo: 6–12 viñetas con momentos clave, emociones y evidencias físicas (“ticket”, “email”, “pack”).
    Señales: ¿El usuario reconoce su viaje? ¿Dónde pone cara rara? ¿Qué escena le falta?

    • Storytelling (pitch + artefacto mínimo)

    Qué valida: Mensaje, tono, promesa, valor percibido (a veces, disposición a pagar).
    Cómo: Guion de 60–90″ + hoja simple (flyer, email impreso, mock de landing).
    Señales: ¿Repite tu promesa con sus palabras? ¿Qué objeciones aparecen? ¿Pediría más info? (En B2B, pide “señales de compromiso”: agenda de prueba, contacto de un sponsor).

    • Role-playing (bodystorming)

    Qué valida: Interacciones humanas, tiempos, barreras reales del contexto.
    Cómo: Representa la escena completa con personas y objetos (mostrador, cartel, “sistema” en papel).
    Señales: ¿Se forma cola? ¿Necesitas otra persona/turno? ¿Qué frase del script no funciona?

    Recuerda que el primer artefacto debe existir en 24 horas y costar menos de 100€. Si no puedes, probablemente estás construyendo demasiado. Cómo lograrlo:

    • Recorta alcance: céntrate en un aprendizaje por prototipo.
    • Materiales humildes: papel, cartón, cinta, figuritas, plantillas imprimibles, maquetas de baja resolución.
    • Reutiliza assets: wireframes genéricos, componentes UI, plantillas de pitch.
    • Tiempo acotado: timebox de 60–120′ para construir y 30–60′ para test rápido.
    • Equipo pequeño: 2–3 personas por prototipo (diseña, construye, “actúa”).

    Truco de calidad: define umbral de decisión por adelantado (p. ej., “si 4/5 usuarios completan la tarea en <90s sin ayuda, pasamos a fidelidad media; si no, iteramos aquí”). Evita el “círculo del prototipo infinito”.

    Aprendizaje esperado (pregunta)NivelTipo de prototipo aconsejadoCómo lo medimosUmbral de decisión
    ¿Entiende la promesa en 15s?Físico/ExperienciaServilleta + storytelling (titular + CTA)Repite con sus palabras; señala CTA correcto4/5 lo explican bien
    ¿La secuencia completa tiene sentido?ExperienciaStoryboard (8–12 viñetas)Dónde duda; viñetas que faltan/sobran≤2 dudas críticas
    ¿Puede completar la tarea sin ayuda?FísicoMaqueta clicable o papelÉxito en tarea, tiempo, errores80% éxito, <90s
    ¿El tono y el mensaje generan confianza?ExperienciaStorytelling (pitch + hoja)Objeciones y lenguaje “de confianza”<2 objeciones mayores
    ¿Funcionan las interacciones humanas?Entorno/ExperienciaRole-play con scriptAtascos, tiempos, handoffsFlujo sin bloqueos >80%
    ¿Qué pasa sin conexión/con restricción real?EntornoRole-play + señales físicas (“sin red”)Comportamientos, plan BPlan B aceptado por 4/5
    ¿Valoraría pagar por esto?ExperienciaStorytelling + “oferta” simuladaSeñales de compromiso (agenda prueba, email, orden interna)≥2 señales fuertes

    Para terminar esta parte te mostramos algunos de los errores típicos de la fase de prototipado y algunos antídotos para solucionarlos:

    Perfeccionismo temprano → Antídoto: define el aprendizaje mínimo y timebox.

    Construir sin foco → Antídoto: PoV/HMW visibles en la sala.

    Test de laboratorio sin contexto → Antídoto: lleva el prototipo “al mundo” (pasillo, tienda, calle, obra).

    Enamorarse del artefacto → Antídoto: ritual de “prototipo a la papelera” tras consolidar aprendizajes.

    Opiniones sueltas → Antídoto: busca patrones (matriz de feedback) y decide por umbral.

    Fase 5- Testar e iterar

    Ya conocemos el problema, hemos propuesto una solución y hemos creado un prototipo. Ahora toca testarlo con el usuario/cliente. Recordemos que en esta fase no estamos tratando de entrar ya en el mercado, ni siquiera de mostrar un PMV, sino de seguir aprendiendo para en una fase posterior empezar a construir para vender y validar la venta.

    Por eso es importante que enfoquemos bien esta fase: buscamos aprender, no vender. De igual manera es importante que el testeo lo hagamos correctamente:

    No vender. Entra como explorador, no como comercial. Evita justificar la solución; deja que hable el prototipo.

    Humildad radical. Tu objetivo no es tener razón, sino descubrir la verdad de uso. Cada objeción es oro.

    Equipo tomando notas. Mínimo dos personas: una guía y otra anota (citas literales, tiempos, gestos). Si el usuario acepta, graba vídeo; verás detalles que se escapan en directo.

    Respeto por el contexto. Si puedes, prueba donde ocurre el comportamiento (tienda, calle, taller, backoffice).

    Una hipótesis por vez. No intentes validarlo todo en una sesión. Define qué quieres aprender y un umbral de decisión antes de empezar.

     Ante de iniciar la prueba o el testeo es interesante que tengas en cuenta una serie de puntos que te ayudarán a tener más éxito en tu análisis y que te ayudarán a prepararlo:

    Aprendizaje objetivo (1 línea): “Queremos saber si X entiende la promesa y completa Y en <90s sin ayuda”. Lo que quieras analizar has de poder explicarlo en una frase. No te compliques buscando aprendizajes complejos. Si vas a mostrar un prototipo ten en cuenta qué quieres aprender de esa presentación y el correspondiente feedback: ¿es el uso, el atractivo del modelo, la dureza, la comprensión del cliente…? Si son varias cosas defínelas de la manera más simple posible y diferéncialas en el análisis

    Hipótesis explícita: “Creemos que cambiar el CTA a ‘Reservar ahora’ reducirá dudas”. Trata de ser claro y concreto en la definición de la hipótesis.

    Métrica y umbral: éxito de tarea ≥80% con ≤1 duda crítica; si no, iteramos copy y flujo. Es importante que trabajes con métricas que definan el éxito o el go/no go del proyecto o del prototipo.

    Guion de test: contexto (“cuéntame tu día”), tarea/escena, silencio mientras actúa, preguntas de por qué, cierre con matriz de feedback. No vayas a pecho descubierto, lleva siempre un guion, que podrás saltártelo si lo crees conveniente, pero que lo tendrás siempre a mano.

    Muestra pequeña (≈5 usuarios): busca patrones, no unanimidad. Combina extremos (novatos/expertos). Trata de ser rápido y barato en tus análisis. Evita la parálisis por análisis.

    En Innolandia solemos utilizar dos tipos de plantillas para trabajar en este tipo de experimentos. Por un lado, la ficha de experimento, en la que definimos y describimos el experimento que vamos a realizar:

    Y por otro lado la matriz de feedback, con la que recogemos la información en el momento del experimento:

    Con ambas plantillas recogemos información suficiente para saber si podemos validar el prototipo y las hipótesis de las que partimos.

    De este modo, una sesión tipo de unos 15 o 20 minutos podría tener el siguiente guion:

    Calienta (2–3′). “Gracias por tu tiempo. No probamos personas, probamos el prototipo.” Evita sesgos.

    Contexto (3–4′). “Cuéntame cómo haces ahora [tarea]… ¿qué te cuesta más?” Pregunta 2–3 veces “¿por qué?”.

    Tarea/escena (6–8′). Entrega el prototipo y calla. Observa manos, mirada, silencios.

    Sondeo (3–4′). “¿Qué has entendido? ¿Dónde dudaste? ¿Qué te sorprendería que hiciera?”

    Cierre (2–3′). Agradece y completa tu matriz de feedback (positivo / negativo / dudas / ideas) con ejemplos concretos.

    Es muy difícil que el prototipo guste 100%. Lo normal es que debas cambiar cosas, añadir unas y quitar otras, es decir, iterar. Para ello es importante que trabajes con la información que recoges. Y puede ser incluso adecuado que no esperes a “el informe”. De ese modo itera en la misma sesión si puedes: cambia el copy del CTA, invierte dos pasos, añade una señal visual, reescribe el microcopy de error, mueve la posición del botón, prueba otra formulación del pitch. Esa espiral (test → microcambio → test → microcambio) acelera el aprendizaje y evita el círculo infinito de prototipos sin decisiones. Puesto que ya estás trabajando con el cliente potencial y él está dentro de la dinámica, aprovéchalo.

    Al final del bloque con 5 usuarios, toma una decisión explícita:

    • Iterar aquí (mismo nivel de fidelidad, nuevos cambios),
    • Pivotar PoV/HMW (aprendiste algo estructural), o
    • Avanzar a mayor fidelidad / piloto controlado.

    Para finalizar esta parte te vamos a mostrar algunos errores típicos al testar y cómo evitarlos:

    Entrevista dirigida (“te gusta, ¿verdad?”) → Preguntas neutras y abiertas.

    Ayudar al usuario para que “salga bien” → Silencio y paciencia; mide dónde se atasca.

    Recoger opiniones, no evidencias → Observa comportamiento; usa la matriz.

    Post-mortems eternos → Umbral y decisión el mismo día.

    No iterar in situ → Llega con materiales para cambiar rápido (copias de pantallas, rotuladores, cinta).

    Cómo potenciar el Design Thinking con la IA Generativa

    La IA está de moda, y en concreto la Inteligencia Artificial Generativa (IAG), a la que en Innolandia hemos dado una vuelta de modo que hablamos de Innovación Aumentada, es decir, la aplicación de la IAG a procesos de innovación de una manera estructurada y racional.

    Esto último es importante, porque no basta con usar la IAG, es necesario saber cómo y qué podemos esperar de ella, es decir, no construir castillos en el aire ni pensar que las nubes son de colores, Hay que ser realista, saber cuáles son los límites.

    La IAG es un copiloto, no el piloto. Bien usada, acelera análisis, documentación e ideación; mal usada, genera humo elegante y mata la creatividad. Aquí la clave es: personas reales + método + IA como turbo, no como sustituto.

    Por eso es necesario que tengas en cuenta una serie de consejos si quieres utilizar la IAG en procesos de Design Thinking. Aquí van los más importantes:

    No sustituye trabajo de campo. La IA parte de texto, de interpretaciones y de enfoques que podemos trabajar en la oficina; los insights vienen de usuarios reales, de nuestra interacción con ellos, es decir, de la fuente primaria.

    Una sola persona operando la IA en sesión. Evita 6 personas chateando a la vez y clonando sesgos; el resto piensa, dibuja, discute. Esto es importante, porque evita cruces, pérdida de información, contradicciones…

    Prompts con contexto. Cuanto más concreto seas (segmento, sector, restricción), más útil. No es raro preguntar a la IAG y que su respuesta sea demasiado generalista, sin precisión y repetitiva, eso es porque le falta contexto, le falta información del proyecto. Cuanta más le demos, mejor respuesta nos dará ella.

    Pensamiento crítico siempre. Contrastar, no tragar: la IA se inventa cosas, arrastra sesgos, desconoce matices internos. Debemos ser nosotros los que dominen a la IAG y no al revés. Esto lo hacemos revisando, corrigiendo y repreguntando cuando el resultado no es el esperado. Seamos críticos con la IAG.

    Cuidado con datos sensibles. Anonimiza entrevistas, nombres y cifras internas. Es posible que no haya problemas de pérdida de información, pero mejor prevenir que curar.

    Tiempo acotado. La IA es turbo, no agujero negro. Si llevas media hora “jugando”, paras y vuelves al usuario. Si te quedas en la IA entras en un círculo vicioso de pregunta-respuesta que te puede atrapar y te impide avanzar. Si llevas 40 minutos “jugando con prompts”, has dejado de innovar.

    Ahora vamos a analizar cómo podemos servirnos de la IAG en cada una de las fases que hemos descrito del Design Thinking. Con esto vamos a profundizar un poco en cuánto y cómo nos puede ser útil la IAG:

    1) Empatizar

    • Arquetipos / Buyer Persona (borrador). Generar hipótesis iniciales sobre segmentos para luego validar en campo.
    • Guiones de entrevistas. Crear listas de preguntas abiertas adaptadas a cada tipo de usuario.
    • Mapas de empatía iniciales. Estructurar “piensa/siente/ve/oye/dice-hace” como base del taller.
    • Análisis de patrones. Volcar transcripciones y pedir clusters de temas, pains, citas clave. 

    Uso correcto: te ahorra tiempo en preparación y síntesis. El contenido relevante sigue viniendo de la calle, no del modelo.

    2) Definir

    • Agrupar insights. Pedir ayuda para ordenar citas en nubes temáticas y proponer primeros PoV.
    • Refinar PoV y HMW. Generar variantes y elegir las que mejor encajan con tus evidencias.
    • Jobs to be Done. Pedirle que clasifique hallazgos en Jobs funcionales/ sociales/ emocionales para ver causalidad.

    Aquí la IA acelera el “ordenar la pared llena de post-its”, pero la decisión de foco es humana.

    3) Idear

    • Ideación dirigida. Generar listas de ideas condicionadas por PoV/HMW, sector, restricciones, tecnologías.
    • Perspectivas forzadas. Pedirle que piense como “low-cost”, “premium”, “competidor X”, “sombrero negro/verde” de De Bono, etc. 
    • Evaluación impacto–esfuerzo. Subir un listado de ideas y pedir una primera matriz deseabilidad / factibilidad / viabilidad como input al equipo (no como verdad).

    Importante: primero idean las personas; luego la IA expande, combina o estresa ideas. No al revés.

    4) Prototipar

    • Storyboards con imagen. Generar escenas visuales para explicar una experiencia en 6–8 pasos. 
    • Pantallas y maquetas rápidas. Crear propuestas de UI, cartelería, folletos, layouts.
    • Copy de prueba. Variantes de mensajes, claims, CTAs, emails, guiones de atención.

    La IA aquí es perfecta para “hacer tangible” y tener algo que enseñar mañana sin gastar diseño senior.

    5) Testar

    • Diseño del test. Guiones de sesiones, preguntas neutrales, consentimientos, plantillas de matriz de feedback.
    • Síntesis de feedback. Pasar notas/transcripciones y pedir patrones positivos/negativos/dudas/ideas. 
    • Aprendizajes accionables. Pedir propuestas de “siguientes iteraciones” alineadas con criterios que tú definas.

    De nuevo: la IA ayuda a ver patrones; tú verificas con notas originales y decides.

    Evidentemente, para cada una de estas fases y usos se necesitan prompts. Aquí te vamos a mostrar algunos prompts como ejemplo. No los tomes como el prompt definitivo, sino como un ejemplo que tendrás que adaptar a tu caso. Entiéndelos más como una plantilla mínima:

    Empatizar

    1. Arquetipo inicial

    “Actúa como investigador. Define 2–3 arquetipos de clientes para [producto/servicio] en [país/sector], indicando contexto, objetivos, pains y comportamientos clave. No inventes datos numéricos.”

    1. Guion de entrevistas

    “Genera 15 preguntas abiertas para entrevistar a [tipo de usuario] sobre cómo hace hoy [tarea], qué le frustra y qué valora. Sin sugerir respuestas.”

    1. Análisis de entrevistas

    “A partir de estas transcripciones [pegar], identifica patrones: pains recurrentes, objetivos, frases literales clave. Devuélvelo en bullets.”

    Definir

    1. Nubes + PoV

    “Con estos hallazgos [pegar], agrúpalos en 5–7 temas. Para cada tema, propone 1 posible Point of View (Usuario + Necesidad + Insight), sin soluciones implícitas.”

    1. How Might We

    “A partir de este PoV [pegar], genera 5 preguntas ‘How might we…’ concretas, centradas en el usuario, ni muy amplias ni muy cerradas.”

    1. Jobs to be Done

    “Clasifica estos insights [pegar] en Jobs funcionales, sociales y emocionales, y relaciona cada pain/gain con un Job.”

    Idear

    1. Ideación dirigida

    “Genera 40 ideas para responder a este HMW [pegar], en [sector], bajo estas restricciones [lista]. Distingue entre ideas incrementales y radicales.”

    1. Evaluación impacto–esfuerzo

    “Con esta lista de ideas [pegar], sugiere una matriz impacto–esfuerzo (alto/medio/bajo) basada en deseabilidad, factibilidad y coste. Justifica en 1 línea por idea.”

    Prototipar

    1. Storyboard

    “Diseña un storyboard en 8 pasos para explicar cómo [usuario] usa [idea], indicando contexto, acción, emoción y evidencia física/visual en cada viñeta.”

    1. Copy & pantallas

    “Propón estructura y textos de una pantalla principal para [servicio], alineada con este PoV [pegar]. Incluye titular, subtítulo, CTA y 3 beneficios.”

    Testar

    1. Guion de test

    “Diseña un guion de test con usuarios para evaluar este prototipo [descripción/enlace], con: intro neutral, 3 tareas, preguntas abiertas y criterios de éxito.”

    1. Matriz de feedback

    “Con estos comentarios de usuarios [pegar], construye una matriz en 4 columnas: Positivos, Negativos, Dudas, Ideas. Luego resume 5 patrones clave y sugiere 3 cambios de prototipo.”

    Recuerda que la IAG no sustituye tu proceso de Design Thinking: lo acelera, lo hace más visible y te libera tiempo para lo importante: mirar a tus usuarios, decidir mejor y lanzar antes.

    Errores frecuentes y cómo evitarlos

    Como toda metodología, es normal cometer errores, sobre todo cuando se usa por primera vez. Algunos de esos errores los cometemos incluso los que llevamos años trabajando con el DS. Pero lo importante es que tengamos la capacidad de identificar y corregir esos errores. Para eso te mostramos una guía muy esquemática pero completa de posibles errores y sus antídotos. Empezamos con los errores que se suelen cometer en el DS “clásico”, es decir, antes de la aparición de la IAG (pero que también se cometen con la IAG):

    1. Expectativas mágicas

    • Error: creer que el Design Thinking sacará “la idea salvadora” solo con post-its.
    • Antídoto clave: pacto inicial de restricciones + objetivos realistas (qué sí / qué no se toca).

    2. Exploración pobre

    • Error: pocas entrevistas, cero observaciones, todo desde la sala. 
    • Antídoto: mínimo varias técnicas (entrevistas, shadowing, “día en la vida”, CJ) hasta encontrar cosas nuevas.

    3. Quedarse en hechos, no en causas

    • Error: describir comportamientos sin entender porqués. 
    • Antídoto: clasificar en Jobs / Pains / Gains y buscar relación causa–efecto (insights).

    4. Baja calidad de ideas (autocensura)

    • Error: solo ideas “posibles”, cero radicales; se mata la creatividad en la sala. 
    • Antídoto: separar divergir vs. decidir, usar moldes creativos, equipos diversos, dejar pasar ideas locas a prototipado.

    5. Prototipo infinito

    • Error: iterar prototipos sin decidir, sin fecha ni criterios. 
    • Antídoto: regla 24h / <100€, 1 aprendizaje por prototipo, umbral claro (si pasa → avanza; si no → cambia).

    6. Decidir por opiniones aisladas

    • Error: cambiar todo por lo que dijo “un cliente importante”. 
    • Antídoto: usar matriz de feedback, buscar patrones en ~5 usuarios, ignorar outliers sin repetición.

    7. Atrapados en el diseño sin pedir “tarjeta de crédito”

    • Error: prototipos bonitos, presentaciones, likes internos… sin prueba de mercado real. 
    • Antídoto: traducir aprendizajes a test de compromiso: pre-reservas, cartas de intención, pagos piloto, tiempo invertido.

    Ahora incluimos un listado y posibles antídotos contra los errores cometidos específicamente cuando utilizamos la IAG en Design Thinking:

    1. Sustituir trabajo de campo por IA

    • Error: “que la IA me invente al cliente”.
    • Antídoto: IA solo para estructurar y ampliar, nunca en lugar de usuarios reales.

    2. Creer que la IA siempre tiene razón

    • Error: copiar sin contraste.
    • Antídoto: marcar todo como hipótesis, contrastar con evidencias.

    3. Dejar que la IA marque el foco

    • Error: PoV/HMW dictados por la máquina.
    • Antídoto: PoV/HMW se validan con datos de campo y negocio, no solo texto bonito.

    4. Many people, many prompts

    • Error: la sesión se vuelve “circo de pantallas”.
    • Antídoto: 1 operador IA, resto observa, piensa, decide.

    5. Prompts vagos / genéricos

    • Error: outputs obvios, basura elegante.
    • Antídoto: prompts con contexto, restricciones, datos reales.

    6. Confirmar sesgos con IA

    • Error: pedirle que soporte lo que ya creo.
    • Antídoto: pedir alternativas, contraejemplos, riesgos, puntos ciegos.

    7. Matar la creatividad del equipo

    • Error: dejar que la IA genere todas las ideas.
    • Antídoto: primero idean personas; IA solo expande, combina, provoca.

    Cerrar este artículo es sencillo: ahora te toca salir al mundo real.

    El Design Thinking que hemos recorrido aquí no es una moda ni un ritual de post-its. Es una forma disciplinada de reducir incertidumbre cuando los Excel ya no bastan: hablar con personas reales, entender causas (no solo síntomas), generar alternativas con intención, prototipar rápido, testar con humildad y decidir con evidencias. Y, si quieres, apoyarte en IA generativa como copiloto para ir más rápido sin perder criterio.

    Si te quedas solo con una idea, que sea esta: no esperes a tenerlo perfecto para poner algo delante del usuario. El riesgo no está en enseñar demasiado pronto, sino en llegar demasiado tarde con algo que nadie quiere o no puede usar.

    Qué puedes hacer mañana mismo:

    1. Elige un reto concreto: un proceso roto, una experiencia clave, un servicio estratégico.
    2. Habla con 5 usuarios reales esta semana. Observa, pregunta “por qué”, captura frases literales.
    3. Formula 1 PoV + 1 HMW potente.
    4. Genera ideas durante 45 minutos con tu equipo (sin juzgar).
    5. Construye un prototipo en 24h, por menos de 100€.
    6. Testa con 5 personas, usa la matriz de feedback y toma una decisión en el día.

    Si repites este ciclo, tu organización deja de “hacer talleres de innovación” y empieza a aprender sistemáticamente del mercado. Ahí está la diferencia entre coleccionar canvas y construir soluciones que se venden, se usan y se recomiendan.

    Y si algo de este artículo te ha removido, perfecto: úsalo como guía, discútelo con tu equipo, destroza lo que no encaje en tu contexto… pero no vuelvas al power point sin pasar primero por tus usuarios. Ahí fuera es donde empieza el diseño de verdad.

    Los comentarios están cerrados.

    * indica que es obligatorio