Le design thinking

Don Norman ouvre ce chapitre par une règle de consultant qu'il qualifie lui-même de contre-intuitive : « ne jamais résoudre le problème qu'on me demande de résoudre ». La raison est simple et redoutable : le problème qu'on vous soumet n'est presque jamais le vrai problème, le problème fondamental, la cause racine. C'est le plus souvent un symptôme. Comme au chapitre précédent, où la solution aux accidents passait par la découverte de la cause profonde des événements plutôt que par la sanction de l'opérateur, le secret du design réside dans une discipline patiente : comprendre quel est le vrai problème avant de prétendre le résoudre. Ce chapitre est celui de la méthode — le design thinking —, c'est-à-dire la façon dont les designers passent d'une demande floue à un produit qui sert réellement les gens.

Résoudre le bon problème

Il est stupéfiant de voir combien de fois les gens résolvent le problème qu'on leur pose sans jamais songer à le questionner. Norman raconte qu'il donne à ses étudiants — ingénieurs comme MBA — un problème le premier jour de cours, puis écoute la semaine suivante leurs solutions magnifiques : analyses brillantes, dessins détaillés, tableurs où sont disséqués les coûts, les ventes, les marges et les profils démographiques de la clientèle. Tout est bien fait, brillamment présenté. Et lorsque les présentations s'achèvent, il les félicite, puis demande : « Comment savez-vous que vous avez résolu le bon problème ? » Stupeur. Ingénieurs et gens d'affaires sont dressés à résoudre des problèmes ; pourquoi diable leur en donnerait-on un mauvais ?

C'est que le monde réel ne ressemble pas à l'université. À l'université, le professeur fabrique des problèmes artificiels, bien emballés, prêts à l'emploi. Dans la vie, les problèmes n'arrivent jamais dans de jolis paquets nets : ils doivent être découverts. Il est terriblement facile de ne voir que les problèmes de surface et de ne jamais creuser jusqu'aux véritables enjeux. C'est précisément là que se sépare la formation de l'ingénieur de celle du designer.

Les bons designers ne commencent jamais par tenter de résoudre le problème qu'on leur a confié : ils commencent par chercher à comprendre quels sont les enjeux réels. Au lieu de converger vers une solution, ils divergent — ils étudient les gens et ce qu'ils cherchent à accomplir, ils génèrent idée sur idée sur idée. Ce comportement rend les managers fous. Le manager veut voir des progrès ; le designer, lui, semble reculer : on lui donne un problème précis et, plutôt que de se mettre au travail, il l'ignore et soulève de nouvelles questions, de nouvelles directions à explorer. Et pas une seule : beaucoup. Que se passe-t-il ?

Les designers ont développé tout un arsenal de techniques pour ne pas se laisser piéger par une solution trop facile. Ils prennent l'énoncé d'origine comme une suggestion, non comme un verdict final, puis réfléchissent largement aux enjeux qui sous-tendent réellement cet énoncé — exactement comme la méthode des « cinq pourquoi » (five whys) du chapitre précédent permet de remonter à la cause racine. Surtout, le processus doit être itératif et expansif. Le designer résiste à la tentation de sauter immédiatement à une solution : il prend d'abord le temps de déterminer quel est le problème fondamental, puis, même une fois celui-ci cerné, il s'arrête encore pour envisager un large éventail de solutions possibles. Ce n'est qu'alors qu'il converge enfin vers sa proposition. Ce processus s'appelle le design thinking — et il n'est nullement la propriété exclusive des designers : tous les grands innovateurs l'ont pratiqué, fût-ce sans le savoir, qu'ils fussent artistes ou poètes, écrivains ou savants, ingénieurs ou entrepreneurs.

Le design centré sur l'humain

