D’une métaphore oubliée : Macintosh et le lent déclin du bureau

Les raisons du succès des interfaces graphiques sont bien connues : des objets visuels simples (fenêtre, icônes, menus et pointeurs), permettant un panel d’actions limitées et explicites, organisés par une métaphore cohérente : des documents rassemblés en dossier, posés sur le bureau pour les affaires courantes et rangés dans des casiers pour le reste.

wooton
Bureau Wooton, station de travail tout-en-un

Un dossier = une fenêtre

il est moins connu que cette métaphore, à son origine, était plus forte et contraignante. Les premières versions du Finder (l’explorateur de fichier de Mac OS) obéissaient à un modèle dit « spatial », lequel a été abandonné à la sortie de Mac OS X (moment d’une refonte complète du système). Cela se traduisait par deux règles :

  1. Cohérence. Chaque dossier était représenté par une seule fenêtre et chaque fenêtre était liée à un seul dossier. L’icône d’un dossier changeait d’apparence pour signifier qu’il était ouvert ou fermé. Cliquer sur l’icône d’un dossier ouvert faisait clignoter sa fenêtre et rien d’autre, puisqu’il ne pouvait être ouvert deux fois. En bref, pour l’utilisateur il n’y avait aucune différence entre un dossier et sa fenêtre.
  2. Stabilité. Les fenêtres mémorisaient la manière dont l’utilisateur les personnalisait. La forme, la position, le mode d’affichage (grille, liste…), la position des icônes en mode grille, etc., tout cela était conservé. Grâce à l’association entre fenêtre et dossier, cette règle était beaucoup plus simple à appliquer qu’aujourd’hui et le comportement des fenêtres d’autant plus prédictible pour l’utilisateur. Si j’ouvre ce dossier, je sais qu’il apparaitra à droite sur toute la hauteur de l’écran ; si j’ouvre cet autre dossier, il apparaitra en petit à gauche et ses fichiers seront en liste. Aujourd’hui, le Finder conserve certains paramètres (taille et position) et d’autres non (mode d’affichage et style), selon des règles de priorité impénétrables (détails ici).

En résumé, le Finder « spatial » tentait de faire fonctionner le bureau comme un ensemble de choses tangibles et fixes, pouvant servir de véritable mémoire externe (l’être humain étant plus doué pour reconnaitre un objet que pour s’en rappeler). Au lieu d’utiliser une abstraction pour en gérer une autre (fenêtre et système de fichier), l’utilisateur manipulait des objets concrets qui ne changeaient pas dans son dos (principe de moindre surprise).

Contraignant mais adapté à son temps

Ce modèle pouvait être assez contraignant. Notamment, ouvrir un dossier faisait forcément apparaître une nouvelle fenêtre (la fenêtre de ce dossier). Pour éviter de se retrouver avec des dizaines ouvertes, il fallait déplier l’arborescence du dossier (comme dans Mac OS X aujourd’hui), ou bien utiliser Alt+click, ce qui fermait la fenêtre d’origine et ouvrait la nouvelle en même temps.

Un dossier dans un dossier dans un… (Mac OS 9)
Un dossier dans un dossier dans un… (Mac OS 9)

Pourtant, d’après ce que j’ai pu lire et tester, ça marchait pas mal. D’abord, ces dossiers superposés dans tous les sens ne faisaient que reproduire le rangement classique d’un bureau, dans ce qu’il peut avoir d’idiosyncrasique et d’apparement chaotique. Ensuite, l’OS était organisé autour de ce modèle. Par exemple, plutôt que de minimiser une fenêtre, on pouvait double-cliquer sur la barre de titre pour ne laisser que celle-ci et cacher tout le reste. Cette fonction de « stores » (shades) suivait, une fois encore, un principe de spatialité : la fenêtre restait à sa place.

Exemple de deux fenêtres réduites à leur barre de titres
Exemple de deux fenêtres réduites à leur barre de titres

Ensuite, la cible d’Apple était moins experte que le public typique de l’époque et n’était probablement pas à l’aise avec l’abstraction d’un système de fichiers arborescent. Enfin, les ordinateurs d’alors avaient peu de mémoire, peu de fichiers et peu d’applications, peu de mémoire et avaient donc moins besoin de manipuler des quantités énormes d’information.

Le lent déclin du bureau façon Macintosh

