El error más costoso de design thinking suele ocurrir antes de crear una sola idea: enamorarse de una solución antes de entender el problema.
En proyectos reales, entrevistar, observar, sintetizar, idear, prototipar y probar no son seis ceremonias separadas: forman un sistema para reducir incertidumbre. Esta ficha muestra cómo convertir ese sistema en una práctica de equipo y no en un taller aislado.
Objetivo didáctico
Al terminar esta ficha serás capaz de coordinar un proceso completo de design thinking, desde la investigación con usuarios hasta el testeo de prototipos, y convertir sus ciclos de aprendizaje en una práctica habitual de un equipo de trabajo.
Introducción
Design thinking resulta especialmente útil cuando un equipo sabe que existe un problema, pero todavía no comprende con suficiente precisión qué necesita la persona usuaria, por qué ocurre la fricción ni qué solución merece construirse. En ese escenario, comenzar por una lista de funcionalidades equivale a fabricar una llave antes de observar la cerradura.
El enfoque combina investigación cualitativa, síntesis, generación deliberada de alternativas, prototipos de baja inversión y experimentos con personas reales. Su valor no está en los post-its ni en una secuencia rígida de cinco pasos, sino en disminuir el costo de equivocarse antes de comprometer presupuesto, tecnología, operaciones o reputación.
💡 Design thinking
Proceso de resolución de problemas centrado en las personas que alterna comprensión del contexto, definición del reto, exploración de alternativas y aprendizaje mediante prototipos. Las etapas se pueden recorrer varias veces; no constituyen una línea de producción rígida.
En el nivel intermedio, el reto deja de ser “participar en una sesión creativa” y pasa a ser facilitar el proceso para otras personas: decidir a quién entrevistar, separar observaciones de interpretaciones, evitar que la jerarquía mate ideas, seleccionar qué prototipar y convertir resultados ambiguos en una siguiente decisión.
Un equipo mexicano que rediseña la experiencia de entrega de una cadena de farmacias, por ejemplo, no debería preguntar únicamente qué pantalla quieren los clientes. Necesita observar qué ocurre cuando una persona no está en casa, cómo se comunica el repartidor, qué información necesita la sucursal y qué excepciones generan llamadas. El problema real vive entre actores, no dentro de una interfaz.
Desarrollo del tema
Empatía profunda: escuchar lo dicho y observar lo que ocurre
Una entrevista de empatía no funciona como una encuesta oral. Su objetivo es reconstruir episodios concretos: “cuéntame la última vez que ocurrió”, “¿qué hiciste después?” o “¿qué era lo más difícil en ese momento?”. Una conversación de 30 a 45 minutos suele permitir profundizar más que veinte preguntas cerradas contestadas con rapidez.
La observación agrega una segunda capa. Las personas no siempre pueden explicar hábitos que realizan en automático, y a veces describen el proceso ideal en lugar del proceso real. Por eso conviene registrar acciones, objetos utilizados, atajos, esperas, interrupciones, conversaciones y contradicciones. Un mapa de empatía sintetiza posteriormente qué la persona dice, hace, piensa y siente.
En el trabajo real no hace falta una investigación etnográfica de meses para comenzar. Un equipo puede iniciar con 5 a 8 conversaciones diversas, tratándolas como exploración y no como una muestra estadística. La meta es detectar patrones, excepciones y nuevas preguntas; si cada entrevista agrega hallazgos radicalmente distintos, todavía falta explorar.
El criterio profesional es diferenciar evidencia e interpretación. “Esperó siete minutos antes de llamar” es una observación; “es impaciente” es una inferencia. Mantener esa distinción evita diseñar sobre prejuicios. En proyectos de servicio, esta disciplina puede revelar que un supuesto problema tecnológico es en realidad una falla de coordinación, información o confianza.
Síntesis: del caos de hallazgos a un reto útil
Después de entrevistar y observar, el equipo suele tener fotografías, citas, notas y contradicciones. El trabajo de síntesis consiste en agrupar evidencia por afinidad y buscar relaciones: comportamientos repetidos, tensiones, necesidades no satisfechas y circunstancias que cambian una decisión. Sintetizar no significa reducir todo a un promedio; también importan los casos extremos.
Una forma útil de redactar el punto de vista es combinar persona o segmento, necesidad e insight. “Personal de sucursal que atiende entregas necesita saber cuándo intervenir porque hoy descubre los problemas cuando el cliente ya está molesto” orienta mucho mejor que “debemos mejorar la logística”.
De ese punto de vista nace la pregunta “¿cómo podríamos…?”. Debe ser suficientemente específica para conservar el problema y suficientemente abierta para admitir varias respuestas. “¿Cómo podríamos avisar antes de que una entrega entre en riesgo?” abre rutas; “¿cómo podríamos poner un botón rojo en la app?” ya es una solución disfrazada de pregunta.
La historia moderna del enfoque conecta varias tradiciones. Herbert Simon escribió sobre el diseño como transformación de situaciones existentes en preferidas en 1969; décadas después IDEO y la d.school de Stanford ayudaron a popularizar procesos de diseño centrado en las personas. Esa evolución explica por qué design thinking es más una lógica de investigación y experimentación que un ritual de cinco cajas (Brown, 2008).
Ideación avanzada: cantidad primero, criterio después
La ideación pierde potencia cuando generación y evaluación ocurren simultáneamente. Una persona propone algo y otra responde “eso no se puede”, con lo que el equipo regresa de inmediato a opciones conocidas. La solución es separar deliberadamente una fase divergente —producir posibilidades— y una convergente —evaluarlas con criterios explícitos.
El reto de 100 ideas en 30 minutos debe entenderse como una restricción de facilitación, no como un umbral científico. En un equipo de cinco personas representa veinte aportaciones por integrante y obliga a superar las primeras respuestas previsibles. Se admiten combinaciones, exageraciones y propuestas aparentemente absurdas porque algunas contienen un principio útil.
🧩 Divergir, combinar o filtrar
Selecciona una acción y después la categoría que mejor describe su función dentro de una sesión de ideación.
La convergencia necesita criterios acordados antes de votar: impacto sobre el usuario, aprendizaje esperado, costo de probar y alineación con el reto. Una idea no necesita ser totalmente viable para avanzar; necesita ser suficientemente valiosa e incierta como para justificar un experimento.
En un equipo de seguros, por ejemplo, veinte variantes de una atención post-siniestro pueden agruparse en autoservicio, acompañamiento humano y prevención. El resultado útil de la ideación no es una pared llena de notas, sino dos o tres hipótesis contrastantes que el equipo pueda convertir rápidamente en experiencias observables.
Prototipado de servicios: hacer visible lo intangible
Un servicio no siempre cabe en una maqueta física. Para prototiparlo hay que representar momentos, actores, mensajes y decisiones. Un storyboard de 6 a 10 escenas permite mostrar la secuencia; un roleplay reproduce una interacción; y una maqueta puede simular formularios, señalización, mensajes o pantallas sin construir el sistema definitivo.
La pregunta no es “¿qué tan bonito se ve?”, sino “¿qué necesitamos aprender?”. Si la incertidumbre está en la reacción del cliente ante una nueva política de devolución, bastan un guion, un mostrador simulado y dos personas representando la conversación. Programar una aplicación completa agregaría costo sin aumentar el aprendizaje relevante.
Si mañana tuvieras que probar la idea sin desarrollar software ni pedir presupuesto adicional, ¿qué parte de la experiencia podrías representar con papel, personas y mensajes simulados?
El nivel de fidelidad debe corresponder a la pregunta. Un prototipo tosco invita a modificar; uno demasiado terminado puede provocar que participantes y directivos discutan colores y detalles en vez de cuestionar la propuesta central. En la primera vuelta conviene invertir horas, no semanas.
Para coordinar al equipo, resulta útil escribir junto al prototipo tres elementos: la hipótesis que representa, la conducta que se observará y la decisión que se tomará con los resultados. Así, storyboard, roleplay o maqueta dejan de ser materiales de presentación y se vuelven instrumentos de aprendizaje.
Ciclos rápidos de testeo: buscar evidencia, no aprobación
Probar un prototipo significa observar qué hace una persona cuando enfrenta una situación diseñada por el equipo. Preguntar “¿te gusta?” produce opiniones; pedir “muéstrame cómo resolverías esto” produce comportamiento. Un test de servicio puede completarse en 20 a 40 minutos por participante si se concentra en pocas hipótesis.
El facilitador debe evitar defender la idea. Cuando una persona se confunde, el impulso natural es explicar; sin embargo, esa confusión es precisamente evidencia. Conviene registrar citas, acciones, dudas, expectativas incumplidas y momentos de sorpresa, y separar posteriormente hallazgos repetidos de incidentes aislados.
Después de cada ronda conviene formular una decisión explícita: continuar, ajustar, cambiar de hipótesis o detener. Esta disciplina convierte la iteración en aprendizaje acumulativo. Sin decisión, el equipo puede pasar semanas “mejorando” una idea sin saber qué incertidumbre está reduciendo.
En un servicio de atención B2B, por ejemplo, descubrir que los clientes entienden el nuevo tablero pero continúan llamando porque desconfían del dato no es un fracaso de interfaz: revela un problema de credibilidad. La siguiente iteración debería probar señales de trazabilidad o responsabilidad, no agregar botones.
Integrar design thinking en el trabajo habitual del equipo
El mayor riesgo aparece cuando design thinking se reserva para un taller anual. La práctica se vuelve sostenible cuando algunas de sus rutinas entran al sistema normal de trabajo: escuchar usuarios, formular hipótesis, visualizar experiencias, reservar tiempo para alternativas y revisar evidencia antes de escalar.
Un equipo puede establecer un ritmo ligero: una sesión mensual con usuarios, una revisión quincenal de hipótesis y un bloque breve de prototipado antes de aprobar desarrollos costosos. Incluso 60 minutos por semana dedicados a investigar o experimentar pueden cambiar la conversación de “¿qué vamos a construir?” a “¿qué necesitamos aprender?”.
La integración también exige documentación mínima. Un repositorio con entrevistas, insights, hipótesis, experimentos y decisiones permite que el conocimiento no desaparezca cuando cambia una persona del proyecto. El objetivo no es crear burocracia; es conservar la cadena entre evidencia y decisión.
El indicador de madurez no es cuántas personas conocen el vocabulario de design thinking, sino cuántas decisiones importantes se toman después de observar usuarios y probar supuestos. Cuando investigación y experimentación forman parte del flujo normal, la innovación deja de depender de momentos excepcionales.
Conclusión
Aplicar design thinking con nivel intermedio significa coordinar una conversación disciplinada entre evidencia, creatividad y experimentación. Empatizar evita resolver el problema equivocado; sintetizar concentra el aprendizaje; idear amplía alternativas; prototipar reduce el costo de explorar; y probar convierte opiniones en observaciones.
El proceso alcanza su mayor valor cuando modifica el trabajo cotidiano. Un equipo que aprende a investigar antes de asumir, formular preguntas antes de comprar soluciones y experimentar antes de escalar no elimina la incertidumbre: desarrolla una forma más económica y rigurosa de trabajar con ella.
🔭 Para seguir aprendiendo
- ¿Cómo cambia el design thinking cuando quien usa un servicio no es quien lo compra ni quien lo opera?
- ¿Qué decisiones de tu equipo merecen investigación cualitativa y cuáles necesitan datos cuantitativos?
- ¿Qué parte de un proceso actual podrías prototipar esta semana sin solicitar presupuesto adicional?
Actividad de aprendizaje autónoma
Producto final: plan de ciclo design thinking de una página. Selecciona un problema real de tu equipo que todavía contenga incertidumbre sobre usuarios, causas o solución. El objetivo es diseñar un ciclo que pueda empezar en los próximos diez días, no un proyecto hipotético.
- Describe el problema sin incluir todavía la solución.
- Define qué tipo de usuario o actor necesitas observar o entrevistar y prepara cinco preguntas abiertas.
- Redacta un punto de vista y una pregunta “¿cómo podríamos…?”.
- Planifica una sesión breve de ideación y define dos criterios posteriores para seleccionar alternativas.
- Elige qué prototipo construirás y qué conducta observarás durante el test.
- Fija la fecha en la que el equipo decidirá continuar, modificar o abandonar la hipótesis.
Evidencia de logro: el plan identifica usuario, evidencia a buscar, reto, alternativas, prototipo, criterio de test y una decisión posterior. Otra persona del equipo debe poder ejecutarlo sin pedir una explicación adicional.
Reflexión final: ¿qué supuesto sobre el problema estabas tratando como un hecho antes de estructurar este ciclo?
Fuentes principales: Brown, T. (2008). Design thinking. Harvard Business Review, 86(6), 84–92. · IDEO.org. (2015). The Field Guide to Human-Centered Design. IDEO.org. · Knapp, J., Zeratsky, J., & Kowitz, B. (2016). Sprint. Simon & Schuster.