Quand j'ai rejoint UNOWHY en 2017, l'équipe design était réduite et largement déconnectée du reste de l'organisation. Les décisions sur la direction produit se prenaient dans des réunions où le design n'était pas représenté. Les ingénieurs implémentaient des fonctionnalités à partir de spécifications écrites qui n'avaient jamais été validées auprès des utilisateurs. Les product managers rédigeaient des briefs sans vocabulaire partagé pour cadrer les problèmes utilisateurs. Rien de tout cela n'était inhabituel pour une PME EdTech à ce stade. Mais cela signifiait que l'influence du design se limitait à la phase d'exécution, et cette limitation avait un coût direct sur la qualité des produits.

Six ans plus tard, la situation était substantiellement différente. Le design était présent dans les discussions stratégiques. La recherche utilisateur informait des décisions prises par des équipes qui n'avaient jamais participé à un test utilisateur. Les journaux de décisions tenus par les designers étaient consultés par les ingénieurs et les product managers comme une évidence. Ce changement ne s'était pas produit grâce à un programme de design thinking ou à une initiative culturelle déclarée. Il s'était produit grâce à une série de petites actions concrètes qui s'étaient accumulées en un ensemble différent d'hypothèses partagées.

Pourquoi une culture ne peut pas être installée

L'erreur la plus fréquente dans les démarches de culture design est de traiter la culture comme quelque chose qu'on déclare ou qu'on installe. On organise un atelier de design thinking, on colle des post-its sur un mur, on introduit un framework, et on s'attend à ce que l'organisation ait internalisé une nouvelle façon de travailler. Cela ne fonctionne pas ainsi. Une culture n'est pas un ensemble de croyances que les gens entretiennent. C'est un ensemble d'hypothèses tellement bien établies qu'elles ne nécessitent plus d'être formulées. Ces hypothèses viennent de l'expérience répétée, pas des déclarations.

Cela signifie que construire une culture design requiert de trouver les actions concrètes et répétées qui créeront les expériences à partir desquelles de nouvelles hypothèses émergeront. Non pas des rituels (les rituels sont performatifs), mais de véritables activités de résolution de problèmes que les non-designers se soucient déjà de résoudre, abordées à travers une démarche design.

Commencer par les problèmes qui importent aux non-designers

Le premier atelier cross-fonctionnel que j'ai animé chez UNOWHY n'était pas cadré comme un atelier de design. Il était cadré comme une investigation d'un problème métier : pourquoi les enseignants abandonnent-ils SQOOL Connect après la première semaine d'utilisation ? La question venait du customer success, qui gérait les conséquences. C'était une question dans laquelle l'ingénierie, le produit et la direction avaient toutes un enjeu.

En commençant là, je n'avais pas à convaincre qui que ce soit de la valeur de la pensée centrée utilisateur dans l'abstrait. La valeur était implicite dans la question. L'atelier utilisait des méthodes design (cartographie de parcours, cadrage du problème, synthèse) mais était organisé autour d'un problème que les participants trouvaient déjà important. Les méthodes étaient accessoires. La question métier était le point d'entrée.

Ce principe a gouverné la façon dont j'ai introduit presque chaque pratique design au cours des six années suivantes. Je n'ai jamais commencé par « voici une méthode design qu'on devrait essayer ». Je commençais par « voici un problème avec lequel on lutte tous », puis j'introduisais la méthode comme la façon la plus utile d'y répondre.

Rendre la recherche utilisateur visible

La recherche utilisateur a un problème de visibilité dans la plupart des organisations. Le designer va parler aux utilisateurs, revient avec des insights, et rédige un rapport. Le rapport est lu par un petit nombre de personnes. Les insights sont filtrés et résumés. Au moment où ils atteignent l'ingénierie ou la direction, ils ont perdu la plupart de leur texture.

La chose la plus efficace que j'ai faite pour changer cela a été d'inviter les product managers et les ingénieurs à observer les tests utilisateurs en direct. Non pas de manière formelle et planifiée, mais de manière opportuniste : quand un test avait lieu, j'envoyais un message disant « je teste avec trois enseignants cet après-midi, vous pouvez regarder si vous voulez ». Certaines personnes venaient par curiosité. D'autres venaient parce qu'ils avaient une question précise à laquelle ils voulaient une réponse. Après les premières sessions, les gens commençaient à demander à observer plutôt qu'à attendre d'être invités.

La raison pour laquelle cela fonctionne est que l'expérience observée est qualitativement différente de l'expérience rapportée. Un product manager qui lit « les utilisateurs ont trouvé la navigation confuse » hochera la tête et passera à autre chose. Un product manager qui regarde un enseignant passer quatre minutes à essayer de trouver une fonctionnalité qu'il utilise quotidiennement ressentira cette confusion d'une manière qui façonne ses décisions. En 2021, une session de trente minutes avec trois enseignants a révélé qu'un flux que nous avions prévu de construire ne fonctionnerait pas pour la façon dont les enseignants organisaient réellement leur travail. Cette observation a évité trois semaines de développement sur la mauvaise solution. Le PM qui a assisté à cette session est devenu l'un des plus forts défenseurs de la recherche utilisateur avec lesquels j'ai travaillé chez UNOWHY.