Aujourd’hui, bien peu d’explorateurs de fichiers utilisent encore un modèle spatial. Les seuls projets actifs que j’ai trouvé sont Haiku OS (héritier de BeOS), Enligthenment (dit-on) et MATE (mais pas par défaut).

A moins que vous n’utilisiez un système exotique, il y a de fortes chances que votre bureau fonctionne différemment. Un simple test : y a-t-il des boutons Précédent et Suivant dans une fenêtre de l’explorateur ? Si oui, c’est qu’il ressemble plus à un navigateur Internet : il permet de parcourir différents dossiers à travers une fenêtre.

Ce modèle a été popularisé par Windows 98 (avec des prémisses dans 95). Dans une optique de convergence avec Internet Explorer, une barre d’adresse et des boutons Précédent et Suivant ont été ajoutés. Ouvrir un dossier a cessé d’ouvrir une nouvelle fenêtre. Ce comportement a été adopté par Mac OS X à sa sortie, créant un Finder bâtard, avec deux types de fenêtres et des réactions imprévisibles. Pour des détails, voyez notamment cet article de Siracusa, et celui-ci de Tog (un des premiers spécialistes en IHM employés par Apple).

Cachez ces fenêtres que je ne saurais voir

Le modèle de Windows est donc devenu la convention dominante – son ubiquité n’y est sans doute pas étrangère.

A la sortie de Mac OS, Steve Jobs a déclaré qu’un utilisateur ne devrait pas avoir à faire le ménage dans ses fenêtres. Il disait surtout ça pour promouvoir certaines nouveautés plus que pour exposer une quelconque vision du futur des interfaces, mais cela signale à mon avis un changement profond quoique lent de l’OS, dont l’abandon du Finder spatial constitue la première étape.

En gros, tout est fait pour qu’on n’ait plus à déplacer ou redimensionner ses fenêtres. La plupart des fonctions introduites depuis dix ans et dédiées à la navigation vont dans ce sens :

  • Mission Control (anciennement Exposé), une vue éclatée présentant simultanément des vignettes de toutes les fenêtres
  • Launchpad, grille montrant toutes les applications
  • Spaces, permettant de gérer des bureaux virtuels au lieu de fenêtres
  • Le mode plein écran, apparu avec Lion et qui a remplacé la fonction de maximisation
  • Des onglets pour le Finder.

Certains se sont inquiétés de l’importation de certains concepts depuis iOS. Il est vrai qu’aujourd’hui, tout est fait pour qu’on puisse utiliser un Mac comme un iPad, en affichant toutes les applications en plein écran et en naviguant entre elles grâce à un geste du trackpad. Après l’abandon du Finder spatial, faut-il s’attendre un jour à la disparition des fenêtres ?

Pour aller plus loin

Vous n’avez pas le monopole du design

Les relations entre client et prestataire sont compliquées, presque par définition. Un problème fréquent pour le prestataire est de faire reconnaître son expertise, notamment quand il est dans un rôle de conception. Il est sans doute tentant d’apprendre son métier à un concepteur d’interfaces, à un architecte (de systèmes ou de bâtiments) ou à un styliste automobile, plus qu’à un illustrateur, un développeur ou tout autre personne qui réalise elle-même le résultat final.

Face à cette prétention, la solution habituelle est d’essayer d’asseoir cette expertise : « vous me payez pour ça, faites-moi confiance ». Ça peut marcher, mais c’est un joker qui ne marche pas éternellement et qui remplace l’échange par le bras de fer. Il y a certes bien des manières de convaincre et on peut être pédagogue avec un client sans l’envoyer bouler. Mais si cela se résume à surenchérir d’arrogance en voulant « éduquer » le client, j’ai peur que cela n’enterre toute possibilité d’aborder la racine du problème – et il y en a souvent une.

Le design comme symptôme

Prenons un cas auquel j’ai assisté : un client n’était pas content de propositions de pictogrammes. Après quelques échanges, il nous a envoyé des contre-propositions se résumant à des cliparts tirés d’une banque d’images et à des croquis faits par eux-même. Clairement, c’était mauvais, ça ne marchait pas. L’épisode nous a énervé et donné l’impression que le client prétendait faire le travail à notre place. A mon sens, notre très compréhensible colère se trompait de cible. Le problème n’est pas qu’ils aient osé prendre le feutre et l’initiative, c’est qu’ils l’aient fait dans leur coin.