Le design thinking s'appuie sur deux outils puissants : le design centré sur l'humain (human-centered design, HCD) et le modèle du double diamant (double diamond). Le premier est le processus qui garantit que les besoins des gens sont satisfaits, que le produit qui en résulte est compréhensible et utilisable, qu'il accomplit les tâches désirées, et que l'expérience d'usage est positive et agréable. Concevoir efficacement, c'est satisfaire une multitude de contraintes et de préoccupations à la fois : forme et esthétique, coût et efficacité, fiabilité et efficacité réelle, compréhensibilité et utilisabilité, plaisir de l'apparence, fierté de la possession, joie de l'usage. Le HCD est une procédure pour traiter toutes ces exigences, mais avec une insistance sur deux choses : résoudre le bon problème, et le faire d'une manière qui respecte les besoins et les capacités humaines.

Au fil du temps, les nombreux métiers et industries impliqués dans le design ont convergé vers un ensemble commun de méthodes. Chacun a sa variante favorite, mais toutes déclinent le même thème : itérer à travers quatre étapes — observation, génération d'idées, prototypage, test. Avant tout cela, néanmoins, un principe surplombe les autres : résoudre le bon problème. C'est de cette dualité — trouver le bon problème, puis répondre aux besoins humains — que naissent les deux phases du processus de design, et c'est ce que capture le modèle du double diamant.

Le modèle du double diamant

Introduit en 2005 par le British Design Council, le double diamant décrit le rythme alterné de divergence et de convergence qui structure tout projet de design. On part d'une idée ; on diverge d'abord pour explorer l'espace du problème — examiner tous les enjeux fondamentaux qui le sous-tendent —, puis on converge vers un énoncé de problème unique et juste. Vient ensuite le second diamant : on diverge à nouveau pour explorer un large éventail de solutions possibles, avant de converger vers la proposition finale à livrer.

   TROUVER LE BON PROBLEME        TROUVER LA BONNE SOLUTION

         <>                              <>
        <  >                            <  >
   idee<    >                      <    >
        <    >    enonce du   idees<    >
         <  >     probleme         <  >    solution
          <>      ----------->      <>     ----------->
      decouvrir  definir      developper  livrer

   divergence  convergence   divergence  convergence
   --------------------- TEMPS --------------------->

Le Design Council découpe ainsi le processus en quatre étapes : « découvrir » (discover) et « définir » (define) pour les phases de divergence et de convergence du bon problème ; « développer » (develop) et « livrer » (deliver) pour celles de la bonne solution. Ce double mouvement diverger-converger est remarquablement efficace pour libérer les designers des restrictions inutiles imposées aux espaces du problème et de la solution.

On comprend pourtant la détresse du chef de produit : il a confié un problème à résoudre, et voilà ses designers qui contestent la mission, exigent de parcourir le monde pour acquérir une compréhension plus profonde, puis, même une fois concentrés sur le problème, ne semblent pas progresser mais accumulent une foule d'idées à demi formées, parfois manifestement impraticables. Pire encore : au moment de converger vers une solution, ils réalisent parfois qu'ils ont mal formulé le problème, si bien qu'il faut tout recommencer (plus vite, cette fois). Ce va-et-vient paraît chaotique et désordonné, mais il suit en réalité des principes bien établis.

Le processus HCD : observer, générer, prototyper, tester

Le double diamant décrit les deux phases ; le processus de design centré sur l'humain décrit, lui, comment on les parcourt. Il se déploie à l'intérieur du double diamant et se compose de quatre activités, répétées en boucle — on parle souvent de méthode en spirale plutôt qu'en cercle, pour souligner que chaque tour fait progresser.

Activité	Ce qu'on y fait	Piège à éviter
Observation	Étudier les gens en contexte, dans leur environnement naturel (ethnographie appliquée)	Se fier à ce que les gens disent faire plutôt qu'à ce qu'ils font
Génération d'idées (idéation)	Produire en quantité, sans juger, en questionnant tout	Se fixer trop tôt sur une ou deux idées
Prototypage	Construire vite une maquette grossière de chaque solution	Attendre un prototype « parfait » avant de tester
Test	Faire utiliser le prototype par de vrais représentants de la cible	Tester trop tard, ou des gens qui ne sont pas la cible