Les journaux de décisions comme mécanisme de lisibilité

L'un des problèmes persistants dans les organisations produit est que les décisions se prennent à l'oral et sont ensuite oubliées. La même question refait surface des semaines plus tard, le même débat se produit, la même conclusion est atteinte, et personne ne remarque que l'organisation est déjà passée par là. C'est coûteux, et cela érode la confiance entre les disciplines parce que chaque équipe travaille à partir d'une version différente de l'histoire.

J'ai introduit une pratique légère de journal de décisions : après toute décision de design significative, je rédigeais une courte entrée documentant ce qui avait été décidé, quelles alternatives avaient été envisagées, quelle preuve utilisateur avait informé le choix, et quelles conditions nous amèneraient à le réexaminer. Les entrées étaient courtes. Trois à cinq phrases, en général. Le but n'était pas de créer un dossier exhaustif mais un dossier consultable.

L'effet secondaire était celui que je n'avais pas pleinement anticipé. Les journaux de décisions rendaient la pensée design lisible pour les autres disciplines. Quand un ingénieur pouvait lire le raisonnement derrière une décision UX et voir qu'elle était fondée sur des observations utilisateurs spécifiques plutôt que sur une préférence esthétique, la nature de la conversation changeait. Les désaccords devenaient plus productifs parce qu'ils portaient sur le fond plutôt que sur l'autorité. « Je vois que tu as fondé ceci sur l'observation enseignante de mars, mais je pense que le cas élève est différent » est une meilleure conversation que « je ne pense pas que ce soit la bonne approche ».

Le test structurel

Il existe un test utile pour savoir si une culture design est devenue structurelle : est-ce que des questions de design émergent dans des conversations où aucun designer n'est présent ? Dans une équipe où la culture design dépend encore de défenseurs individuels, la réponse est non. Des décisions se prennent sans apport du design, et un designer en prend connaissance après coup et doit pousser en retour.

En 2023, six ans après le début de ce travail chez UNOWHY, j'observais le test structurel se réussir régulièrement. Les ingénieurs soulevaient des questions d'utilisabilité dans le sprint planning. Le customer success signalait des problèmes d'expérience utilisateur avant qu'ils n'escaladent. Les product managers cadraient les demandes de fonctionnalités en termes de problèmes utilisateurs plutôt que de spécifications de fonctionnalités. Ces conversations se produisaient sans designer dans la pièce, ce qui signifiait que les hypothèses étaient devenues suffisamment partagées pour fonctionner indépendamment.

Six départements s'étaient impliqués de manière significative dans le processus design sur cette période : technologie, produit, customer success, design, direction et utilisateurs finaux directement. Cette étendue n'était pas le résultat d'une campagne d'évangélisation design. Elle était le résultat de la résolution répétée de problèmes ensemble, d'une manière qui rendait la démarche design utile et lisible pour des personnes qui n'y avaient pas été formées.

Ce qui ne fonctionne pas

Les déclarations descendantes ne fonctionnent pas. Une annonce de la direction selon laquelle « nous sommes une entreprise design-driven » n'a pas de contenu opérationnel. Elle ne change pas ce qui se passe dans les réunions, la façon dont les décisions sont prises, ni ce qui est valorisé dans le travail quotidien. Elle peut signaler une aspiration, mais les aspirations sans pratiques correspondantes restent des aspirations.

Les programmes de formation obligatoires ne fonctionnent pas non plus, du moins pas de la façon dont leurs partisans le croient. La formation peut introduire un vocabulaire et un ensemble de méthodes. Ce qu'elle ne peut pas faire, c'est créer l'expérience répétée de l'utilisation de ces méthodes pour résoudre de vrais problèmes, ce qui est la seule chose qui construit une vraie fluidité. Une formation suivie d'aucun changement dans les pratiques de travail réelles produit des personnes qui peuvent décrire le design thinking mais ne le pratiquent pas. L'investissement est largement gaspillé.

Ce qui fonctionne, c'est trouver les problèmes qui importent aux personnes que l'on cherche à rejoindre, les résoudre ensemble en utilisant des méthodes design, rendre le processus visible, et le faire de manière répétée sur une période suffisamment longue pour que de nouvelles hypothèses aient le temps de se former. Cela requiert de la patience, et cela requiert d'être à l'aise avec une influence qui est indirecte et lente. Mais cela produit quelque chose que les déclarations et les programmes de formation ne peuvent pas produire : un ensemble d'hypothèses partagées qui fonctionnent même quand aucun designer n'est dans la pièce.