¿Qué es el design thinking? 5 etapas, ejemplos reales y por qué tantos equipos se equivocan

El design thinking es un flujo de diseño iterativo centrado en las personas que resuelve problemas mediante cinco etapas principales: empatizar, definir, idear, prototipar y probar. En lugar de seguirlas como una secuencia rígida, los equipos las usan para comprender a los usuarios, plantear el problema adecuado, comprobar supuestos y reducir la incertidumbre antes de elegir una solución.

El problema es que muchos equipos tratan el design thinking como una lista de cinco pasos. La investigación se alarga sin prototipos, los talleres producen ideas sin acciones y la IA genera conceptos antes de aclarar el problema real. El reto es decidir qué merece la pena explorar, probar y construir.

Virse ayuda a conectar la investigación, las ideas, los prototipos y la exploración asistida por IA. Con un lienzo infinito, contexto compartido del proyecto, varios agentes de IA y memoria de equipo a largo plazo, los equipos exploran más rápido sin perder de vista el problema del usuario ni las decisiones que guían el proyecto.

¿Qué significa design thinking en términos sencillos?

Design thinking significa aprender qué necesitan realmente las personas antes de decidir qué construir.

Un proceso práctico de design thinking puede resumirse en seis acciones:

1. Comprender a las personas y su contexto.
2. Identificar el problema subyacente.
3. Explorar varias soluciones posibles.
4. Convertir los supuestos importantes en prototipos y maquetas.
5. Comprobar esos supuestos mediante interacciones reales.
6. Revisar el problema o la solución según las evidencias.

Un ejemplo sencillo de design thinking

Imagina que un equipo universitario recibe este encargo:

Rediseñar la aplicación de la cafetería.

Un equipo que parte de la solución puede rediseñar de inmediato menús, navegación o pantallas de pedidos. Un equipo de design thinking investiga primero por qué los estudiantes tienen dificultades.

La investigación puede revelar que el problema real no es pedir comida. Los estudiantes no pueden prever si les dará tiempo a hacer cola entre clases.

El reto pasa de:

¿Cómo deberíamos rediseñar la aplicación de la cafetería?

a:

¿Cómo podríamos ayudar a los estudiantes a decidir si tienen tiempo suficiente para comer?

Ese nuevo planteamiento podría dar lugar a un estimador de colas, un sistema de recogida, un indicador de aforo, una pantalla física o una solución totalmente distinta.

La lección es sencilla: una petición de una parte interesada suele describir una solución propuesta, no el problema de diseño de producto subyacente.

¿Cuáles son las cinco etapas del proceso de design thinking?

El modelo más conocido incluye empatizar, definir, idear, prototipar y probar. Conviene entenderlas como modos repetibles, no como cinco pasos consecutivos obligatorios.

Empatizar: comprender a los usuarios antes de diseñar

La etapa de empatía investiga qué hacen las personas, qué necesitan, dónde encuentran dificultades y por qué.

Los equipos pueden usar entrevistas, observación, investigación contextual, conversaciones con partes interesadas o evidencias de comportamiento.

En un caso profesional revisado para este artículo, el equipo combinó inmersión, observación, entrevistas abiertas, priorización y descomposición del problema. El profesional informó de la participación de aproximadamente 8–9 usuarios avanzados, convencionales o extremos y partes interesadas de cada categoría, lo que acabó generando decenas de ideas de productos y servicios.

Esa cifra no es un estándar universal de investigación. El principio útil es que la exposición directa a distintos comportamientos aporta una base más sólida que las suposiciones internas por sí solas.

Definir: convertir la investigación en el problema adecuado

La investigación produce información. Definir transforma esa información en un problema sobre el que el equipo puede actuar.

Compara:

Enunciado de solución: necesitamos una función móvil para seguir la cola.

Enunciado del problema: los estudiantes necesitan una forma fiable de decidir si tienen tiempo suficiente para comer.

El primero ya ha elegido una respuesta. El segundo mantiene abierto el espacio de soluciones.

Un buen planteamiento busca comportamientos recurrentes, necesidades insatisfechas, tensiones, restricciones y supuestos antes de elegir funcionalidades.

Idear: explorar alternativas antes de comprometerse

La ideación crea alternativas de forma deliberada antes de que el equipo invierta mucho en una dirección.

Entre las técnicas útiles están las preguntas «¿Cómo podríamos…?», Crazy 8s, los ejercicios de inversión, la peor idea y los bocetos colaborativos.

Los equipos multidisciplinares afrontan aquí un reto particular. Los ingenieros consideran de forma natural las API, bases de datos, arquitectura, costes y complejidad de implementación. Esa experiencia es esencial, pero aplicar todas las restricciones desde el principio puede reducir demasiado pronto el espacio de soluciones.

Un principio práctico es:

Primero divergir, después converger.

Explora ampliamente y después incorpora la factibilidad, la viabilidad, las restricciones técnicas y la responsabilidad a la decisión.

Prototipar: hacer comprobables los supuestos

Un prototipo es un experimento, no un producto terminado en miniatura.

