Le design thinking, étape par étape, et là où il déraille

Le design thinking est une façon de résoudre les problèmes qui part des personnes qui les vivent. En pratique, il se déroule en cinq étapes : comprendre les personnes, définir le problème, générer des idées, fabriquer un prototype sommaire et le tester avec de vrais utilisateurs, en revenant en arrière chaque fois que le test vous apprend quelque chose. Les étapes sont simples ; les équipes se trompent à des endroits prévisibles, et cet article vous montre où, et comment éviter chacun de ces pièges.

La version en cinq étapes est celle qu'enseigne la d.school de Stanford (empathie, définition, idéation, prototypage, test). Le Double Diamond du Design Council britannique, créé en 2003 et diffusé publiquement à partir de 2004, décrit le même parcours en quatre phases : découvrir, définir, développer, livrer. Utilisez le vocabulaire que votre organisation connaît déjà. Ce qui compte, c'est l'ordre des questions, pas les noms sur les diapositives.

Si vous vous demandez si le design thinking est seulement la bonne approche, lisez d'abord design thinking, lean, agile ou design sprint. Pour la carte complète des outils, voyez quel outil d'innovation utiliser ?.

Avant de commencer : poser le défi

Le design thinking échoue le plus souvent avant la première étape. Réglez trois points avant le premier entretien.

1. Un sponsor qui porte la décision. Nommez la personne qui agira sur le résultat. Si personne ne peut dire oui à l'issue, le projet produira un rapport.
2. Un brief qui nomme un champ de problème, pas une solution. « Améliorer la façon dont les nouveaux collaborateurs traversent leur premier mois » est un brief. « Développer une application d'intégration » est une solution déguisée, qui referme le projet avant même de l'ouvrir.
3. Une petite équipe cœur, mixte, et du temps protégé. Quatre à six personnes, dont quelqu'un qui rend le service au quotidien. Une demi-journée par semaine pendant six semaines vaut mieux qu'un séminaire héroïque de trois jours sans suite.

Étape 1 : comprendre les personnes (empathie)

Ce que vous faites. Allez voir les personnes qui vivent le problème. Menez des entretiens avec les parties prenantes auprès de huit à douze personnes couvrant toute la diversité des utilisateurs, pas seulement les plus aimables. Ajoutez de l'observation en contexte : regardez la tâche se faire là où elle se fait.

Ce qui en sort. Des notes dans les mots des personnes elles-mêmes, des photos de l'environnement réel, et une première carte d'empathie pour chaque grand type d'utilisateur.

Là où ça déraille.

• L'équipe interroge des collègues ou des managers au sujet des utilisateurs, au lieu des utilisateurs eux-mêmes.
• Les questions demandent aux gens de prédire leur comportement futur (« Utiliseriez-vous… ? »), ce qu'ils font mal.
• La recherche est sous-traitée, et l'équipe lit une synthèse au lieu d'entendre directement les personnes. Le déclic se produit dans la pièce, pas dans le rapport.

La parade. Interrogez sur la dernière fois où quelque chose s'est produit (« Racontez-moi la dernière fois que vous… »), et faites en sorte que chaque membre de l'équipe cœur assiste à au moins deux entretiens. Pour en savoir plus : 5 erreurs de recherche qui gâchent vos entretiens.

Étape 2 : définir le problème

Ce que vous faites. Étalez les constats et regroupez-les avec un diagramme d'affinités. Cherchez les tensions et les surprises, pas seulement les plaintes fréquentes. Rédigez un énoncé de point de vue : un utilisateur précis, un besoin, et un insight sur la raison pour laquelle cela compte. Transformez-le en deux ou trois questions « Comment pourrions-nous ».

Ce qui en sort. Un énoncé du problème partagé et une courte série de questions « Comment pourrions-nous », validés par le sponsor.

Là où ça déraille.

