Le design thinking suit un processus en cinq phases: empathie, définition, idéation, prototypage et test. Popularisé par la d.school de Stanford dans les années 2000, ce modèle structure une démarche de résolution de problèmes centrée sur l’utilisateur. Derrière l’apparente simplicité du schéma se cache une logique exigeante, où chaque phase produit un livrable distinct et où les retours en arrière ne sont pas des échecs mais des raffinements.
Comprendre avant de résoudre: la phase d’empathie
La première phase consiste à observer les personnes concernées par le problème dans leur environnement réel. Il ne s’agit pas d’envoyer un questionnaire ni d’organiser un focus group, mais d’aller sur le terrain: suivre un opérateur pendant une journée, accompagner un client dans son parcours, observer comment une équipe utilise réellement un outil qu’on pense connaître.
L’empathie au sens du design thinking va au-delà de la simple écoute. Elle implique de suspendre ses hypothèses et d’accepter que le problème perçu par les décideurs ne corresponde pas nécessairement au problème vécu par les utilisateurs. La d.school de Stanford insiste sur cette distinction: un problème bien observé est un problème à moitié résolu, tandis qu’un problème mal cadré conduit inévitablement à une solution inadaptée.
L’erreur la plus fréquente à ce stade est de considérer cette phase comme un simple recueil de besoins. L’empathie ne cherche pas à confirmer ce qu’on sait déjà, elle vise à découvrir ce qu’on ignore.
Formuler le bon problème
La phase de définition transforme les observations en un énoncé de problème exploitable. C’est un exercice de synthèse qui exige de la rigueur: parmi tout ce qu’on a observé, quel est le problème central que le projet doit résoudre?
La technique la plus utilisée est la formulation “How Might We” (comment pourrions-nous): “Comment pourrions-nous réduire le temps d’attente perçu par les patients?” plutôt que “Comment pourrions-nous optimiser le flux d’accueil?”. La première formulation reste ouverte et centrée sur l’expérience utilisateur, la seconde oriente déjà vers une catégorie de solutions.
Un bon énoncé de problème remplit trois critères: il est centré sur l’humain et non sur l’organisation, il est suffisamment large pour autoriser plusieurs pistes de solution et il est suffisamment précis pour guider l’idéation. “Améliorer l’expérience client” est trop vague; “Réduire la frustration des nouveaux clients lors de leur première commande en ligne” est actionnable.
Générer des idées sans filtre
L’idéation est la phase la plus mal comprise. Son objectif n’est pas de trouver la bonne idée, mais d’en produire le plus grand nombre possible avant d’en évaluer aucune. Cette séparation entre génération et évaluation est essentielle: quand on juge les idées en même temps qu’on les formule, on censure les propositions les plus originales.
Plusieurs techniques structurent cette phase. Le brainstorming classique reste utile à condition de respecter ses règles fondamentales, notamment l’interdiction de critiquer pendant la phase de génération. Le brainwriting, où chaque participant écrit ses idées en silence avant de les partager, produit souvent des résultats plus diversifiés car il neutralise l’effet de conformité sociale. La méthode SCAMPER (Substituer, Combiner, Adapter, Modifier, Proposer un autre usage, Éliminer, Réorganiser) offre une grille systématique pour transformer une idée existante en plusieurs variantes.
Le tri intervient ensuite: les idées sont regroupées par affinité, évaluées selon leur faisabilité et leur potentiel d’impact, et les plus prometteuses passent à l’étape suivante.
Rendre visible pour tester
Le prototypage traduit une idée abstraite en quelque chose de tangible que des utilisateurs peuvent manipuler. Le prototype n’est pas une maquette finalisée: c’est un outil d’apprentissage dont la qualité se mesure à sa capacité à provoquer des réactions utiles, pas à son degré de finition.
Un prototype peut prendre des formes très différentes selon le projet: maquette papier pour une interface, jeu de rôle pour un processus de service, storyboard pour un parcours utilisateur, maquette physique en carton pour un produit. La règle d’or est d’investir le minimum de temps et de ressources nécessaires pour tester l’hypothèse centrale. Un prototype trop abouti crée un biais: l’équipe qui a investi des semaines de travail dans une maquette fonctionnelle aura tendance à défendre sa solution plutôt qu’à la questionner.
Tester pour apprendre, pas pour valider
La phase de test met le prototype entre les mains d’utilisateurs réels. L’objectif n’est pas de confirmer que la solution fonctionne, mais de comprendre comment les gens interagissent avec elle, ce qui les surprend, ce qui les bloque et ce qu’ils détournent de l’usage prévu.
C’est ici que le caractère itératif du design thinking se manifeste pleinement. Un test peut révéler que le problème initial était mal défini, ce qui ramène à la phase de définition. Il peut montrer que l’idée retenue repose sur une hypothèse fausse, ce qui relance l’idéation. Ces boucles ne sont pas des régressions: elles affinent progressivement la compréhension du problème et la pertinence de la solution.
Le Nielsen Norman Group souligne que les organisations qui tirent le meilleur parti du design thinking sont celles qui acceptent cette itération comme partie intégrante du processus, et non comme un signe d’échec de planification.
Un processus, pas une recette
Les cinq phases ne se parcourent presque jamais de façon linéaire. Dans la pratique, les équipes reviennent régulièrement à des phases antérieures, mènent parfois deux phases en parallèle et répètent certaines boucles jusqu’à convergence. L’Interaction Design Foundation décrit ces phases comme des “modes” plutôt que des étapes séquentielles, ce qui reflète mieux la réalité de leur mise en oeuvre.
Cette flexibilité fait du design thinking un cadre particulièrement adapté aux projets dont le problème est mal défini ou dont les parties prenantes ont des visions divergentes du besoin. Elle exige toutefois une discipline de facilitation rigoureuse: sans structure, l’itération devient de l’errance et le processus perd sa capacité à converger vers une solution.