Observation : aller voir les gens là où ils vivent

La recherche initiale pour comprendre la nature même du problème relève de la recherche en design (design research). Attention : il s'agit de recherche sur les clients et les futurs utilisateurs, non de la recherche que les scientifiques mènent en laboratoire pour découvrir de nouvelles lois de la nature. Le chercheur en design va vers les clients potentiels, observe leurs activités, tente de comprendre leurs intérêts, leurs motivations, leurs véritables besoins. La définition du problème jaillira de cette compréhension profonde des buts que les gens poursuivent et des obstacles qu'ils rencontrent.

La technique la plus critique consiste à observer les utilisateurs dans leur environnement naturel, dans leur vie normale, là où le produit sera réellement utilisé. Chez eux, à l'école, au bureau ; dans les transports, aux repas, en soirée, au bar du coin avec leurs amis. « Suivez-les jusque sous la douche s'il le faut », plaisante Norman, car il est essentiel de saisir les situations réelles, et non une expérience isolée et purifiée. Cette technique porte un nom : l'ethnographie appliquée (applied ethnography), méthode empruntée à l'anthropologie, mais plus rapide et plus ciblée, car les buts diffèrent — déterminer des besoins humains adressables par de nouveaux produits, dans des cycles contraints par le calendrier et le budget.