• L'équipe saute cette étape parce que « nous connaissons déjà le problème ». En général, elle connaît le symptôme.
• L'énoncé est si large (« Comment pourrions-nous améliorer l'expérience client ? ») que n'importe quelle idée y entre, ou si étroit (« Comment pourrions-nous ajouter un chatbot ? ») qu'il introduit la réponse en douce.
• On ne montre pas l'énoncé au sponsor, qui rejette ensuite les idées parce qu'il avait un autre problème en tête.

La parade. Traitez la validation de l'énoncé du problème comme un point de passage obligé. Un guide complet se trouve dans votre énoncé du problème, c'est tout le projet.

Étape 3 : générer des idées (idéation)

Ce que vous faites. Commencez en silence. Utilisez le brainwriting ou les Crazy 8s pour que chacun produise des idées seul avant que le groupe n'en discute. Visez d'abord la quantité. Ensuite, regroupez, rebondissez sur les idées des autres, et resserrez avec une matrice impact-effort ou un outil comparable.

Ce qui en sort. Deux ou trois idées qui méritent un prototype, chacune reliée à la question « Comment pourrions-nous » à laquelle elle répond.

Là où ça déraille.

• Discussion ouverte dès la première minute : la personne la plus haut placée ou la plus bruyante fixe la direction.
• L'équipe tombe amoureuse d'une idée et cesse d'en produire.
• Les idées sont choisies à main levée, sans se demander lesquelles répondent le mieux à l'énoncé du problème.

La parade. Séparez la production du jugement, dans le temps et dans les règles. Pour l'argumentaire contre le brainstorming ouvert et ce qu'il faut utiliser à la place, voyez le brainstorming ne marche pas ; voici ce qui marche.

Étape 4 : prototyper

Ce que vous faites. Fabriquez la chose la moins chère qui permette à une vraie personne de réagir à l'idée. Un prototype papier d'un écran ou d'un formulaire, un storyboard d'un service, une maquette de courrier, une conversation de guichet jouée en jeu de rôle. Avant de construire, listez les hypothèses les plus risquées avec une cartographie des hypothèses et assurez-vous que le prototype les teste.

Ce qui en sort. Un prototype sommaire par idée, plus une note écrite sur ce que vous comptez en apprendre.

Là où ça déraille.