Il y avait là une situation idéale pour une séance de co-conception, tous ensemble autour d’un tableau. On aurait ainsi pu les guider vers de meilleures solutions, voire remettre à plat l’iconographie et son utilisation. C’était peu envisageable parce qu’il n’y avait pas assez de respect mutuel. La question du design était surtout le symptôme d’un problème de communication et de cadrage. Cette guéguerre pour savoir si ces pictos étaient intelligibles n’était que le dernier épisode d’un projet mal parti, le genre où l’on doit justifier le moindre détail.

Dans ce contexte, s’arc-bouter sur ses prérogatives n’est au mieux qu’une solution à court-terme. Asséner « c’est moi le designer » ne remplace pas une vraie argumentation voire, soyons fous, des tests auprès d’utilisateurs. Adopter une approche plus collaborative offre bien des avantages. Avoir un rôle de conseiller plutôt que d’expert tout puissant permet de gagner en confiance ce que l’on perd en contrôle. Mais cela suppose dès le départ une relation saine et propice.

Le design comme monopole

Plus fondamentalement, cette idée même de prérogative est contestable. Chacun a éminemment le droit de se sentir viscéralement designer, mais dans le cadre d’un projet ce n’est qu’un un poste attribué à quelqu’un. Il y a de nombreuses manières d’organiser ce qui relève du « design ». Ça peut être une des casquettes de quelqu’un, aussi bien qu’être décomposé en spécialités : concept, études utilisateur, prototypage, animations, spécification, éditorial, graphisme, tests… c’est large.

Enfin, le design (et par extension le design UX) peut être vu comme une responsabilité de tout l’équipe, moins une compétence particulière qu’un processus plus ou moins formalisé et plus ou moins co-extensif à tout le projet. La littérature en théorie du design et en gestion de projet est abondante.

Un avis ?

VGE, wink wink
Source

Pour aller plus loin

La génération procédurale dans le jeu vidéo

Je recycle ici un travail étudiant datant d’il y a trois ou quatre ans. Le texte a été un peu désuniversitarisé, à part ça il est tel quel. Le format était volontairement court et limité au jeu vidéo.

Les jeux vidéos grand public actuels ont souvent une grande valeur ajoutée en terme de contenu : graphismes réalistes, environnements vastes et variés, acteurs professionnels, etc. Même avec un gros budget, cette richesse représente un défi de production. Par exemple, la ville immense et détaillée de GTA4 a été entièrement créée « à la main » : chaque immeuble a été dessiné et placé avec soin par des artistes. Il existe une autre approche, qui consiste à partir d’éléments de base (ici, un ensemble de bâtiments) et à les disposer semi-aléatoirement, avec certaines contraintes (laisser des vides pour que des rues se forment, rassembler les immeubles similaires pour que chaque quartier ait une identité, etc.). Cette approche dite procédurale est très générique : avec elle, on peut générer des textures, des terrains, des niveaux de jeu, des scénarios, etc.

Un peu de technique

Il y a globalement deux familles de techniques : celles des grammaires de formes et celles utilisant des fonction de bruit.

[Note 2014 : J’avoue ne plus savoir d’où je sors cette distinction. Il existe des dichotomies plus générales, notamment entre algorithmes ontogénétiques et téléogiques, c’est-à-dire en gros entre les modèles réalistes seulement en apparence et ceux qui le sont vraiment. Voir cette liste et cet article.]

Les grammaires de formes sont héritées des grammaires formelles, qui permettent de décrire avec un jeu de règles l’ensemble des phrases correctes d’un langage donné. On procède en générant toutes les phrases possibles à partir d’un alphabet et de règles de transition. Par, exemple, à partir de l’alphabet {a, b} et de la règlea => b, on peut générer le langage {a, ab, abb, abbb…}. Cette idée fut d’abord utilisée pour modéliser des phénomènes de croissance naturelle (feuilles, colonies de bactérie), puis étendue à l’architecture. En prenant des formes géométriques simples comme alphabet de base, on peut créer des façades, des bâtiments, voire des villes entières.

Système L
Système L

Passons aux fonctions de bruit. On commence par placer des points dont les valeurs sont générées de façon pseudo-aléatoire, puis à effectuer une interpolation entre eux afin d’obtenir une courbe. Faire la somme de plusieurs de ces courbes permet d’en obtenir une d’aspect plus fractal, compliqué et naturel. On peut faire la même chose en deux dimensions, ce qui donne alors une texture. Le passage à la troisième dimension permet d’obtenir un terrain, ce qui est relativement trivial : il suffit d’interpréter la valeur du niveau de gris comme une hauteur.

