En una reunión matutina reciente en un hospital regional, un médico adjunto sénior nos preguntó: "¿No está ya pasado de moda el design thinking?"
Una breve introducción. El design thinking es un ciclo de cinco etapas popularizado en los años 90 por IDEO: empathize (entender al usuario), define (delimitar el problema), ideate (generar soluciones), prototype (construir algo tosco) y test (ponerlo frente a usuarios). La premisa es simple: averiguar qué problema resuelves antes de construir, dejar que usuarios reales toquen una versión rudimentaria y revisar después la definición. Suena a sentido común, pero en la práctica la mayoría de los equipos nunca completan un solo ciclo entero.
Durante la última década se formó la impresión de que la metodología había envejecido mal. Los argumentos habituales:
- Es cosa de los 2010 — el mundo ya pasó al lean startup y a la generación directa con IA
- Se convirtió en una industria de talleres: muchos Post-its, ningún seguimiento
- Las grandes empresas lo volvieron ritual: un sprint de una semana y nada más
- Si los LLM pueden sintetizar soluciones a demanda, ¿para qué empatizar o hacer investigación de usuarios?
Nuestra lectura es distinta. Durante la última década, lo que hacía parecer obsoleto al design thinking era la velocidad, no la lógica. La IA ahora comprime las partes que solían frenar el ciclo —construcción de prototipo y síntesis de feedback— de meses a días. El ciclo completo puede correr de extremo a extremo por primera vez.
Este artículo recorre un pivote interno reciente: de una herramienta de cabecera monoespecialidad a un schema composer multiespecialidad de autoservicio. Todo el arco encaja limpiamente sobre un ciclo completo de design thinking, y lo usamos como ejemplo concreto de por qué la IA no reemplaza al design thinking, sino que es la herramienta que llevaba veinte años esperando.
Por qué se pensaba que estaba pasado de moda
El manifiesto de Tim Brown en Harvard Business Review en 2008 llevó la metodología al mainstream. Pero su verdadero cuello de botella nunca fue lógico. Era el tiempo.
Correr una iteración completa —de empathize a test, y de vuelta a redefinir— le tomaba a un equipo tradicional entre tres y seis meses:
- Empathize: agendar 5–15 entrevistas, transcribir, agrupar patrones
- Define / ideate: meter a todos los stakeholders en talleres de varios días, generar pilas de Post-its
- Prototype: diseñadores mockean pantallas; ingenieros construyen una versión jugable
- Test: otra ronda de sesiones con usuarios, recoger feedback
Cada paso era lento. Tanto, que cuando el equipo terminaba una ronda y veía la reacción real del usuario, ya no quedaba tiempo ni presupuesto para actuar.
Como consecuencia, en la última década pasaron tres cosas:
- Empathize y define se ritualizaron: un taller y listo
- Prototype y test se tercerizaron a agencias: entregables bonitos, lejos de producción
- Toda la metodología quedó comprimida en "sprints de dos días" — design thinking de nombre, pero sin el movimiento que la hacía significativa: pivotar de verdad
Ya entrados los 2020, el consenso había virado: el design thinking era "lo viejo". Lo nuevo era lean startup, growth hacking, producto data-driven.
El veredicto de "obsoleto" no fue solo charla de pasillo. La retrospectiva de 2023 de Rebecca Ackermann en MIT Technology Review consolidó el caso: ideas sin ejecución, teatro de la innovación, empatía sin pericia comunitaria. La profesora de NYU Natasha Iskander lo había dicho de forma más afilada cinco años antes en su pieza en HBR de 2018: "fundamentalmente conservador". Ambas críticas apuntan al fracaso del design thinking en problemas sociales y de política pública —comedor escolar, iniciativas contra la pobreza, servicios gubernamentales—, dominios que requieren trabajo político e institucional de largo plazo, no un ciclo de cinco etapas.
No discutimos con ese cuerpo de crítica. Hace fuerza. Nuestro artículo aborda una pregunta más estrecha: por qué el design thinking dejó de correr dentro de los flujos de producto.
Lo que la IA cambió de verdad
Cuando la IA entró en escena, la narrativa más ruidosa fue: "Ya no necesitamos investigación de usuarios — que los LLM sinteticen la solución directamente". Esa narrativa choca de frente con el design thinking, y es por eso que la gente pregunta si este último está pasado de moda.
Lo que vemos dentro de los equipos de producto se parece más a lo contrario. Los LLM no aceleran la etapa de empathize. Aceleran la construcción de prototipos y el procesamiento de feedback:
| Etapa | Antes de la IA | Con IA |
|---|---|---|
| Redacción del spec | 1–2 semanas (revisión multi-ronda con stakeholders) | 1–2 días (revisión multi-AI en paralelo) |
| Mock de UI | 1 semana (diseñador + herramientas) | Medio día (LLM + plugins de Figma) |
| Prototipo jugable | 2–4 semanas (ingeniería frontend + backend) | 3–5 días (mocked API + lógica de UI generada por IA) |
| Síntesis de feedback | 1 semana (clustering manual) | Medio día (extracción de temas con LLM + clustering) |
| Borradores de compliance / legales | 2–4 semanas (abogado + revisión interna) | 3–5 días (drafts de IA + revisión del abogado) |
Sumando: un ciclo único de design thinking que solía tomar entre 12 y 16 semanas (o más) ahora corre en 2 o 3 semanas (o menos).
El cuello de botella se movió. Lo que antes era lento —"construir algo que un usuario realmente pueda tocar"— ahora es rápido. Lo lento ahora es "decidir qué construir".
En otras palabras: la importancia relativa de las etapas de empathize / define no bajó. Subió.
El verdadero cambio
Los LLM son amplificadores. Si encuadras mal el problema, van a producir cosas que nadie quiere — con una eficiencia sin precedentes. Si lo encuadras bien, multiplicarán por diez la dirección correcta.
Lo cual significa que el movimiento más clásico del design thinking —"preguntar primero por qué"— no solo sigue siendo relevante en la era de la IA. Es la barrera de protección.
Antes empathize era lento, así que los equipos sentían la tentación de saltárselo. Hoy prototype es rápido, así que saltarse empathize es más peligroso, no menos: te vas a meter por el camino equivocado con muchísima eficiencia antes de darte cuenta.
Nuestra regla interna: sin spec firmado, no empieza el trabajo. Cuanto más rápida se vuelve la IA, más crítico es el paso de la firma. Corremos tres revisores AI (Codex, Gemini, ChatGPT) en paralelo contra cada spec — detectan violaciones de contrato, IDOR, problemas con PHI, incompatibilidades cross-version que los talleres tradicionales de design thinking nunca cubren. En la era de la IA, esas preocupaciones tienen que estar al lado de "qué quiere el usuario" como parte de empathize / define, no después.
"Spec primero" no es anti-design-thinking. Es design thinking adaptado a la era de la IA.
Caso: del overflow de SOAP.S a un composer multiespecialidad
El arco no empezó con estudio de mercado ni focus group. Empezó con una conversación con un médico sénior. Describió lo que su equipo venía observando: su patient copilot dejaba a los pacientes ingresar las quejas principales antes de la visita, pero el texto generado por el LLM desbordaba rutinariamente la sección Subjective del SOAP. El tiempo que el médico solía dedicar al razonamiento clínico ahora se iba en limpiar lo que escribía la IA.
El primer instinto fue agregar un compilador para comprimir el input del paciente en algo utilizable. El equipo no hizo eso. Sentándonos con el problema, quedó claro que no faltaba una capa de compresión; había que reordenar todo el flujo de valor. Así que recorrimos las cinco etapas del design thinking. De la conversación a la decisión de pivotar: unas dos semanas. El mismo trabajo antes de la IA: de seis a nueve meses.
Empathize
El equipo incluye un fundador que también es cirujano ortopédico en ejercicio. Desde su perspectiva, la pregunta de design thinking más clásica:
"En cada visita de consulta, ¿cómo traduzco yo personalmente las quejas sueltas de un paciente al contenido de SOAP.S?"
La respuesta no es "anotarlo todo". Es "comprimir en cuatro campos más el razonamiento detrás de cada uno": qué lado, gravedad, traumático o degenerativo, duración. Una vez llenos esos cuatro, el árbol de hipótesis del diagnóstico diferencial se arma solo.
En otras palabras: el SOAP.S que escribe un médico nunca es una transcripción de la narrativa del paciente. Es la interpretación estructurada que el médico hace de ella. El overflow de SOAP.S no lo causan pacientes que escriben demasiado — lo causan herramientas diseñadas para volcar la salida de la IA directamente en la historia clínica, en vez de comprimirla para que el médico la revise primero.
(Hemos escrito una versión más profunda de la regla de diseño "la IA hace borradores, el médico confirma" en iRehab Doctor AI: Draft-Only Enforcement — la traducción por IA y la confirmación del médico son dos acciones que no se pueden fusionar.)
Define
Replanteamos el problema:
"En los dos minutos antes de que el paciente entre en la sala, comprimir las dos semanas previas de inputs del paciente —tendencias de VAS, fotos de heridas, registros de ejercicio, scores PROM— en un resumen relevante para la especialidad que el médico lea en cinco segundos."
Las palabras clave son "comprimir" y "leíble en cinco segundos". Si manteníamos la lógica de "transcripción al EMR", ningún nivel de precisión de la IA detendría el overflow. Este paso de define se acotó deliberadamente: solo ortopedia, solo este recorte, nada más.
Ideate
Todo enfoque previo asumía que la acción ocurría dentro de la sala de consulta: médico sentado, paciente enfrente, EMR abierto, tipeando mientras escucha.
Nuestro movimiento clave de ideate fue reubicar todo el paso de traducción fuera de la sala. El paciente llena los inputs fuera de la visita (en casa, en el celular, durante las dos semanas previas). La IA comprime dos minutos antes de la visita. El médico lo lee en cinco segundos antes de entrar.
Esto no es una mejora de herramienta. Es una reubicación del flujo de trabajo. (El input del lado del paciente que alimenta a Brief es el check-in diario de 30 segundos sobre el que hemos escrito — 30 segundos por día, pero dos semanas de acumulación son la materia prima del resumen pre-visita.)
Prototype
Unos días de redacción de spec, revisión multi-AI y construcción de prototipo después: salió iRehab Brief Wave 1, solo ortopedia. Esto solía tomar de cuatro a ocho semanas, a menudo más. La IA comprimió la redacción del spec, el mocking de UI, el scaffolding de la API backend, la revisión del modelo de datos y los documentos de compliance.
Test
Cuando Brief entró en su piloto intrahospitalario, pasaron dos cosas inesperadas.
Primero, el rollout físico se bloqueó en una sede. No por razones de código. La política del hospital exigía aprobación del departamento de PR para cualquier póster con código QR; el jefe de cirugía lo encuadró como "otro médico más promocionando una página de Facebook". La cobertura del code review y la gobernanza institucional son dos mundos distintos.
Segundo, la reacción en FB volvió más caliente de lo esperado. Mensajes directos de médicos en psiquiatría, neurología, uroginecología y obstetricia, todos preguntando lo mismo: "¿Pueden construir uno para mi especialidad?".
Las dos corrientes de feedback convergían en un único mensaje: el problema que originalmente definimos es un recorte de un problema mayor.
Redefine
Cada especialidad necesita un traductor, pero los cuatro campos a los que cada una traduce son completamente distintos:
- Psiquiatría necesita sueño, oscilaciones del estado de ánimo, adherencia a la medicación
- Uroginecología necesita diario miccional, completitud de Kegel
- Neurología necesita variabilidad de síntomas, efectos secundarios, frecuencia de episodios
- Obstetricia necesita molestias relacionadas con el embarazo, movimiento fetal, alertas específicas por trimestre
Misma arquitectura. Cuatro schemas completamente diferentes.
Si seguíamos empujando el Brief de ortopedia, probablemente lo habríamos desplegado sin sobresaltos a un puñado de ortopedistas. Y habríamos perdido el insight real: el valor de esta herramienta no es "ahorrarles tiempo a los ortopedistas". Es "permitir que cualquier médico defina sus propias reglas de traducción en unos minutos".
Pausamos el rollout del Brief de ortopedia. Abrimos un nuevo spec: un Schema Composer multiespecialidad que permite a cualquier especialista definir sus propios cuatro campos, firmar la attestation y publicar su propio specialty pack.
Esa decisión de redefinición es la salida real de la quinta etapa del design thinking: no "el prototipo funciona", sino "el encuadre original del problema era demasiado pequeño".
Dos multiplicadores con IA
Mirando hacia atrás esas dos semanas, la IA aceleró el trabajo en dos lugares específicos:
Primer multiplicador: tiempo de spec → prototipo. Escribir un spec listo para firma, construir un prototipo jugable y correr la revisión interna solía tomar de cuatro a ocho semanas. Nuestro equipo ahora comprime eso a 7–10 días. Los LLM redactan el spec; tres revisores AI corren en paralelo; un arquitecto humano reconcilia. El prototipo arranca con mocked APIs y stubs de UI generados por IA; los ingenieros llenan la lógica de negocio.
Segundo multiplicador: tiempo de feedback → redefinir. Pasar de "piloto en vivo" a "deberíamos pivotar" solía requerir entre tres y seis meses de datos de uso, varias rondas de entrevistas y síntesis. Nuestro ciclo ahora corre así: FB una semana, DMs tres días, discusión interna un día. Cinco días desde la señal externa hasta un nuevo spec que captura "el encuadre original era un sub-problema".
Juntos, los dos multiplicadores comprimen un ciclo completo de design thinking —pensar, spec, prototipar, feedback, redefinir— de 6–9 meses a unas 2 semanas. Esto no es el design thinking siendo reemplazado. Es el design thinking corriendo de extremo a extremo por primera vez.
Qué es realmente el design thinking
El design thinking no son talleres. Ni Post-its. Ni mapas de empatía.
Su núcleo son dos voluntades:
- La voluntad de admitir que tu primera respuesta está equivocada.
- La voluntad de testear rápido y encontrar la correcta.
Durante la última década, ambas han sido difíciles de honrar. La primera la bloqueaba el sunk cost ("le metimos tres meses a este spec, ¿cómo vamos a admitir que está mal?"). La segunda la bloqueaba el tiempo ("correr otro ciclo lleva seis meses").
La IA cambió la segunda. La iteración rápida por fin es barata. Eso es lo que vuelve significativa por primera vez la primera voluntad: admitir que estabas equivocado ahora significa que puedes probar otra cosa de inmediato.
Por eso nuestro equipo trata "spec primero", "preguntar por qué" y "¿qué puerta abrió esto?" como disciplina interna. La IA es solo la herramienta. La disciplina es la metodología que se sienta encima — y esa metodología tiene un nombre. Se llama design thinking.
No estamos solos
Si solo se considera el caso de un equipo, el argumento suena a anécdota. Las creadoras originales de la metodología vienen dando una señal más directa.
Desde 2024, IDEO ofrece un curso online titulado, sin rodeos, Bring AI to the Design Thinking Process. El currículum enseña aceleración con IA a lo largo de cinco fases:
- Inspiración / Investigación: ampliar el input creativo con IA
- Síntesis: "acelerar la investigación y la síntesis, obtener insights más rápido"
- Brainstorming: idear más rápido, explorar más opciones
- Prototipado: dar vida a los conceptos rápidamente
- Uso responsable: entender los límites y la ética de la IA
Si mapeas esas fases sobre la tabla de aceleración con IA mostrada antes, las cinco se alinean casi una a una.
Las popularizadoras originales del design thinking no tratan a la IA como rival. Están onboardeando a su propia comunidad a la versión de próxima generación. Nótese la quinta fase —uso responsable—, que hace eco de nuestro argumento: a medida que la IA se vuelve más rápida, "preguntar primero por qué" se convierte en la barrera de protección.
El design thinking no está pasado de moda. Sus creadoras lo están cableando a la IA con sus propias manos.
Cierre
Volviendo a la pregunta del médico adjunto sénior: "¿No está pasado de moda el design thinking?".
Nuestra respuesta: no lo está. Durante la última década pareció obsoleto porque el ciclo de iteración era demasiado largo. La IA no es su rival — la IA es la herramienta que llevaba veinte años esperando.
Las dos semanas durante las cuales iRehab Brief pasó de un piloto de una sola especialidad a un composer multiespecialidad fueron la primera vez que nuestro equipo vio al design thinking correr realmente de extremo a extremo. No creemos que sea la última.
Lecturas adicionales
- Brown, T. (2008). Design Thinking. Harvard Business Review. — El manifiesto original.
- IDEO U. Bring AI to the Design Thinking Process. — El curso on-demand de IDEO desde 2024 que enseña aceleración con IA a lo largo de las cinco fases.
- Ackermann, R. (2023, feb). Design thinking was supposed to fix the world. Where did it go wrong? MIT Technology Review. — La retrospectiva que definió la narrativa del "obsoleto" de la última década.
- Iskander, N. (2018, sep). Design Thinking Is Fundamentally Conservative and Preserves the Status Quo. Harvard Business Review. — La crítica académica afilada más temprana.
- Mayer, J. et al. (2025). The impact of design thinking and its underlying theoretical mechanisms: A review of the literature. Creativity and Innovation Management. — La síntesis académica de 2025.
- U.S. FDA (ene 2025). Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations (Draft Guidance). — Anclaje regulatorio para la disciplina del ciclo de vida del software clínico de IA.
Desde el blog de De Novo
- iRehab Doctor AI: Draft-Only Enforcement — La pieza hermana sobre la regla de diseño de Brief: la IA traduce, el médico confirma; las dos acciones no se pueden fusionar.
- Check-in diario de 30 segundos — El flujo de input del lado del paciente que alimenta a Brief: 30 segundos por día, dos semanas de acumulación se convierten en la materia prima del resumen pre-visita.
- Recovery Loop — La metodología clínica más amplia dentro de la cual se publican las funciones de iRehab.