• Le prototype est trop abouti. Les gens sont polis face à ce qui semble fini et cessent de donner un avis sincère, et l'équipe rechigne à jeter un travail qui a pris des semaines.
• Le prototype teste la partie facile (l'aspect de l'écran) au lieu de la partie risquée (savoir si quelqu'un apporterait les bons documents).
• On mobilise l'informatique ou un prestataire pour construire un pilote, et le projet devient discrètement une mise en œuvre.

La parade. Fixez une limite d'un ou deux jours par prototype. Si cela prend plus longtemps, il est trop détaillé.

Étape 5 : tester, puis boucler

Ce que vous faites. Mettez le prototype devant cinq vrais utilisateurs environ. Menez un test d'utilisabilité modéré : donnez-leur une tâche, observez, et taisez-vous. Consignez les résultats dans une grille de recueil des retours : ce qui a marché, ce qui n'a pas marché, les questions soulevées, les nouvelles idées.

Ce qui en sort. Une décision claire pour chaque idée : l'affiner, l'abandonner, ou la faire passer en pilote. Souvent, vous découvrirez aussi que le problème était légèrement mal formulé, ce qui vous renvoie à l'étape 2.

Là où ça déraille.

• L'équipe explique le prototype avant le test, puis mesure à quel point les gens ont compris l'explication.
• Le test est vécu comme un examen final à réussir, si bien que les résultats négatifs sont justifiés et écartés.
• Après le test, il n'existe aucun chemin vers la mise en œuvre, et le prototype finit dans un tiroir.

La parade. Convenez à l'avance du résultat qui vous ferait abandonner l'idée. Et avant de tester, convenez avec le sponsor de qui portera une idée réussie jusqu'à sa mise en œuvre, et sur quelle ligne budgétaire.

Un exemple concret

Illustratif. La bibliothèque d'une université d'une grande ville veut que davantage d'étudiants utilisent son service d'accompagnement à la recherche. La fréquentation est faible, et la responsable des services de la bibliothèque suppose que le problème vient de la notoriété.

Comprendre. L'équipe de cinq personnes interroge dix étudiants et observe le bureau d'accueil pendant trois après-midi. Les étudiants savent que le service existe. Ce qui les arrête, c'est que la réservation exige de décrire leur sujet de recherche dans un formulaire, et beaucoup ont le sentiment que leur sujet n'est pas encore « assez bon » pour être montré à un bibliothécaire.

Définir. L'énoncé de point de vue devient : « Les étudiants de première année de master ont besoin d'un moyen sans enjeu de demander de l'aide tôt, parce qu'ils se sentent jugés quand leur idée de recherche est encore floue. » La question « Comment pourrions-nous » : « Comment pourrions-nous rendre normal le fait de demander de l'aide avant que le sujet ne soit clair ? »

Idéer. Un tour de brainwriting produit quarante idées. La matrice impact-effort en laisse trois : des permanences sans rendez-vous « sujet encore flou », un formulaire de réservation avec un seul champ facultatif, et la venue de bibliothécaires au premier séminaire de chaque cursus.

Prototyper. Une affiche imprimée pour les permanences et une version papier du formulaire raccourci, réalisées toutes deux en une matinée.

Tester. Sur deux semaines, les permanences attirent un flux régulier d'étudiants, tandis que le formulaire raccourci ne change pas grand-chose. L'équipe abandonne le formulaire, garde les permanences pour un pilote d'un semestre, et convient avec la responsable des services de la bibliothèque des heures de personnel qui les assureront.

L'hypothèse de départ, selon laquelle les étudiants ne connaissaient pas le service, aurait produit une campagne d'affichage. Le processus a produit une autre réponse.

À faire, à éviter

À faire

• Obtenir un sponsor nommé et un brief sans solution avant la première étape.
• Faire entendre directement les utilisateurs à l'équipe cœur.
• Faire valider l'énoncé du problème avant l'idéation.
• Prototyper en heures, pas en semaines.
• Prévoir le chemin vers la mise en œuvre avant de tester.

À éviter

• Traiter le design thinking comme un atelier. Une journée peut couvrir l'idéation ; le processus complet prend des semaines.
• Sauter l'étape de définition pour gagner du temps. Elle en fait perdre davantage ensuite.
• Peaufiner les prototypes ou les expliquer avant le test.
• Dérouler le processus pour justifier une décision déjà prise. Les gens s'en aperçoivent, et vous les perdez pour le projet suivant.
• Considérer les étapes comme strictement linéaires. Revenir en arrière, c'est la méthode qui fonctionne.

Questions fréquentes

Quelles sont les 5 étapes du design thinking ? Dans le modèle de la d.school de Stanford : empathie, définition, idéation, prototypage et test. Le Double Diamond du Design Council regroupe le même travail en quatre phases : découvrir, définir, développer et livrer.

Combien de temps dure un projet de design thinking ? Pour un problème de service bien ciblé, comptez quatre à dix semaines de travail à temps partiel pour une petite équipe cœur. Un design sprint peut condenser les dernières étapes en cinq jours, mais seulement une fois le problème raisonnablement bien compris.

Pourquoi le design thinking échoue-t-il dans les organisations ? Généralement pour des raisons organisationnelles, pas méthodologiques : pas de sponsor qui porte le résultat, un brief qui contient déjà la solution, une recherche sautée ou sous-traitée, et aucun chemin entre un prototype testé et sa mise en œuvre.

Pour aller plus loin

Les guides de méthode pour chaque étape : les entretiens avec les parties prenantes pour l'étape 1, l'énoncé de point de vue et les questions « Comment pourrions-nous » pour l'étape 2, le brainwriting pour l'étape 3, et le prototype papier pour les étapes 4 et 5. Pour approfondir le test, lisez comment tester une idée avant de la construire.