Gravir les échelles du design

Petite mission et pied dans la porte

En 2007, Michael Beirut décrivait comment il gravissait l’échelle des enjeux pour gagner en légitimité :

The client asks you to design a business card. You respond that the problem is really the client’s logo. The client asks you to design a logo. You say the problem is the entire identity system. The client asks you to design the identity. You say that the problem is the client’s business plan. And so forth. One or two steps later, you can claim whole industries and vast historical forces as your purview. The problem isn’t making something look pretty, you fool, it’s world hunger !

Boy that escalated quickly

Toute la SNCF dans un papelard

Dans ce mille-feuilles d’enjeux, les couches supérieures structurent celles du dessous. Dans les cas extrêmes, un objet anodin encapsule une bonne partie de la complexité de tout l’édifice. Exemple : les 36 données présentes sur un billet de la SNCF, commentées ici.

Billet SNCF

Dans le même genre, j’ai récemment aidé à concevoir d’un outil permettant aux encadrants d’une entreprise de saisir un nombre, lequel était syndicalement et politiquement sensible. Potentiellement, l’outil aurait pu se résumer à un champ et un bouton de validation : chacun saisit le nombre pour son périmètre, qui sera agrégé en une stat global – et basta. Dans les faits, tout a été discuté : quand doit-il être saisi, avec quelle régularité, selon quelle méthode d’estimation (le corpus juridique fournissant seulement un cadre général), comment inciter les gens à le faire sans perdre en rigueur, etc.

Bref, beaucoup de questions souvent inattendues pour un seul champ, alors qu’on était bien placés auprès de l’échelle des décideurs. C’est ce que tentent de faire beaucoup de gens : s’attaquer à un problème par la racine et pas par la petite porte, en ayant d’emblée une position assez influente pour vraiment changer les choses. Faire du design stratégique, de la stratégie UX, de la conduite du changement, etc.

C’est facile à dire

Dans un projet, il est bon d’être responsable de son niveau, consulté pour le niveau +1 et au courant du niveau +2. Exemple : vous êtes responsable des IHM, on vous consulte sur les choix fonctionnels et on vous tiens au courant du raisonnement derrière les orientations stratégiques. Il peut y avoir des niveaux en dessous (déclinaison des IHM) et au dessus. Si vous avez besoin de gravir un échelon pour faire du bon travail et que vous y parvenez (par exemple lors du projet suivant), tant mieux, mais :

  1. C’est plus facile à dire qu’à faire.
  2. Il est difficile de suivre ou de s’occuper de trop de niveaux en même temps.

Qui es-tu et d’où parles-tu ?

Ces réflexions m’amènent à un article récent de Donald Norman et Pieter Jan Stappers. Son propos est que si on monte très haut dans les échelons, on arrive au niveau de systèmes socio-techniques complexes, qui posent des défis spécifiques :

  • Inter-dépendance des éléments
  • Relations causales non-linéaires et non-séquentielles
  • Latences longues et imprédictibles
  • Echelles multiples
  • Données opérationnelles changeantes

Ces thèmes sont bien connus en théorie de la complexité mais c’est intéressant de les voir convoqués dans le domaine de la conception centrée-utilisateur.

Hélas, l’article manque de réflexivité : les auteurs auraient pu se demander personnellement quelles positions ils ont dans leurs interventions. Don fucking Norman n’a pas le même prestige quand il débarque dans un projet que le concepteur en « design public » évoqué ici et stagiaire à l’époque, même s’ils travaillent sur des sujets similaires. Comme on disait dans le temps : « qui es-tu et d’où parles-tu ? » Bref, tout est affaire de contexte : à quel stade commence-t-on, avec quelle mission officielle, commandité par qui, et cetera et cetera.