Bruit de Perlin en dimensions 1, 2 et 3
Bruit de Perlin en dimensions 1, 2 et 3

Un nouveau processus de conception

Générer du contenu procéduralement au lieu de le créer à la main a de multiples avantages :

  • Réduction des coûts de main d’œuvre. Concevoir et paramétrer un algorithme qui génère une forêt n’est pas trivial, mais ce sera toujours moins long que de dessiner et placer chaque arbre.
  • Diminution des besoins de stockage et de bande passante. Par exemple si l’on veut des textures hautement réalistes, il suffit de stocker l’algorithme qui les génére à la volée, et pas les lourdes images finales. C’est ce qui permet à certains de créer des démos graphiques spectaculaires avec un fichier d’origine pesant quelques dizaines de Ko, alors que l’équivalent en vidéo pèserait beaucoup plus. Voir par exemple .kkrieger.

Cette approche a évidemment des limites. Générer procéduralement un objet revient à automatiser sa création, ce qui implique dans une certaine mesure qu’on le comprenne. Par exemple, créer des récits vraisemblables suppose que l’on sache ce qui fait qu’une histoire est bonne. Il faut au pire avoir de bonnes intuitions et heuristiques à ce sujet, au mieux avoir isolé des invariants et savoir les combiner. Cela fait écho à la quête des théoriciens du récit et des spécialistes des séries télévisées qui cherchent à trouver des archétypes et des mécanismes présents dans tout récit.

Ces limites suggèrent une méthode de conception différente de celle fréquemment en vigueur. Les jeux vidéo pour le grand public sont souvent très linéaires, avec une suite d’évènements scriptés minutieusement. Par exemple, un avion doit passer au-dessus du joueur précisément au moment où il sort d’un tunnel. Le but est de contrôler autant que possible l’expérience du joueur, dans la perspective classique d’un artiste démiurge et totalement maitre de l’univers fictionnel. Cet idéal devient impossible dans une perspective procédurale, puisque le contenu est largement aléatoire1. Par exemple, on ne peut pas savoir la disposition exacte des arbres et des clairières dans une forêt.

Pourtant, on regagne en facilités de macro-gestion ce qu’on perd en contrôle minutieux. On ne peut pas placer telle espèce d’arbre à tel endroit, mais on peut faire des changements globaux sur la flore simplement en modifiant l’algorithme. Ce nouvel état d’esprit peut se répandre dans tout le processus de conception. Par exemple, puisqu’on ne peut pas planifier précisément l’emplacement d’une rencontre en forêt, on peut laisser le programme s’en occuper en suivant certaines conditions (« dans une clairière à moins d’un kilomètre de la ville »). Ensuite, on peut être tenté de rendre aléatoire la survenue elle-même des évènements. Certains moments clés dans le scénario peuvent restés pré-codés, tandis que d’autres peuvent se faire au hasard (par exemple les rencontres que le joueur ferait dans une ville).

De nouveaux types d’interactions

L’approche procédurale change aussi beaucoup la manière de jouer. Certains jeux promettent en effet une re-jouabilité potentiellement infinie, puisque la cartographie des niveaux, l’emplacement des objets, les objectifs à remplir, etc. sont différents pour chaque nouvelle partie et chaque joueur. La question de la durée de vie d’un jeu doit donc être repensée, puisqu’elle dépend plus de la propension du joueur à se lasser que de l’imagination du développeur. À charge pour ce dernier de créer un programme qui génère des environnements et des aventures intéressantes, le reste se passe entre le jeu et le joueur. C’est à nouveau une perte de contrôle pour le créateur, mais qui se révèle payante, puisqu’elle permet au joueur de mieux s’approprier le jeu et de se faire sa « propre » aventure.

Plus généralement, le centre de gravité se déplace du créateur vers la création elle-même. Dans beaucoup de jeux classiques, le joueur essaye de composer avec ce qu’il devine des intentions du créateur, en essayant de prédire où un piège a été placé, ou quel va être le prochain rebondissement dans l’intrigue. Dans un jeu généré procéduralement, on cherche plutôt la logique qui gouverne la génération de ces structures variées. Passé l’émerveillement initial, on cherche la nécessité derrière la contingence apparente des formes.

