

Discover more from Easy Tech
EasyTech #10 - le Design Thinking, une théorie incontournable
LA brique à maîtriser pour tous les Product Managers
Salut salut 😃
Très heureux de te retrouver avant cette très courte semaine !
Aujourd’hui, on parle d’un sujet important pour les Product Managers : le Design Thinking.
Qu’est-ce que c’est concrètement ?
En une image, le Design Thinking c’est ça :
Le fameux “Double Diamant”
On parle souvent de “Double Diamant” pour résumer le Design Thinking. Le diamant étant le losange “horizontal”. On en a un premier pour la partie problème puis un second pour la partie solution.
La puissance de la notion de Diamant, c’est que ça matérialise qu’on alterne des phases de divergence puis des phases de convergence.
→ Pendant les phases de divergence on “ouvre ses chakras”.
On va essayer d’avoir plein d’idées et de chercher à plein d’endroits différents. On ne s’auto-censure pas. À ce stade on veut du volume et de la quantité, pas de la qualité.
Par exemple je me demande où je vais partir en vacances, en phase divergente je pense à plein d’idées. Pas grave si c’est farfelu. Je n’ai aucune contrainte, ça peut être les Gorges du Verdon, au fond de l’océan ou sur Mars !
→ Pendant les phases de convergence on focalise sur le plus pertinent
Une fois qu’on a récupéré plein de matière, on priorise. On choisit ce sur quoi on veut se focaliser. Comme ça on est sûr de délivrer plus de valeur.
Par exemple je peux regrouper les destinations en fonction de critères comme (i) le prix, (ii) l’accessibilité. Mars est pas accessible. Le fond des océans trop cher. Mais les Gorges du Verdon, accessible ✅ et pas trop cher ✅.
La partie problème
L’objectif de ce diamant : identifier le bon problème.
Pendant la phase divergente on essaye de trouver le plus de problèmes possibles
On le fait avec 3 principales activités.
Premièrement, des interviews (ou entretiens) utilisateurs. On va aller discuter avec nos utilisateurs… tout simplement !
Alors évidemment, c’est plus facile à dire qu’à faire. Il faut :
(i) recruter des utilisateurs disponibles et intéressées ;
(ii) aller les interroger efficacement pour récupérer un max d’éléments ;
(iii) analyser toute cette matière pour en sortir les éléments avec le plus de valeur.
Deuxièmement, on va aller observer les comportements liés au problème qu’on veut résoudre.
Par exemple, si je lance une appli comme Cajoo ou Gorillaz pour se faire livrer ses courses, j’ai tout intérêt à aller observer les gens qui font leurs courses ! À quel moment de la journée ? Quel est le profil des personnes ? Est-ce que les clients font beaucoup la queue ?
À partir de ces observations, je collecte des éléments de compréhension très précieux et un peu moins biaisés que lorsque je pose directement des questions à un utilisateur.
Troisièmement, on va faire de la recherche secondaire (😅 le terme a l’air un peu barbare mais en fait ça va).
La recherche secondaire, c’est de la recherche qu’on va faire tout seul de notre côté “en chambre”. Quelque soit le problème auquel on s’intéresse, quelqu’un a déjà dû y réfléchir et écrire des choses intelligentes dessus.
On va donc chercher des livres, des articles ou des éléments sur Internet qui en parlent. On va aussi aller se balader sur des forums en ligne, pour voir ce que disent nos utilisateurs cibles.
Pendant la phase convergente, on identifie les problèmes sur lesquels se focaliser
On a récupéré plein de problèmes, il faut qu’on identifie ceux sur lesquels on va se focaliser.
On veut se focaliser sur les problèmes les plus durs, les plus récurrents et les plus pénibles. Parce que ce sont les problèmes dont la résolution apportera le plus de valeur aux utilisateurs.
Premièrement, on va faire des interviews utilisateurs (encore). Par rapport aux premiers entretiens qu’on a fait dans la partie divergente, on va essayer d’être un peu plus ciblé sur les problèmes pré-identifiés. Pour les qualifier davantage et préparer la priorisation.
Par exemple, si j’ai identifié trois problèmes : pb1, pb2, pb3. Je vais poser des questions comme : “pouvez-vous me classer pb1, pb2 et pb3, par ordre de pénibilité ?” ; “dans un monde idéal, si vous deviez choisir un seul problème que je résolve, lequel ça serait ?”
💡 À noter que tu peux très bien traiter les deux aspects (divergence / convergence) pendant un même entretien. Ça permet de gagner du temps, mais attention à ne pas négliger la partie problème / divergence.
Deuxièmement, on va cartographier le processus suivi par l’utilisateur. Si on veut résoudre un problème donné, ce problème intervient dans un contexte et au sein d’un ensemble d’actions réalisées par l’utilisateur. C’est ce contexte et ces actions qu’on veut repérer.
Par exemple, pour mon application de livraison de courses, par quelles étapes passe mon utilisateur cible lorsqu’il fait ses courses aujourd’hui ?
Même si un des problèmes que j’identifie est “les utilisateurs n’aiment pas faire la queue au supermarché”, je vais regarder tout ce qu’il se passe autour de l’activité des courses. Pas uniquement regarder le moment où il fait la queue.
Troisièmement, faire des sondages. Tu vas créer un questionnaire sur un outil comme Google Form et Type Form. Puis l’envoyer à des utilisateurs potentiellement intéressés.
Deux avantages à ça :
Ça confirme quantitativement, statistiquement, les intuitions qu’on a et sur lesquelles on échange en entretien.
Ça nous force à démarrer les activités de prospection. On va réfléchir à comment atteindre notre cible et au message qu’on va lui envoyer etc…
La partie solution
Pendant la phase divergente on regroupe plein de pistes solutions potentielles
On va le faire avec trois principales activités.
Premièrement, le brainstorming (tempête de cerveau en français 😅) ! En gros on va faire venir quelques utilisateurs dans une même pièce avec trois temps principaux :
D’abord tout le monde va noter ses idées, ⚠️ on est en mode divergence donc pas de jugement
Ensuite on va regrouper tous les posts-its par thématiques similaires.
Enfin, tout le monde vote pour identifier les thématiques qui paraissent les plus pertinentes.
Deuxièmement, on fait réagir l’utilisateur sur des mini-maquettes du produit (donc de la solution) qu’on veut développer.
Les utilisateurs vont sûrement vouloir modifier des choses, être en accord avec certains éléments, ou en désaccord avec d’autres. Et c’est génial ! C’est ce qu’on veut.
Attention, ces maquettes ne doivent pas être trop réalistes ou précises. Sinon on va trop biaiser les utilisateurs en faveur de la solution qu’on privilégie. Des mini dessins pas trop précis / ressemblants type “storyboarding” feront très bien l’affaire, par exemple :
Troisièmement, on va chercher de l’inspiration en regardant ce qui se fait ailleurs.
On va regarder :
Des produits sur des problématiques similaires, par exemple pour la livraison de courses, on va regarder la livraison de repas
Des produits sur des problématiques proches, par exemple pour la livraison de courses, on va regarder les applications e-commerce
Des produits qui n’ont pas grand chose à voir, parce que ça peut toujours nous donner des idées ! Par exemple, on peut regarder Uber, AirBnb, Instagram… qui sont de superbes applications, peut-être qu’il y aura des éléments qui vont nous donner des idées.
C’est aussi pertinent de chercher de l’inspiration pour la charte graphique et l’univers visuel de ce qu’on veut construire. D’ailleurs je te conseille d’aller regarder le site Dribble si tu veux un petit shot d’inspiration design.
Pendant la phase convergente, on affine notre solution privilégiée jusqu’à en valider une
3 activités vont nous aider pendant phase convergente du diamant solution.
Premièrement, des ateliers de “co-design” / co-construction avec les utilisateurs. L’idée est de choisir, faire évoluer à la marge ou affiner notre solution en demandant leur avis aux utilisateurs.
C’est un peu différent de l’activité côté divergence où on fait réagir l’utilisateur sur les maquettes. Ici, on veut que l’utilisateur soit partie prenante des fonctionnalités qu’on développe, en fonction de ses priorité.
L’avantage : l’utilisateur est engagé et valide les idées directement. Ça veut dire qu’il a plus de chance d’être un utilisateur en cible, lorsqu’on aura sorti le vrai produit.
Deuxièmement, on construit un prototype. Ce prototype ressemblera comme deux gouttes d’eau à l’application finale. Mais on n’aura pas écrit une seule ligne de code pour le construire.
C’est presque magique et super efficace. En effet, c’est encore très très simple à ce stade de bouger des éléments du prototype. À partir du moment où on aura écrit des lignes de code, ça le sera beaucoup moins.
Un outil hyper utile pour faire du prototypage est Figma. Tu en as peut-être déjà entendu parler. Sinon je te conseille d’aller jeter un oeil à cette formation gratuite Open Classroom si ça t’intéresse 😄
Troisièmement, on va réaliser des “tests utilisateurs” pour confirmer que la solution qu’on envisage - matérialisée avec notre prototype - est bien pertinente !
Dit comme ça, on a l’impression que c’est un moment clé / stressant mais en fait :
Si on a bien construit de manière itérative, avec beaucoup d’entretiens utilisateurs et de la co-construction, il y a peu de risque qu’on se soit complètement trompés
Si on se rend compte qu’il n’y a pas de potentiel dans notre idée, au moins on n’a pas écrit de code à ce stade, ce qui veut dire qu’on n’a pas dépensé trop d’argent.
Un outil très efficace pour faire des tests utilisateur est Maze. Tu branches ton prototype et les utilisateurs le testent avec des questions par-ci par-là. C’est fait comme un jeu (Maze = labyrinthe en anglais), donc c’est beaucoup plus agréable pour eux.
Bref historique du Design Thinking
Maintenant qu’on a un peu compris les enjeux. On se replonge rapidement en arrière pour comprendre d’où ça vient.
Dans les années 1970, les premiers principes
Dès les années 1970, on identifie que c’est difficile de rationaliser complètement le fonctionnement des systèmes et problèmes complexes.
On va notamment parler de “wicked problems” (problème épineux en français) pour définir des problèmes difficiles à résoudre car :
Multi-dimensionnels = il est nécessaire de mélanger différents axes pour les analyser, les comprendre et influencer dessus
Complexes = pas de possibilité de tout rationaliser par une formule, de tout expliquer facilement
Par exemple, un problème épineux pourrait être de supprimer la faim dans le monde.
C’est un problème multi-dimensionnel car il y a des enjeux politiques (comment mettre d’accord les États) et économiques (qui paye quoi et comment).
C’est un problème complexe qu’on ne peut pas résumer par une seule formule ou expliquer facilement ; la faim en tant que tel c’est difficile à définir, à mesurer et agir dessus est délicat.
Pour gérer ces problèmes et systèmes complexes, on se rend compte que la compréhension passe par deux activités :
Construire et prototyper
Observer
Dans les années 1980, science = problème, design = solution
Il y a un petit recul à cette période. Plutôt que de gérer les choses de manière globale, on essaye de résoudre les choses de manière fragmentée. Via des disciplines spécialisées.
En fait à cette époque, pas mal d’expériences sont faites pour comprendre comment l’esprit humain résout des problèmes. Et on observe la dichotomie suivante :
Les scientifiques sont très orientés sur la compréhension du problème
Les designers, eux, sont très forts pour tester rapidement des solutions
On voit qu’on commence à voir apparaître la distinction problème / solution structurante dans nos doubles diamants 💪 ! Pour autant c’est encore trop segmenté / cloisonné 😕.
Des années 1990 jusqu’à maintenant, le design thinking prend la place qu’on lui connaît
Finalement, le Design Thinking va peu à peu s’affirmer comme une méthodologie globale et sérieuse..
Deux phénomènes y ont largement contribué.
Premièrement, des avancées théoriques
Des universitaires / académiques vont créer le terme “Design Thinking” et en font une discipline à part entière. Son objectif est de mélanger plusieurs sciences dans une approche holistique pour trouver des solutions innovantes à des problèmes complexes
Deuxièmement, des avancées pratiques
L’agence de design Ideo va mettre en pratique avec acharnement ces approches. Elle va l’utiliser pour traiter des problèmes très variés et va documenter le processus par lequel elle passe. Petit à petit, la renommée d’Ideo grandit et avec elle le Design Thinking.
D’ailleurs, les fondateurs d’Ideo ont écrit un excellent livre : Creative Confidence qui détaille différents cas d’usage traités avec ce genre de méthode.
Pourquoi c’est puissant ?
L’alternance divergence convergence
C’est un principe qui marche extrêmement bien pour créer des produits digitaux. Mais ça va bien au delà de ça !
Dans tout processus créatif, c’est efficace d’alterner :
des phases divergentes où tu vas essayer d’avoir plein d’idées diverses et variées, sans forcément les trier, sans forcément être très exigeant
des phases convergentes où tu vas essayer de choisir les idées les plus pertinentes, et être justement beaucoup plus exigeant.
Par exemple c’est exactement ce que je fais pour mes posts LinkedIn et les sujets de mes newsletters. Dans une première étape, j’essaye d’avoir des idées et je les note toutes, sur une note iPhone sur laquelle c’est vraiment le b*rdel.
Après, je passe sur une phase convergente. Je choisis les posts qui me plaisent le plus, qui ont le plus de potentiel. Ça veut donc dire qu’en pratique, il y aura beaucoup d’idées qui ne verront jamais le jour. Mais c’est pas grave, parce que de cette quantité, statistiquement, vient plus de qualité 😄
L’orientation problème
Je trouve ça très important que le Design Thinking inclue deux phases, les deux diamants, avec d’abord la partie problème.
Globalement, LE plus gros risque lorsqu’on développe des produits, c’est de partir sur un produit qui n’est utilisé par personne. On ne le fait jamais exprès. Mais je constate que ça arrive souvent lorsqu’on a une idée de solution en tête, et qu’on veut absolument le développer.
L’avantage d’une “orientation problème” :
on identifie dès le début le problème à résoudre et donc, on a plus de chance de trouver des utilisateurs pour qui résoudre de problème revêt un enjeu significatif
on ne jette pas l’idée de solution à la poubelle, bien au contraire, on va se focaliser dès le début notre travail sur ce qui apporte le plus de valeur
Attention, évidemment le deuxième diamant solution a aussi beaucoup d’importance. Il ne faut pas passer sa vie à étudier le problème sous toutes ses formes jusqu’à en avoir une compréhension exceptionnelle. Il faut vite itérer sur la partie solution.
La puissance des itérations
Quand on regarde le schéma en double diamant, c’est facile de se dire que c’est “bêtement” linéaire :
On définit le problème une fois pour toutes !
On bosse ensuite sur la solution et on va jusqu’au bout !
Pareil sur l’apparente linéarité des phases convergentes puis divergentes.
Bien évidemment ça ne doit pas se passer comme ça :
Dans les diamants, on peut faire des aller-retours entre convergence et divergence
Entre les diamants, on peut et on doit revenir de temps en temps en arrière dans la partie problème pour ré-affiner ou pivoter
De manière très opérationnelle, quand tu démarres, je te conseille de faire des minis sprints d’1 semaine problème / solution / problème / solution etc. 1 sprint avec 5 entretiens utilisateurs par exemple. Ça va te permettre d’affiner très vite et de progresser en connaissance rapidement.
Pour aller plus loin
On complexifie un petit peu 🤯 et on détaille ce qu’il y a dans les deux diamants.
Tout est très bien expliqué dans ces deux articles : le premier de 2016 ; le second de 2018. Ils permettent d’avoir une vision plus précise et actionnable. Mais ⚠️ accroche-toi bien avant de lire ça car c’est un poil plus complexe 😄 💪
Conclusion
Les coups de ❤️ de la semaine
📝 Le contenu de la semaine : cet article sur le design thinking dont je parle juste au dessus, il m’a beaucoup inspiré sur le sujet pour construire la newsletter. Par ailleurs si tu cherches un livre sur le sujet, on m’a conseillé Change By Design, je ne l’ai pas encore lu mais ça ne va pas tarder 😄
📰 L'actu de la semaine : tu ne l’as peut être pas vue passer, mais je suis très fier de cette tribune rédigée avec Thiga sur l’équilibre théorie et pratique
😂 Le rire de la semaine : ce tweet qui m’a bien fait rire, effectivement l’IA a beaucoup de potentiel, mais il y aura des choses pour lesquelles on aura toujours besoin de l’homme 🙌
À dimanche prochain !
Si tu es trop impatient pour attendre, tu peux :
M'envoyer des actus, contenus ou rires qui ont animé ta semaine et j'essayerai de les inclure dans l'édition de la semaine prochaine (en te citant bien sûr) 💪
Me contacter pour échanger sur le Design Thinking par mail ou par message LinkedIn 💪
M'envoyer des feedbacks sur ce numéro, positifs... ou négatifs bien sûr ! C'est comme ça qu'on progresse 💪
Partager la newsletter à des personnes susceptibles d'être intéressées 💪
Bon courage pour la semaine (juste 3 jours ça va 😄) !
Victor