Ce qui compte le plus, ce ne sont pas les mesures traditionnelles des gens — âge, éducation, revenu — mais les activités à accomplir. Même entre cultures très différentes, les activités se révèlent souvent étonnamment semblables : c'est pourquoi automobiles, ordinateurs et téléphones sont assez standardisés à travers le monde. Mais lorsqu'un produit vise une sous-culture précise — les adolescentes japonaises diffèrent profondément des femmes japonaises, et plus encore des adolescentes allemandes —, il faut étudier exactement cette population. Et si le produit sera utilisé dans un autre pays que celui où il est conçu, il n'y a qu'une seule façon de le savoir : y aller (et toujours inclure des natifs dans l'équipe). Pas de raccourci consistant à rester chez soi en interrogeant quelques étudiants ou visiteurs venus de là-bas : ce qu'on en apprend ne reflète que rarement la population cible.

Génération d'idées : produire d'abord, juger ensuite

Une fois les exigences déterminées, l'équipe génère des solutions potentielles : c'est l'idéation (ideation). C'est la partie amusante du design, celle où la créativité est reine. Quelle que soit la technique — la plupart relèvent du « brainstorming » —, deux règles majeures prévalent. D'abord, générer de nombreuses idées : il est dangereux de se fixer trop tôt sur une ou deux. Ensuite, être créatif sans égard pour les contraintes : éviter de critiquer les idées, les siennes comme celles des autres, car même une idée folle, manifestement fausse, peut renfermer une intuition féconde qu'on extraira plus tard. Norman ajoute une troisième règle qui lui est chère : tout questionner, et particulièrement par des questions « stupides ». Une question stupide interroge des choses si fondamentales que tout le monde en suppose la réponse évidente ; mais prise au sérieux, elle se révèle souvent profonde, car « l'évident, bien souvent, ne l'est pas du tout ».

Prototypage : le magicien d'Oz

La seule manière de savoir si une idée tient debout, c'est de la tester ; et pour la tester, il faut un prototype. Aux premiers stades, les maquettes peuvent être de simples croquis au crayon, des modèles en carton et en mousse, des diapositives, des fiches bristol, voire des saynètes jouées lorsqu'on conçoit des services difficiles à matérialiser. Une technique célèbre porte le nom de « magicien d'Oz » (Wizard of Oz), d'après le personnage de L. Frank Baum : ce sorcier n'était qu'un homme ordinaire qui, à grand renfort de fumée et de miroirs, se faisait passer pour omnipotent. Tout était truqué.

Norman illustre par une anecdote restée fameuse. Pour tester un système de réservation de billets d'avion, il faisait entrer les sujets un à un dans une petite pièce isolée de son laboratoire de San Diego et leur faisait taper leurs besoins de voyage, croyant dialoguer avec un programme automatisé. En réalité, dans la pièce voisine, un de ses étudiants lisait les requêtes et tapait les réponses. Le test fut riche d'enseignements : un sujet demandant un aller-retour San Diego–San Francisco précisa « je voudrais repartir le mardi suivant, mais je dois être rentré avant mon premier cours, à 9 heures ». L'équipe comprit qu'il ne suffisait pas de comprendre les phrases : il fallait résoudre un problème mobilisant des connaissances sur les aéroports, le trafic, les délais de bagages, le stationnement. Le but initial — comprendre le langage — était trop étroit ; il fallait comprendre les activités humaines.

Test : cinq personnes, puis itérer

On rassemble un petit groupe de gens correspondant au plus près à la population cible et on leur fait utiliser le prototype le plus fidèlement possible à l'usage réel. Astuce : même si l'usage normal est solitaire, il est utile de faire travailler deux personnes ensemble, l'une manipulant, l'autre guidant et interprétant à voix haute, car cela les amène à discuter ouvertement et naturellement de leurs idées, de leurs hypothèses et de leurs frustrations. L'équipe observe discrètement — assise derrière, ou par vidéo depuis une autre pièce —, puis interroge les sujets après coup en reconstituant leurs pas.

Combien de personnes étudier ? Les avis varient, mais Jakob Nielsen, associé de Norman, défend depuis longtemps le chiffre cinq : cinq personnes étudiées individuellement suffisent à révéler l'essentiel. Mieux vaut faire un test à cinq, affiner, puis recommencer avec cinq autres — multipliant les cycles d'amélioration — que de tester une seule fois un grand nombre de personnes.

Itération : « échouer souvent, échouer vite »

Le rôle de l'itération est de permettre le raffinement continu. Le but, selon la formule de David Kelley, professeur à Stanford et cofondateur d'IDEO, est de prototyper et tester rapidement : « Fail frequently, fail fast » — échouer souvent, échouer vite. Bien des dirigeants rationnels ne comprennent jamais cet aspect du processus. Pourquoi voudrait-on échouer ? Ils croient qu'il suffit de fixer les exigences puis de construire en conséquence, les tests ne servant qu'à vérifier la conformité. C'est cette philosophie qui engendre tant de systèmes inutilisables. Les échecs ne devraient même pas s'appeler des échecs : ce sont des expériences d'apprentissage. « Si tout marche parfaitement, on n'apprend rien ; l'apprentissage survient quand surgissent les difficultés. »

Centré sur l'activité, pas seulement sur l'individu

L'attention intense portée aux individus est une marque de fabrique du HCD. Mais que faire quand un produit s'adresse au monde entier ? Automobiles, appareils photo, ordinateurs, téléphones, réfrigérateurs sont à peu près identiques partout, avec d'infimes variations régionales. Comment prétendre accommoder des populations aussi disparates ? La réponse de Norman est de se concentrer sur les activités, et non sur la personne : le design centré sur l'activité (activity-centered design). Que l'activité définisse le produit et sa structure ; que le modèle conceptuel (conceptual model) du produit s'organise autour du modèle conceptuel de l'activité.

Pourquoi cela fonctionne-t-il ? Parce que les activités humaines se ressemblent à travers le monde, et surtout parce que les gens, rétifs à apprendre des systèmes aux exigences arbitraires et incompréhensibles, acceptent volontiers d'apprendre ce qui paraît essentiel à l'activité. Cela ne viole nullement les principes du HCD : c'est une bonification, car les activités sont menées par et pour des humains. L'automobile en est l'exemple parfait : conduire exige de maîtriser pédales, volant, clignotants, feux, rétroviseurs, instruments, tout en surveillant la route — une foule de sous-tâches qui n'ont guère de sens hors de l'activité, mais que chacun accepte d'apprendre parce qu'elles semblent appropriées à la conduite.

Itératif contre linéaire : la réalité du terrain

Le processus de design traditionnel est linéaire — la méthode dite en cascade (waterfall), où l'on avance dans une seule direction et où il est difficile de revenir en arrière une fois les décisions prises. Elle s'oppose à la méthode itérative du HCD, circulaire, faite de raffinement continu et qui encourage à revisiter les décisions précoces — d'où des variantes comme Scrum et Agile. Les méthodes en cascade les plus rigides sont dites « à barrières » (gated methods) : chaque étape est séparée de la suivante par une barrière (gate), une revue de direction qui décide du passage à l'étape suivante.

Laquelle est supérieure ? Comme toujours dans les débats féroces, les deux ont vertus et défauts. L'itératif excelle à clarifier l'énoncé du problème et à différer la rédaction de spécifications rigides, mais il se déploie mal sur les très grands projets — des centaines voire des milliers de développeurs, des années, des millions ou des milliards. Les barrières, elles, donnent à la direction un contrôle bien meilleur, mais sont lourdes : les revues à chaque étape engloutissent des semaines. La meilleure approche combine les deux : l'itération se déroule à l'intérieur des étapes, entre les barrières. Le tour de force consiste à retarder la spécification précise des exigences jusqu'à ce qu'un peu de prototypage rapide ait été fait, tout en gardant un contrôle serré sur calendrier, budget et qualité. Et le plus dur, dans les produits complexes, n'est pas technique : c'est le management — organiser, communiquer, synchroniser une multitude de personnes et de divisions, sur des horizons si longs que les exigences, les technologies et les équipes elles-mêmes changeront en cours de route.

« Dans la pratique, ça ne marche pas vraiment comme ça »

Tout ce qui précède décrit l'idéal. Norman cite la vieille blague : « En théorie, il n'y a pas de différence entre la théorie et la pratique ; en pratique, il y en a une. » Un membre désabusé d'une équipe de design lui confia que, malgré le discours de son entreprise sur l'expérience utilisateur et le HCD, seuls deux moteurs gouvernaient en réalité les nouveaux produits : ajouter des fonctionnalités pour rattraper la concurrence, et ajouter une fonctionnalité poussée par une nouvelle technologie. « Cherchons-nous les besoins humains ? — Non. » Pression du marché plus culture d'ingénierie produisent une inflation sans fin de fonctions, de complexité et de confusion. Mais même les entreprises sincèrement décidées à chercher les besoins humains se heurtent au manque de temps et d'argent. D'où la loi que Norman propose.

Deux remèdes émergent. D'abord, pour échapper à la pénurie de temps qui interdit la recherche amont, il faut dissocier la recherche de l'équipe produit : des chercheurs en design en permanence sur le terrain, étudiant clients et produits potentiels, de sorte qu'au lancement ils puissent dire « nous avons déjà étudié ce cas, voici nos recommandations ». Ensuite, le choc des disciplines — design, ingénierie, programmation, fabrication, marketing, ventes, service —, chacune avec ses exigences légitimes mais souvent contradictoires, se résout par des équipes pluridisciplinaires où des représentants de tous les métiers sont présents en permanence, du premier jour jusqu'à l'expédition et au service après-vente. Quand chacun comprend et respecte les contraintes des autres, on trouve souvent des solutions créatives qui satisfont la plupart des enjeux. Cela exige un chef de produit habile pour créer compréhension et respect mutuels — mais c'est possible.

Le défi du design

Le design est une discipline merveilleuse parce qu'elle réunit technologie et humains, affaires et politique, culture et commerce. On demande au designer de gérer des choses complexes, l'interaction de la technologie et des gens — aujourd'hui un appareil photo, demain un système de transport ou la structure d'une organisation. Comment une même personne peut-elle œuvrer dans des domaines si variés ? Parce que les principes fondamentaux du design pour les humains sont les mêmes partout : les gens sont les mêmes, donc les principes le sont aussi. Le designer n'est cependant qu'un maillon d'une longue chaîne : l'efficacité de l'ingénierie, la fiabilité, le coût, la viabilité financière comptent aussi, et posent des exigences parfois opposées, le calendrier et le budget restant les deux contraintes les plus sévères. Dans une organisation bien tenue, tous les métiers du cycle produit se réunissent pour partager leurs exigences et concevoir ensemble, avec des compromis acceptables ; dans une organisation dysfonctionnelle, chaque équipe travaille isolée et voit ses spécifications altérées par les autres de façon qu'elle juge déraisonnable.

Norman achève le chapitre par quelques motifs récurrents du design réel : les clients ne sont pas toujours les utilisateurs (un promoteur qui achète des électroménagers se soucie du prix, jamais de l'utilisabilité) ; il faut donc étudier les acheteurs autant que les usagers. Le design pour les personnes spéciales — âgées, handicapées, malvoyantes, malentendantes — bute sur le problème de la stigmatisation : beaucoup refusent les aides dont ils ont besoin par crainte de l'image qu'elles renvoient. La parade ? Concevoir pour tous : l'éplucheur OXO de Sam Farber, pensé pour son épouse arthritique mais vendu comme « meilleur pour tout le monde », a révolutionné son industrie — c'est le design universel (universal design), où chacun finit par gagner. Norman rappelle aussi que la complexité est bonne ; c'est la confusion qui est mauvaise : une cuisine inconnue paraît compliquée, la nôtre non — la confusion n'est pas dans la cuisine, elle est dans l'esprit, et le bon modèle conceptuel la dissipe. Enfin, la standardisation simplifie la vie (qu'on songe à l'horloge : une horloge tournant à contre-sens, avec son « 12 » déplacé, obéit pourtant à une logique strictement identique à celle de l'horloge ordinaire — elle est tout aussi logique ; si elle nous désarçonne, c'est seulement parce que nous nous sommes standardisés sur l'autre convention, sur la définition même du sens horaire, et qu'il nous faut sinon recalculer la correspondance à chaque coup d'œil ; c'est notre convention de mesure du temps qui est arbitraire — vingt-quatre heures découpées en deux cycles de douze, plus l'artifice des am/pm, puis soixante minutes et soixante secondes —, et non la logique de l'horloge) — mais standardiser trop tôt fige une technologie primitive, trop tard rend tout accord impossible, comme l'illustrent l'interminable bataille des standards de la TVHD ou l'échec du temps décimal.

À retenir

• Ne jamais résoudre le problème qu'on vous demande de résoudre : c'est presque toujours un symptôme. La première discipline du design est de remonter à la cause racine et de résoudre le bon problème — une solution brillante au mauvais problème peut être pire que pas de solution du tout.
• Le design centré sur l'humain (HCD) garantit que le produit répond à de vrais besoins, est compréhensible et agréable, en insistant sur deux points : le bon problème, et le respect des capacités humaines.
• Le double diamant alterne divergence et convergence en deux phases : explorer puis définir le bon problème (découvrir, définir), explorer puis livrer la bonne solution (développer, livrer). On encourage l'exploration libre, mais on tient les délais.
• Le processus HCD itère quatre activités : observation en contexte (ethnographie appliquée), idéation (produire beaucoup, sans juger, tout questionner), prototypage rapide (le « magicien d'Oz »), et test (cinq personnes suffisent, puis on recommence). « Échouer souvent, échouer vite » : les échecs sont des apprentissages.
• Les bonnes exigences ne se demandent pas, elles s'observent : les gens dévient toujours de ce qu'ils décrivent, et la plupart des cas sont « spéciaux ».
• Le design centré sur l'activité complète le centrage sur l'individu : laisser l'activité définir le produit permet de servir des populations vastes et hétérogènes (l'iPod a soutenu toute l'activité d'écoute, pas une tâche isolée).
• L'idéal HCD se heurte à la réalité — loi de Norman : tout projet démarre en retard et hors budget. La parade tient à la recherche menée en continu hors de l'équipe produit, et à des équipes pluridisciplinaires présentes du premier jour à l'après-vente.