El Design Thinking es un método de resolución de problemas centrado en el usuario que alterna fases divergentes —donde se exploran múltiples caminos posibles— y fases convergentes —donde se eligen y validan las mejores soluciones. Nació en las escuelas de diseño americanas en los años 60 y fue codificado por IDEO y la d.school de Stanford en la década siguiente. Hoy es el framework más utilizado en el mundo para diseñar productos digitales que la gente realmente quiera usar.
Esta guía está pensada para quienes diseñan interfaces, productos y servicios digitales. No te contará la historia académica del método; para eso ya está Wikipedia. En su lugar, te mostrará cómo aplicar las 5 fases del Design Thinking a un proyecto de UX real, con ejemplos concretos, herramientas para Figma y —algo poco común— también los casos en los que usarlo es una pérdida de tiempo.
Qué aprenderás con esta guía:
- Qué es realmente el Design Thinking (una definición operativa, no académica)
- Las 5 fases del modelo de la d.school de Stanford aplicadas a proyectos digitales
- Las herramientas y plantillas que usarás en cada fase
- Un ejemplo de principio a fin de Design Thinking aplicado a una funcionalidad real
- La diferencia entre Design Thinking y Double Diamond (y cuándo elegir cada uno)
- Cuándo no sirve el Design Thinking y qué usar en su lugar
Qué es el Design Thinking
El Design Thinking es un enfoque iterativo para la solución de problemas complejos que parte de las necesidades reales de los usuarios, genera muchas ideas alternativas, prototipa las mejores y las valida con personas reales antes de construirlas. En una frase: primero entiendes, luego planteas hipótesis, luego pruebas y finalmente decides.
Tres características lo distinguen de otros métodos de diseño:
- Centrado en el usuario. Cada decisión se deriva de lo que has observado o escuchado de personas reales, no de opiniones internas del equipo.
- Iteración rápida. No se diseña una sola vez: se realizan muchos ciclos cortos de prototipo → test → revisión, cada uno más preciso que el anterior.
- Equilibrio entre deseabilidad, viabilidad y sostenibilidad. Una solución válida en Design Thinking debe ser deseada por los usuarios, realizable técnicamente y sostenible económicamente. Si falta una de estas tres, no es una solución.
El método nació para proyectos físicos (sillas, instrumentos médicos, interiores de oficinas), pero se ha convertido en el estándar para productos digitales porque resuelve un problema típico de las startups y los equipos de producto: escribir código para algo que todavía no existe en la mente de los usuarios es la fuente de desperdicio más cara en el desarrollo de software.
Quién lo inventó (y por qué te interesa)
Las raíces del Design Thinking se remontan a los trabajos de Herbert Simon ("The Sciences of the Artificial", 1969) y de L. Bruce Archer en el Royal College of Art de Londres en los años 60. La versión moderna —la de 5 fases que ves en todos los cursos— fue formalizada a finales de los 90 por la d.school de Stanford y popularizada por IDEO bajo la dirección de Tim Brown y David Kelley.
Saber de dónde viene no es por nostalgia: te sirve para reconocer variantes y adaptaciones. Algunas empresas usan 4 fases, otras 6, y otras el Double Diamond del British Design Council. Todas provienen del mismo tronco. Conoce el modelo base y podrás entender las demás como si fueran dialectos.
Las 5 fases del Design Thinking
El modelo de la d.school de Stanford es el más extendido y el punto de partida ideal. Consta de cinco fases, que no son estrictamente secuenciales: se puede retroceder siempre que sea necesario.
Fase 1 — Empatiza (Empathize)
Objetivo: entender cómo viven las personas el problema, con sus propias palabras y en su contexto.
Esta es la fase en la que no diseñas nada. Sales de la oficina (incluso metafóricamente, en remoto también vale), hablas con los usuarios, los observas mientras usan productos similares y recopilas datos cuantitativos y cualitativos que iluminarán el problema desde diferentes ángulos. El error más común del Design Thinking en los equipos, tanto en España como en LATAM, es saltarse esta fase porque parece "lenta". Luego se encuentran desarrollando funcionalidades que nadie quería.
Actividades típicas:
- Entrevistas semiestructuradas con 5-8 usuarios objetivo (suficientes para que emerjan los patrones principales).
- Shadowing: observar a los usuarios mientras realizan la tarea en contextos reales.
- Análisis de investigaciones existentes (tickets de soporte, reseñas, chats, analíticas).
- Mapa de empatía (Empathy Map): una plantilla visual que resume lo que piensan, dicen, hacen y sienten los usuarios entrevistados.
Entregables típicos: notas de investigación, grabaciones, apuntes de shadowing, mapas de empatía sintéticos.
Para profundizar en los métodos de recopilación de datos, lee nuestra guía de user research.
Fase 2 — Define (Define)
Objetivo: transformar lo que has observado en un problema preciso y accionable.
Después de la fase de empatía, tendrás docenas de insights en bruto. El siguiente paso es sintetizarlos en una frase corta que cualquiera en el equipo pueda usar como guía. Esta frase se llama Punto de Vista (Point of View o POV) o Declaración del Problema (Problem Statement), y a menudo sigue esta estructura:
[Tipo de usuario] necesita [necesidad concreta] porque [insight extraído de la investigación].
Ejemplo: "Una consultora freelance que factura a 15 clientes al mes necesita saber en 30 segundos quién le debe dinero, porque cada mañana tiene que decidir a quién reclamar el pago sin parecer agresiva."
Una frase así es tan potente como breve: elimina el 80% de las discusiones internas porque todos entienden cuál es el problema a resolver y cuál no.
Actividades típicas:
- Mapa de afinidad (Affinity Mapping): agrupar insights similares en un tablero de FigJam.
- How Might We: reformular el problema en preguntas abiertas ("¿Cómo podríamos reducir el tiempo de reclamación de pagos sin empeorar la relación con el cliente?").
- Persona: crear 1-2 arquetipos de usuario que representen las necesidades principales identificadas.
Fase 3 — Idea (Ideate)
Objetivo: generar la mayor cantidad de ideas posible para resolver el problema definido, sin juzgarlas todavía.
Esta es la fase divergente. Se aplica la regla clásica del brainstorming de IDEO: cantidad antes que calidad, sin críticas. Todas las ideas son válidas hasta que se haya generado una masa crítica. Solo después se filtran.
El error más común es que solo participen diseñadores. El Design Thinking funciona mejor con un grupo mixto de 4-6 personas: un diseñador, un desarrollador, un product manager, un representante de atención al cliente y, posiblemente, un stakeholder de negocio. Cada persona aporta una perspectiva diferente del problema y contribuye con ideas que un diseñador por sí solo no generaría.
Actividades típicas:
- Crazy 8s: en 8 minutos, cada persona dibuja 8 bocetos rápidos de posibles soluciones (un minuto por boceto).
- La peor idea posible (Worst Possible Idea): generar ideas deliberadamente malas para desbloquear la creatividad.
- SCAMPER, mapas mentales (mind mapping) y storyboarding para variar el enfoque.
Entregables: una pared de post-its, bocetos, flujos, mapas mentales, que se filtrarán en la siguiente fase con criterios claros (impacto, esfuerzo, alineación con el POV).
Fase 4 — Prototipa (Prototype)
Objetivo: construir versiones tangibles y de bajo coste de las mejores ideas, lo suficiente para poder testearlas.
Un prototipo en Design Thinking no es el producto final. Es solo lo mínimo necesario para que alguien pueda usarlo y ver qué sucede. El error más costoso es prototipar en exceso: un prototipo que requiere 3 semanas de Figma no es un prototipo, es un proyecto. Si descubres que la idea no funciona, habrás quemado 120 horas.
Los prototipos se dividen a grandes rasgos en tres niveles de fidelidad:
- Baja fidelidad (bocetos, wireframes en papel): 30 minutos. Ideales para probar el flujo y la prioridad del contenido sin que la gente se distraiga con la estética.
- Media fidelidad (wireframes interactivos en Figma): 2-4 horas. Buenos para probar la navegación y la nomenclatura.
- Alta fidelidad (prototipo visual clicable): 1-3 días. Necesarios solo cuando estás probando detalles de la interfaz, tono de voz o microinteracciones.
Para una guía práctica sobre wireframes de baja y media fidelidad, lee nuestra guía sobre el wireframe.
Fase 5 — Testea (Test)
Objetivo: poner los prototipos delante de usuarios reales y aprender de sus reacciones, no convencerles de que tienes razón.
El test de usabilidad es la herramienta principal de esta fase. Se eligen 5 usuarios (el número mágico confirmado por Jakob Nielsen), se les dan 3-5 tareas para realizar en el prototipo, se observa en silencio lo que sucede y se toman notas de los puntos de fricción.
Hay dos grandes patrones que buscas:
- ¿Dónde se atascan? Una pausa de más de 3 segundos frente a una pantalla casi siempre es una señal de que falta información o de que un elemento no está claro.
- ¿Qué dicen con sus propias palabras? Cuando un usuario describe una funcionalidad usando términos diferentes a los tuyos, tienes un problema de naming. Es un dato muy valioso.
El test no es el final del ciclo, es el comienzo de la siguiente vuelta. Después de cada test, vuelves a Empatizar (con nuevas preguntas más precisas), a Definir (para reformular el problema), a Idear (para generar variantes de las soluciones más prometedoras) o a Prototipar (para refinar lo que ya tienes). Es normal realizar cinco iteraciones antes de llegar a un diseño que realmente funcione.
Un ejemplo real de principio a fin
Ejemplo simplificado pero realista. Equipo: una scale-up española que ha lanzado una app para autónomos con gestión de facturas y pagos. Métrica por debajo del objetivo: el 40% de los usuarios no completa su primera factura en los 7 días posteriores al registro.
Empatiza. El diseñador entrevista a 6 autónomos recién registrados. Hace shadowing a 2 de ellos mientras intentan emitir su primera factura. Analiza 50 tickets de soporte de los primeros 7 días. Insight emergente: el campo "Tipo de IVA" intimida a quienes nunca han facturado antes; 4 de 6 usuarios lo omiten, 2 cierran la app porque no saben qué poner.
Define. POV: "Un autónomo en su primer año de actividad necesita saber qué tipo de IVA aplicar a su servicio, porque no tiene un gestor que le asesore y la duda lo bloquea al inicio del proceso."
Idea. El equipo genera 15 soluciones en un taller de 45 minutos. Se filtran a 3 finalistas: (a) un botón "No lo sé, ayúdame" que muestra una guía interna; (b) un selector pre-rellenado con el tipo de IVA más común para la categoría de servicio elegida en el onboarding; (c) un enlace discreto a un asesor externo.
Prototipa. Se construyen las tres variantes en Figma como mockups de alta fidelidad. Cada variante solo incluye las 2 pantallas relevantes; 90 minutos de trabajo en total.
Testea. 5 nuevos usuarios dados de alta como autónomos hace menos de 12 meses prueban las tres variantes en orden aleatorio. Resultados: la variante (b) —selector pre-rellenado— es la más rápida (37 segundos frente a 2 minutos de las otras) y la única con una tasa de finalización del 100%. La (a) confunde (los usuarios se preguntan "si hay una guía, ¿por qué no me la muestran directamente?"), la (c) se percibe como un servicio de pago.
Decisión: implementar la (b) con un valor por defecto inteligente basado en la categoría del servicio. Ahora la métrica objetivo se ha fijado en un 80% de finalización de la primera factura en 7 días.
Ningún redactor, ninguna intuición de un product manager, ningún brainstorming abstracto habría llegado a esa solución. La produjo el método, aplicado con rigor en 6 días de trabajo.
Design Thinking vs. Double Diamond
El Double Diamond es una variante británica del Design Thinking, codificada por el Design Council en 2005. Comparten el mismo espíritu (alternancia entre divergencia y convergencia) pero organizan las fases de manera ligeramente diferente.
| Design Thinking (Stanford) | Double Diamond (Design Council) |
|---|---|
| 5 fases: Empatiza, Define, Idea, Prototipa, Testea | 4 fases: Descubre, Define, Desarrolla, Entrega |
| Énfasis en la iteración rápida | Énfasis en la separación entre "el problema correcto" y "la solución correcta" |
| Más adecuado para proyectos digitales ágiles | Más adecuado para proyectos de servicio público e innovación estratégica |
Un diseñador UX se encontrará con ambos en su carrera. En un equipo lean con sprints de 2 semanas, el Design Thinking clásico funciona mejor. En un proyecto de seis meses con muchos stakeholders, el Double Diamond puede ser más adecuado. Aprende ambos y usa el que requiera el contexto.
Cuándo NO usar el Design Thinking
Ningún método es universal. El Design Thinking es un desperdicio en al menos tres situaciones:
- Problemas ya resueltos. Si estás construyendo otra página de login, el Design Thinking es excesivo. Copia los patrones estándar (como los descritos en nuestro artículo sobre UX para login) y ahorra las horas de investigación para problemas que sí lo merecen.
- Requisitos regulatorios estrictos. Si el producto debe cumplir con normativas precisas (privacidad, finanzas, sanidad), la creatividad tiene poco espacio: se necesita conocer las reglas, no idear soluciones alternativas.
- Tiempos muy ajustados con una solución obvia. En ciertos momentos de la vida de un producto —un bug grave, una funcionalidad solicitada por el cliente principal— la solución es clara y debe implementarse de inmediato. En esos casos, el Design Thinking ralentiza sin añadir valor.
La señal de que necesitas Design Thinking es una sola: el problema es complejo, los usuarios son desconocidos o poco comprendidos, y ninguna solución evidente funciona. En esos momentos, es el único método que te evita construir perfectamente la solución equivocada.
Herramientas útiles para cada fase
No se necesitan herramientas sofisticadas, pero tener una de confianza para cada fase hace que el flujo sea más fluido:
- Empatiza: Dovetail o Notion para archivar notas de investigación, Zoom para entrevistas remotas, Miro/FigJam para mapas de empatía.
- Define: FigJam para mapas de afinidad y tableros de POV, Coda para archivos compartidos de personas.
- Idea: FigJam (plantilla de Crazy 8s), Mural, una pizarra física si estás en persona.
- Prototipa: Figma es el estándar absoluto para cualquier nivel de fidelidad.
- Testea: Maze para tests no moderados, Lookback o Zoom para tests moderados, Otter.ai para transcripciones automáticas.
Preguntas frecuentes
¿Cuál es la diferencia entre Design Thinking y Diseño UX?
El Design Thinking es un framework de resolución de problemas aplicable a cualquier disciplina (producto físico, servicio, organización). El Diseño UX es la disciplina específica que diseña experiencias de uso para productos digitales. Un buen diseñador UX utiliza el Design Thinking como método, pero el Design Thinking por sí solo no es suficiente para hacer UX; también se necesitan conocimientos técnicos de diseño de interacción, diseño visual, accesibilidad, investigación cuantitativa y métricas de producto.
¿Cuánto dura un ciclo de Design Thinking?
Depende de la escala del problema. Un ciclo rápido sobre una única funcionalidad puede durar de 5 a 10 días laborables. Un Design Sprint al estilo de Google Ventures comprime todo el proceso en 5 días. Un proyecto grande puede requerir de 6 a 8 semanas para completar todas las fases con rigor. El principio clave es: mejor 3 ciclos de 10 días que 1 ciclo de 30 días, porque la iteración rápida es la fuente del valor.
¿Necesito ser diseñador para usarlo?
No. El Design Thinking nació como un método multidisciplinar precisamente para fomentar la colaboración entre personas con diferentes perfiles. Product managers, desarrolladores, consultores, profesores, médicos: todos pueden aplicarlo. Un diseñador UX tiene la ventaja de saber cómo facilitarlo mejor gracias a su práctica con wireframes, prototipos y tests de usabilidad, pero la metodología en sí es transversal.
¿Son compatibles el Design Thinking y la metodología Agile?
Sí, y se usan juntos en la mayoría de las empresas modernas. El Design Thinking cubre la fase de descubrimiento (entender qué construir), mientras que Agile cubre la fase de entrega (construirlo de forma iterativa). Muchos equipos los alternan: un sprint de descubrimiento con Design Thinking para definir nuevas funcionalidades, seguido de sprints de desarrollo Agile, y luego de nuevo descubrimiento. Para profundizar, lee nuestro artículo sobre UX Design en entornos Agile.
¿Cuál es el mejor libro para empezar?
"Change by Design" de Tim Brown (CEO de IDEO) es el manifiesto del método y se lee en un fin de semana. Para una aplicación más práctica al software digital, "The Design of Everyday Things" de Don Norman es un clásico atemporal. Encuentras ambos en nuestra selección de libros de Diseño UX por nivel.
Próximos pasos
Si quieres aplicar el Design Thinking en tu próximo proyecto digital, la forma más eficaz es aprender haciéndolo con un mentor que te corrija. El curso completo de Diseño UX de CorsoUX dedica más de 30 horas de lecciones prácticas al Design Thinking aplicado: mapas de empatía reales, POVs reescritos docenas de veces, talleres de ideación con el equipo del curso, prototipos en Figma construidos desde cero y testeados con usuarios reales. Al final, sales con 2-3 casos de estudio para tu portfolio que siguen esta metodología al pie de la letra.
Mientras tanto, puedes empezar con estas tres lecturas gratuitas para sentar las bases:
- Las 10 heurísticas de Nielsen — el lenguaje común de la profesión.
- La guía de user research — cómo realizar las entrevistas de la fase de Empatía.
- Cómo hacer wireframes eficaces — la habilidad central de la fase de Prototipado.
