Iterar — tratar las etapas como un ciclo, no una línea

Vuelve a etapas anteriores cuando probar revele que enmarcaste el problema equivocado.

Why it works

Las cinco etapas se dibujan como una secuencia pero se usan como un ciclo. Un resultado de prueba a menudo muestra que el problema real estaba mal enmarcado, enviándote de vuelta a Definir o Empatizar. Abrazar el ciclo evita el bloqueo por costos hundidos — el mecanismo es mantener revisable la definición del problema a la luz de la evidencia.

How to do it

1. Después de cada prueba, pregunta explícitamente: ¿esto cuestionó la solución, o la definición del problema?
2. Permítete volver a Empatizar/Definir, no solo a ajustar el prototipo.
3. Fija una regla de parada (suficientemente bueno para la decisión en cuestión) para que iterar no se convierta en evasión.

Evidencia

Mecanicista. El desarrollo iterativo impulsado por retroalimentación está bien respaldado en general; el uso no lineal específico de las etapas de design thinking es orientación de la práctica de IDEO y la d.school. Un estudio controlado de Dow y colegas encontró que explorar varias alternativas en paralelo, en lugar de comprometerse temprano con una, produjo más divergencia y resultados de diseño más sólidos — la misma lógica que recompensa volver atrás en lugar de encerrarse. (mechanistic)

Iterar también puede convertirse en una forma de evitar comprometerse; la disciplina está en saber cuándo parar, no solo cuándo volver.

Fuentes

• Dow, S. P., Glassco, A., Kass, J., Schwarz, M., Schwartz, D. L., & Klemmer, S. R. (2010). Parallel Prototyping Leads to Better Design Results, More Divergence, and Increased Self-Efficacy. ACM Transactions on Computer-Human Interaction, 17(4), Article 18.

Error común

Tratar las etapas como una lista de verificación de un solo sentido y lanzar el primer prototipo porque "terminaste el proceso", ignorando señales de prueba de que el problema en sí estaba equivocado.