Puede ser una interfaz en papel, un wireframe, un storyboard, una simulación de servicio, un modelo físico o una versión operada manualmente de un flujo automatizado.

La fidelidad adecuada depende de la pregunta. Si necesitas saber si los usuarios comprenden un flujo, un wireframe puede bastar. Si necesitas entender la confianza en un servicio nuevo, simularlo puede ser más útil que construir su tecnología subyacente.

El mejor prototipo suele ser el artefacto de menor coste capaz de responder de forma creíble a la pregunta actual.

Probar: aprender del comportamiento real

Las pruebas sustituyen las opiniones internas por evidencias observables.

Los equipos buscan dudas, malentendidos, comportamientos inesperados, supuestos fallidos y señales de que la solución propuesta realmente ayuda.

Una prueba puede devolver al equipo a definir o empatizar. Eso no es un fracaso.

Las pruebas existen para aprender, no para demostrar que el equipo tenía razón.

¿Por qué el design thinking no es un proceso lineal de cinco pasos?

No existe una única secuencia universal de design thinking.

Cada organización estructura de forma diferente el mismo proceso de aprendizaje subyacente.

Cómo encajan los marcos de cuatro, cinco y siete etapas

Pese a las diferencias terminológicas, los tres modelos comparten un patrón:

Comprender → aclarar → explorar → crear → probar → aprender → repetir

IxDF separa las actividades básicas de diseño en cinco modos reconocibles. HBS las condensa en un modelo de cuatro etapas orientado al negocio. El marco de IDEO U revisado aquí distingue con más detalle planteamiento, inspiración, síntesis, generación de ideas, creación, pruebas y comunicación.

Para los equipos que trabajan en proyectos, el ciclo de aprendizaje importa más que el número de casillas.

¿Cuánta investigación UX basta antes de crear prototipos?

No existe un número universal de entrevistas, días o semanas que indique a todos los equipos cuándo detener la investigación.

Una pregunta mejor es:

¿Otra ronda de investigación nos enseñará más que hacer comprobable un supuesto?

Qué pueden revelar los ciclos largos de investigación

Nuestra revisión de casos profesionales encontró proyectos que, según sus responsables, permanecieron investigando entre 12 y más de 18 semanas sin mostrar un prototipo a los usuarios.

Otro profesional indicó que cuatro a seis semanas de investigación y planificación solían bastar en sus proyectos para empezar a crear wireframes.

Son observaciones de casos concretos, no referencias universales. Cada proyecto presenta distintos grados de incertidumbre conductual, técnica, comercial y regulatoria.

El patrón más importante es que la investigación pierde valor cuando los equipos siguen produciendo hallazgos, pero evitan comprobar los supuestos importantes.

¿Cuándo debería empezar un equipo a crear prototipos?

Una regla profesional útil es:

Crea un prototipo cuando hacer tangible la idea te enseñe más que otra ronda de discusión interna.

Continúa investigando si el comportamiento fundamental no está claro. Empieza a prototipar cuando puedas comprobar un supuesto importante a bajo coste.

Esto ayuda a evitar tanto el diseño prematuro como la parálisis de investigación.

¿Por qué fracasan los talleres de design thinking en organizaciones reales?

Los talleres fracasan cuando las organizaciones copian los rituales visibles, pero eliminan el aprendizaje.

El patrón habitual de fracaso es:

Taller → ideas → presentación → sin responsable → sin prototipo → sin cambios

¿Qué convierte el design thinking en una puesta en escena?

En nuestra revisión de casos profesionales y preguntas de usuarios aparecieron repetidamente varias causas en los flujos de diseño:

• falta de evidencias reales de usuarios
• falta de una persona responsable de decidir
• ausencia de una vía de implementación
• ausencia de prototipo
• ausencia de seguimiento
• convertir la participación en el taller en el entregable

Un taller debe cambiar lo que sucede después. Puede aclarar un problema, identificar supuestos, priorizar conceptos, crear un prototipo o maqueta, o establecer responsabilidades.

Si después no cambia nada, el equipo ha completado una actividad, no un proceso de diseño.

Un caso de taller que llegó a implementarse

Un caso profesional incluyó talleres con múltiples partes interesadas aproximadamente una vez al mes durante cuatro meses, y transcurrieron unos seis meses desde el primer taller hasta el lanzamiento.

El trabajo continuó más allá de la ideación hacia un rediseño más amplio del servicio y el desarrollo de un sistema de diseño y una biblioteca de componentes.

El profesional describió el lanzamiento como exitoso en Estados Unidos y mercados internacionales, pero no aportó métricas de ingresos, conversión o retención.

Esa distinción importa para E-E-A-T: no debe presentarse un éxito declarado como impacto empresarial cuantificado sin datos que lo respalden.

¿Todo proyecto UX necesita el proceso completo de design thinking?

No. El design thinking debe adaptarse a la incertidumbre, no obligar a todos los proyectos a seguir la misma secuencia.

Un equipo que mejora un proceso de pago bien comprendido no afronta la misma incertidumbre que otro que crea un servicio nuevo.

Protege el aprendizaje, no los rituales del proceso

En lugar de preguntar:

¿Hemos completado todas las etapas?

pregunta:

¿Qué incertidumbre podría causar el error más caro y cuál es la forma creíble más rápida de reducirla?

Si ya existe una investigación sólida, repetir la fase de descubrimiento puede aportar poco valor.

Si el problema está claro, pero el comportamiento del usuario es incierto, prioriza los prototipos.

Si los usuarios entienden el concepto, pero su implementación no es realista, adelanta el análisis de factibilidad.

El propósito del design thinking es aprender y decidir mejor, no cumplir perfectamente el proceso.

¿Cómo cambia la IA el design thinking y la creación de prototipos?

La IA reduce el coste de generar posibles soluciones, pero no elimina la necesidad de plantear el problema, aplicar criterio, priorizar y probar.

La IA acelera la exploración de soluciones

Los flujos profesionales revisados para este artículo utilizan IA para acelerar variaciones visuales, generación de prototipos, paneles de inspiración y recursos complementarios.

Las mejoras exactas de productividad varían demasiado según la tarea, herramienta y flujo como para tratar cifras individuales como referencias universales.

Lo relevante desde el punto de vista estratégico es la tendencia: crear otra opción visual resulta cada vez más barato y rápido.

Generar más rápido aumenta el valor de plantear bien el problema

Cuando los equipos pueden crear muchas direcciones rápidamente, la producción deja de ser siempre el principal cuello de botella.

Las preguntas más difíciles pasan a ser:

• ¿Qué problema del usuario importa?
• ¿Qué supuesto debería comprobarse primero?
• ¿Qué restricciones importan ahora?
• ¿Qué variación representa una alternativa significativa?
• ¿Qué hicieron realmente los usuarios?
• ¿Qué solución debería formar parte del producto o del sistema de diseño?

Generar más variaciones del concepto equivocado no crea más valor.

Para los equipos creativos que usan IA, el design thinking se convierte cada vez más en una forma de dirigir la experimentación con criterio.

¿Cuáles son los errores más comunes del design thinking?

En los casos y las preguntas revisados para este artículo se repiten cuatro errores.

Empezar con Figma antes de comprender el problema

Figma ayuda a expresar soluciones. No determina si una solución responde a la necesidad correcta.

Las pantallas creadas demasiado pronto pueden convertir supuestos en requisitos.

Crear prototipos demasiado pulidos

Una mayor fidelidad exige más inversión y a menudo genera más apego.

Empieza con la menor fidelidad que permita responder a la pregunta.

Confundir los entregables de investigación con el aprendizaje

Los perfiles de usuario, mapas de recorrido, presentaciones e informes pueden organizar evidencias, pero no son resultados por sí mismos.

La investigación debería acabar cambiando una decisión, prototipo, experimento o implementación.

Probar solo para validar una idea existente

Una buena prueba debe permitir descubrir que el equipo está equivocado.

Probar para confirmar produce acuerdo. Probar para reducir la incertidumbre produce aprendizaje.

Preguntas frecuentes

¿Design thinking es lo mismo que UX?

No. DT es una forma más amplia de resolver problemas, mientras que UX se centra en la experiencia con productos, servicios y sistemas. Los equipos UX suelen usar métodos de DT como investigación, planteamiento del problema, prototipos y pruebas, pero UX también incluye diseño de interacción, arquitectura de la información, usabilidad y trabajo de interfaz.

¿Cuánta investigación UX basta antes de crear prototipos?

No hay una duración universal. Los casos revisados abarcaron desde ciclos de investigación de 12 a más de 18 semanas sin prototipos hasta experiencias en las que cuatro a seis semanas bastaban para empezar a crear wireframes. Una regla más sólida es prototipar cuando la interacción pueda responder una pregunta importante de forma más directa que seguir discutiendo o investigando.

¿Todo proyecto UX necesita las cinco etapas de DT?

No. Las actividades pueden combinarse, repetirse, acortarse u omitirse según las evidencias existentes y el riesgo del proyecto. El objetivo no es completar cinco etapas, sino reducir las incertidumbres que podrían provocar errores costosos.

¿Sigue siendo relevante DT con la IA?

Sí, aunque su papel cambia. La IA puede acelerar la ideación, la generación visual, la creación de recursos y los prototipos. DT sigue siendo valioso para decidir qué problemas importan, qué supuestos comprobar y cómo las evidencias deben influir en la siguiente decisión de diseño.

Conclusión

El design thinking se entiende mejor como un sistema de aprendizaje centrado en las personas, no como un ritual de cinco pasos. IxDF, HBS y el marco de IDEO U revisado aquí usan estructuras distintas, pero comparten la misma lógica: comprender a las personas, aclarar el problema, explorar alternativas, hacer tangibles los supuestos, probarlos y aprender. Los casos reales también muestran por qué importa la flexibilidad: la investigación puede alargarse demasiado sin pruebas; los talleres pueden fracasar sin responsables ni implementación; y la IA acelera la generación de soluciones. Por tanto, el valor duradero del design thinking no reside en el marco en sí, sino en la disciplina de identificar el problema correcto, reducir la incertidumbre con evidencias y cambiar de dirección cuando la realidad contradice los supuestos del equipo.