Pourquoi les noms des métiers du design changent

Pour concevoir des logiciels, il faut des plans. Et il faut savoir s’en écarter. Beaucoup de stratèges ont exprimé cette idée de différentes façons — Eisenhower est sûrement le plus connu à l’avoir fait. Les détails d’un plan conçu des années avant un événement critique sont souvent incorrects. Mais le processus de planification, celui qui a mené à ce plan, demande l’exploration des options et des contingences. La connaissance acquise durant ce sondage est cruciale pour choisir les meilleures options, à mesure que se déroule les événements.

Le projet informatique n’échappe pas à cette règle. Plusieurs méthodes se sont succédées pour tenter de maîtriser le chaos de la création d’un logiciel. Depuis plusieurs années, la méthode de développement agile est la plus populaire. Seulement, là où cette méthodologie est efficace pour découper le travail de développement et fournir des indicateurs d’avancement aux managers, elle a souvent du mal à prioriser les bénéfices pour l’utilisateur final. La méthode produit du process plutôt que du résultat. C’est précisément dans ce hiatus, cette zone purement tactique, celle située entre la planification et le delivery, que se situe le gros de l’action du designer.

Pourtant, le designer ne rédige pas les user stories des POs. Il n’aide pas les décideurs à savoir quand mettre l’argent, et à quel moment. Il n’aide pas les architectes logiciels à concevoir le modèle de données.

Ou plutôt si, mais pas directement. Car sans qu’ils s’en rendent toujours compte, les participants du projet voient des informations se connecter, des problèmes se factoriser, des développeurs et des POs se comprendre. Le modèle de données prend en compte les enjeux du business. Tandis que tout le monde se comprend mieux, les temps de développement se réduisent. Puis, les utilisateurs finissent par avoir dans leurs mains quelque chose qui leur convient. Ils ne le verbalisent pas toujours, d’ailleurs. Mais si on regarde aux bons endroits, on le remarque : le nombre de tickets de support chute. Le temps de complétion des tâches diminue. D’autres choses, plus difficiles à mesurer, s’améliorent : la charge cognitive des utilisateurs, provoquée par un logiciel mal conçu, est réduite. Lorsque l’on regarde de plus près, un designer est toujours présent dans ces processus. Il a compris les enjeux, aligné les participants, donné une forme a des idées, documenté, expliqué, amélioré.

Cette position, un peu dedans, un peu dehors, est parfois mal comprise. C’est peut-être cette difficulté constante à positionner un designer dans une organisation qui explique les changements de noms successifs pour les désigner, dans l’industrie du numérique : webdesigner, interaction designer, designer de services, user experience designer, customer experience designer, UX/UI designer, visual designer, product designer, growth designer… Ces titres ont eu plus ou moins de popularité ces dernières années. Ils tentent toujours de circonscrire l’action de celui ou de celle qui donne une forme à ce qui est dans les têtes de chaque participant d’un projet. Pour permettre à ces idées de devenir un produit, qui résout de vrais problèmes pour de vrais utilisateurs.

Donc, voici mes propositions pour l’avenir : augmentateur de résolution, éclaireur, expert en connections, lieur-synthétiseur, éclaireur-facilitateur, séquenceur, metteur en perspective. Les noms des designers changent avec les évolutions technologiques et organisationnelles. Avec l’arrivée massive des outils basés sur l’IA, ce processus continuera probablement, et le rôle du designer mutera. Comme il l’a toujours fait.