Itérer — traiter les étapes comme une boucle, pas une ligne

Revenez aux étapes précédentes quand le test révèle que vous avez cadré le mauvais problème.

Why it works

Les cinq étapes sont dessinées comme une séquence mais utilisées comme une boucle. Un résultat de test montre souvent que le vrai problème était mal cadré, vous renvoyant à Définir ou Empathie. Adopter la boucle empêche le verrouillage par coûts irrécupérables — le mécanisme consiste à garder la définition du problème révisable à la lumière des preuves.

How to do it

1. Après chaque test, demandez explicitement : cela a-t-il remis en question la solution, ou la définition du problème ?
2. Autorisez-vous à retourner à Empathie/Définir, pas seulement à ajuster le prototype.
3. Fixez une règle d'arrêt (assez bon pour la décision en cours) pour que l'itération ne devienne pas de l'évitement.

Données probantes

Mécanistique. Le développement itératif guidé par retour est bien étayé en général ; l'usage non linéaire spécifique des étapes du design thinking est un conseil de praticien issu d'IDEO et du d.school. Une étude contrôlée de Dow et collègues a trouvé qu'explorer plusieurs alternatives en parallèle, plutôt que de s'engager tôt sur une seule, produisait plus de divergence et de meilleurs résultats de conception — la même logique qui récompense le retour en boucle plutôt que le verrouillage. (mechanistic)

L'itération peut aussi devenir un moyen d'éviter de s'engager ; la discipline consiste à savoir quand s'arrêter, pas seulement quand boucler.

Sources

• 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.

Erreur fréquente

Traiter les étapes comme une liste de contrôle à sens unique et lancer le premier prototype parce que vous avez « terminé le processus », en ignorant les signaux de test indiquant que le problème lui-même était erroné.