La posture du facilitateur : actionner la pédale de frein
Le design thinking n'est pas un simple prétexte pour jouer avec des post-it ; c'est une approche rigoureuse et structurée pour résoudre des problèmes très ambigus en comprenant en profondeur l'utilisateur final. En tant que facilitateur de cette démarche, vous devez jouer le rôle de « pédale de frein » de la salle. Les équipes sont naturellement programmées pour se ruer vers les solutions, surtout quand la salle compte beaucoup d'ingénieurs, d'opérationnels ou de dirigeants. Votre première mission est de combattre cet instinct. Vous devez obliger l'équipe à rester dans l'ambiguïté inconfortable et trouble de l'espace problème jusqu'à ce que la vraie nature de la douleur de l'utilisateur devienne indéniable. Si elle tente de sauter à une solution avant d'avoir pleinement compris la difficulté de l'utilisateur, ramenez-la fermement en arrière.
Quand le framework fonctionne vraiment (et quand il échoue)
Cet atelier est le plus efficace face à un problème « pernicieux » (wicked problem). Ce sont des défis notoirement mal définis, sans précédent clair dans l'histoire de votre organisation, ou qui reposent largement sur des comportements humains complexes : par exemple, trouver comment rendre un parcours d'onboarding très technique moins intimidant pour un utilisateur non technique.
Le design thinking est la bonne intervention quand vos solutions actuelles semblent usées, ou quand vous soupçonnez qu'elles reposent sur des hypothèses internes et sur la politique de l'organisation plutôt que sur des preuves empiriques venues des utilisateurs. C'est aussi un excellent moyen de casser des silos bien ancrés entre services, ou de sortir une équipe enfermée dans la routine des « affaires courantes » qui a désespérément besoin de libérer une innovation réelle et transversale. Il échoue en revanche quand le problème est purement technique, ou quand la solution est déjà connue et que l'atelier ne sert que de mise en scène pour obtenir l'adhésion.
Choisir les participants et poser le cadre
La magie d'un atelier design thinking vient entièrement d'une collaboration radicale entre métiers. Visez un groupe resserré de cinq à huit participants. Ce groupe doit absolument inclure un « décideur », la personne qui a l'autorité et le budget pour donner le feu vert au projet, afin que le résultat ne finisse pas au fond d'un tiroir. Il vous faut aussi un expert client, comme un agent du support en première ligne ou un chercheur UX dédié, qui parle chaque jour à l'utilisateur final et connaît son vocabulaire réel, sans filtre. Complétez la salle avec des « bâtisseurs » qui comprennent les contraintes techniques et financières, pour garder les idées ancrées dans la réalité, et un « joker » venu d'un service sans aucun rapport, pour apporter un regard neuf et sans parti pris.
Ne tentez pas une session de design thinking sans données qualitatives brutes : on ne peut pas faire preuve d'empathie envers un tableur ou un camembert. Avant même le début de la session, exigez que chaque participant regarde au moins un entretien utilisateur enregistré ou lise une série de tickets de support client bruts. Tout aussi important, posez clairement l'attente que chacun laisse son ego, son titre et ses certitudes au vestiaire. Les participants sont là pour découvrir ce qui est vrai, pas pour confirmer ce qu'ils croient déjà juste.
Dompter le chaos : la phase d'exécution
Une session type dure une demi-journée ou une journée entière et passe méthodiquement par quatre phases distinctes. Elle commence par la phase d'empathie, qui plonge l'équipe dans les données utilisateurs pour rédiger un énoncé du problème clair et centré sur l'humain. Si cet énoncé ressemble à une exigence technique, comme « il nous faut une base de données plus rapide », obligez l'équipe à le réécrire du point de vue de l'utilisateur, par exemple : « l'utilisateur abandonne son panier parce que le long écran de chargement l'inquiète pour sa carte bancaire ».
L'équipe passe ensuite à la phase d'idéation, un brainstorming divergent. Ici, imposez sans concession la règle d'improvisation du « Oui, et… » pour protéger les idées fragiles, encore naissantes, des critiques prématurées. Enfin, l'équipe doit passer à la phase de prototypage et de test : elle est obligée d'arrêter de parler et de commencer à construire des prototypes basse fidélité avec des matériaux bon marché comme le papier ou des wireframes, puis de les confronter immédiatement à la réalité.
Provoquer le déclic
Tout au long de la session, maintenez l'honnêteté intellectuelle de l'équipe en posant des questions incisives et dérangeantes. Demandez-lui sans cesse si elle résout vraiment le problème de l'utilisateur, ou si elle conçoit simplement une solution qui facilite ses propres processus internes. Demandez-lui d'identifier l'hypothèse la plus risquée qui sous-tend son idée préférée, ou comment elle résoudrait le problème avec zéro budget et une seule semaine pour lancer. Quand quelqu'un critique durement une idée, ne le laissez pas simplement l'enterrer : obligez-le à formuler dans quelles conditions de marché précises cette idée fonctionnerait réellement.
Restez très vigilant face aux pièges courants. Le plus dangereux consiste à sauter entièrement la phase d'empathie pour foncer vers l'idéation, ce qui aboutit invariablement à une équipe qui résout brillamment le mauvais problème. Vous devez aussi combattre la mentalité du « Oui, mais… », le pire ennemi de l'idéation naissante. Protégez la démarche du « design par comité », où l'on fusionne les idées audacieuses pour contenter tout le monde, ce qui donne des solutions édulcorées et médiocres ; donnez plutôt au décideur les moyens de trancher, même quand c'est difficile. Enfin, empêchez l'équipe de compliquer ses prototypes. Le but est d'apprendre vite, pas de construire parfaitement.
Tirer davantage de la session
Deux techniques approfondissent la démarche. Pendant la phase d'empathie, demandez à un membre de l'équipe de jouer le persona cible dans un faux entretien, pour que le reste de l'équipe s'entraîne à creuser les points de douleur avant de parler à de vrais utilisateurs. Pendant l'idéation, désignez quelqu'un pour jouer l'avocat du diable et éprouver les idées avec des cas limites et des failles structurelles avant de commencer à prototyper.
Le livrable créé pendant cette session n'est pas un objet précieux à défendre ; ce n'est qu'une hypothèse qui attend d'être testée. La mission en sortant de la salle : prendre ces prototypes basse fidélité, les mettre devant de vrais utilisateurs, échouer aussi vite et à aussi peu de frais que possible, et rapporter les enseignements bruts pour la prochaine itération. Le vrai travail commence dès que vous laissez votre ego au vestiaire et que vous vous mettez à la place de vos utilisateurs.