L’approche procédurale est ainsi très prometteuse. Il existe même des travaux qui tentent de rendre automatisable la génération des règles elles-mêmes, notamment Angelina, un moteur aléatoire de création de jeux. Toutefois, étant donné les limitations de conception, ne sont envisageables que des méthodes où seul un aspect du jeu est procédural.


  1. Dans les faits, peu de jeux sont générés intégralement de manière procédurale. De plus, on peut techniquement rendre l’environnement identique à chaque génération, puisque le générateur est pseudo-aléatoire : il suffit d’entrer à chaque fois les même paramètres de départ. 

Plaidoyer pour l’URL

Résumé : il faut se battre pour l’URL mais il faut aussi améliorer la barre d’adresse et en faire une vraie barre de navigation et d’action.

Google expérimente en ce moment une nouvelle fonctionnalité pour Chrome : faire disparaitre l’URL de la barre d’adresse. Il ne subsisterait que le nom de domaine dans un cadre, afin de mieux le mettre en avant et lutter contre le phishing (source). Cela permettrait de mieux distinguer amazon.com de amazon.siteChelou.com. Pour voir l’URL et l’éditer, il faudrait cliquer sur le nom de domaine.

Animation empruntée à Usability Post

Beaucoup se sont élevés contre cette idée (notamment), l’URL étant le concept fondateur du web. Grâce à elle, un document est accessible universellement et sans ambiguïté. À cela, on peut répondre que bien des appareils fonctionnent parce que leur technologie est invisible pour l’utilisateur. Après tout, on ne lui révèle pas l’adresse IP d’un site ou le header d’une requête HTTP, alors que ce sont des protocoles fondamentaux et porteurs d’information. De plus, les URL sont souvent une suite de caractères incompréhensibles et inutilisables.

Mon avis : cela reste une mauvaise idée et une réponse très disproportionnée au problème du phishing. Rien n’empêche une URL de suivre une syntaxe claire, il y a même de bonnes raisons techniques pour cela. De plus, elle peut comporter des informations directement pertinentes pour l’utilisateur. Considérez une URL de ce genre :

boutique.com/fr/vêtements/homme/pantalons?items-par-page=30?classement=prix

Elle permet de situer la page dans l’arborescence du site et de signaler comment elle est paramétrée. C’est un excellent repère de navigation, toujours présent et toujours au même endroit.

On pourrait aller plus loin et imaginer que chaque niveau de l’URL soit manipulable, comme cela se fait dans l’explorateur de fichiers de Windows ou dans certains éditeurs de code. Par exemple, dans Coda, cliquer sur un dossier du chemin ouvre un menu permettant d’accéder aux autres dossiers de même niveau. Cliquer sur le fichier ouvert permet également d’accéder aux différentes fonctions que celui-ci inclut, ce qui facilite la navigation dans le corps du document. Dans une page web, par exemple, on pourrait imaginer que changer de langue se fasse depuis l’URL, par un menu dédié, au lieu de chercher désespérément le lien dans la page (cela m’arrive souvent dans des bases documentaires).

interactive path for Coda 2

Plus généralement, je trouve toujours dommage qu’on essaye de cacher un système puissant, sous prétexte qu’il est complexe et mal utilisé. Il faudrait plutôt domestiquer cette complexité et la rendre plus accessible aux utilisateurs. La barre d’adresse d’un navigateur est aujourd’hui un des rares endroits où l’on est confronté au concept d’interface en ligne de commande. C’est aussi une interface vers énormément de choses : historique, favoris, recherche, etc. Organiser et retrouver du contenu, opérer un service… Il y a là un gros potentiel et une bonne occasion de faire progresser les interfaces en ligne de commande et d’y habituer les gens.

Je précise que mon propos n’est pas une position de principe ou un un appel à sauver le web. Un protocole ne devrait avoir aucune importance, sauf s’il peut avoir du sens pour l’utilisateur, comme ici. Je dis bien « peut » : en l’état, la plupart des gens se fichent des URL et vu la gueule de bien d’entre elles, on les comprend. Il y a là un pari : c’est seulement en explorant leur potentiel qu’on fera comprendra leur intérêt au plus grand nombre.

C’était l’idéal d’un projet de Mozilla, Ubiquity. Le concept de départ, très ambitieux, était de s’abstraire des pages et de proposer une interface en language naturel qui permette d’exécuter des actions de haut niveau et de les lier entre elles. Concrètement, on pourrait entrer « réserver un vol vers Sidney pour moi et Machin, envoyer l’itinéraire à Machin et ajouter la date à mon calendrier ». La réalité était plus modeste mais tout de même bien cool. Pour en savoir plus, voir ici et ici.

Bref, il y a tant de choses à faire autour de la barre d’adresse.

Le design thinking et le mythe du designer-magicien

Résumé : le design n’est pas une panacée.

On entend par design thinking le fait de recourir à des designers, en personne ou via des méthodes qu’on leur prête. Cela peut être à des fins de conception, d’innovation, de changement organisationnel, d’amélioration du quotidien, de politique, bref d’un peu tout et n’importe quoi. Bien qu’on croise des dizaines de définitions, le design thinking est supposé principalement être un processus :

  • Itératif
  • Centré sur l’humain
  • Créatif dans la résolution de problèmes

De prime abord, ces critères sont positifs, mais quel rapport avec le design ou les designers ? Tout repose sur l’idée que celui qui fait vœu de design acquiert certaines capacités supérieures ou uniques, qu’il peut appliquer à peu près à tous les domaines. Cette supposée exclusivité me paraît très contestable :

  1. Travailler de manière itérative et incrémentale est depuis longtemps une tarte à la crème dans l’industrie.
  2. Garder à l’esprit les besoins des usagers est quelque chose de présent dans certains milieux, notamment en ergonomie. Les techniques de terrain, quant à elles, viennent largement des sciences humaines et sociales. Comme le dit Peter Merholz, ce n’est pas pour autant qu’on parle de socio thinking ou d’ethno thinking.
  3. La créativité est une notion très floue. On peut la rattacher à l’intuition, mais celle-ci n’est ni une habilité particulière ni quelque chose de propre au designer : c’est seulement la manière dont nous utilisons notre expérience de manière intériorisée et non-réflexive (cf cet article de Raskin pour ce qui est des IHM). On rapproche également la créativité de l’abduction (appelée aussi inférence à la meilleure explication), mais cela revient à dire qu’on est designer dès qu’on fait un diagnostic médical, qu’on résout une enquête criminelle ou qu’on essaye de deviner qui s’est servi dans le frigo la nuit dernière. Enfin, en parlant de créativité, on aime à imaginer le designer comme celui qui sait réfléchir en dehors des sentiers battus et voir à travers les problèmes mal posés. Cela impliquerait qu’on est un peu designer dès qu’on fait preuve d’audace intellectuelle, ce qui est encore une façon pour le design de tout ramener à soi. Steve Jobs était un businessman visionnaire, pas besoin d’en faire un designer.

Bref, ces caractéristiques n’ont rien d’exceptionnel et sont largement répandues.

On peut répondre que ces traits sont présents ici et là mais ont été rarement combinés dans une seule discipline. On peut également rétorquer que le design thinking voit le design comme une disposition latente en chacun et pas comme un don réservé à une caste (cf. par exemple how designers think de Nigel Cross, qui s’ouvre par « tout le monde peut designer, et tout le monde le fait »). Pourtant le mystère reste entier : les designers ont-ils un talent particulier et ce talent est-il généralisable à n’importe quel type de problème ?

Quelque soit la réponse, beaucoup agissent comme si c’était le cas et cela montre que l’on prête un pouvoir démesuré au design. Que l’on mette l’accent sur la discipline ou sur ses praticiens, ce statut messianique existe surtout parce qu’on a une vision très fantasmée du potentiel et de l’influence du design. De la même manière qu’on voit le philosophe comme un sage, on prend le designer pour un magicien, quelqu’un ayant tout compris et pouvant tout faire : il voit dans les tréfonds de l’âme des utilisateurs, il prédit les usages de demain, il guérit les grosses organisations de leurs scléroses, etc. Cette complaisance entretenue a sans doute été utile pour promouvoir et légitimer le design, au point que Don Norman a pu y voir une fiction utile. Mais cela me paraît une mauvaise excuse, même sous l’angle de la communication : les fantasmes, surtout aussi séduisants, parasitent les débats, créent des attentes déplacées et à terme font du mal à tout le monde.

Le design thinking abrite de nombreux bons conseils et a été l’étendard de bien des beaux projets, mais cela reste à mon avis un concept inutile.


Pour aller plus loin, on pourra lire cette critique ainsi que cet article de Lucy Kimbell, intéressant en lui-même et contenant beaucoup de références pour et contre sur le sujet.