Transformer l'incertitude en direction produit.
Un programme Discovery mondial fondé sur les données, qui a transformé une information fragmentée en une direction produit validée, avant qu'une seule ligne de code ne soit écrite.
Paysage des systèmes montrant les plateformes opérationnelles, les services de diagnostic et les sources de données qui alimentent l'écosystème produit plus large.
Aperçu du projet
Un programme Discovery connecté, et non une série d'activités de recherche isolées.
Le défi, en bref
Les personnes gérant les comptes grands clients étaient submergées par une information fragmentée : les alertes critiques étaient dispersées entre de multiples systèmes internes, chacun affichant des informations différentes à des moments différents, avec peu de cohérence sur la manière dont le travail devait réellement être priorisé. La direction pensait qu'une assistance intelligente pourrait aider, mais rien ne prouvait que c'était la bonne réponse, ni que les gens lui feraient assez confiance pour l'adopter. Plutôt que d'engager un investissement d'ingénierie sur simple hypothèse, le programme a d'abord cherché à réunir des preuves.
Plutôt que d'engager un investissement d'ingénierie sur simple hypothèse, il nous fallait d'abord des preuves.
“Nous avons plus d'informations qu'une banque ! Il y a des insights que nous n'avons pas le temps de vérifier. Nous devrions réduire, remplacer et centraliser, car les insights sont désagrégés dans différentes sources.”
Mon rôle, en bref
J'ai dirigé le chantier UX pour l'ensemble du programme, responsable de transformer l'incertitude organisationnelle en une direction produit validée. J'ai planifié et dirigé un effort de discovery en plusieurs phases couvrant cinq régions mondiales, modérant personnellement la majorité des entretiens, ateliers et sessions d'utilisabilité, et j'étais responsable de la forme de la solution de bout en bout : service blueprints, modèle d'interaction, architecture de l'information et exigences fonctionnelles produit sur lesquelles le concept a été construit.
Impact, en bref
Sur 5 régions mondiales, le programme a réuni des preuves à partir de 100 entretiens initiaux, 190 participants et 260 réponses aux enquêtes, puis a validé la direction au travers de 40+ sessions d'évaluation de prototypes et 5 Preuves de Concept codées. Il s'est conclu par une direction produit validée, un modèle de priorisation fondé sur des preuves, des service blueprints de l'état futur et des exigences fonctionnelles produit — apportant une confiance exécutive fondée sur des preuves mondiales plutôt que sur des hypothèses, sans engager d'abord un investissement d'ingénierie sur simple hypothèse.
Le défi
Ce programme n'a pas commencé avec l'IA. Il a commencé avec les personnes gérant les comptes grands clients, et les équipes plus larges qui les soutenaient, submergées par une information fragmentée.
Les alertes critiques étaient dispersées entre de multiples systèmes internes, chacun affichant des informations différentes à des moments différents, avec peu de cohérence sur la manière dont le travail devait réellement être priorisé. Les utilisateurs rencontraient fréquemment des informations incohérentes en passant d'un outil opérationnel ou d'une source de données à l'autre, comparant manuellement les rapports et décidant ce qui méritait d'être traité en premier.
La direction pensait qu'une assistance intelligente pourrait aider, mais rien ne prouvait que c'était la bonne réponse, ce qu'elle devait réellement faire, ni que les gens lui feraient assez confiance pour l'adopter.
Plutôt que d'engager un investissement d'ingénierie sur simple hypothèse, il nous fallait d'abord des preuves.
La tâche à venir dépassait la simple conception d'une interface. Il s'agissait de comprendre comment les gens travaillaient réellement selon les régions, les types de clients et les modèles économiques, avant de décider ce qui devait, le cas échéant, être construit.
Mon rôle
J'ai dirigé le chantier UX pour l'ensemble du programme, responsable de transformer l'incertitude organisationnelle en une direction produit validée, et non simplement de produire de la recherche ou de concevoir des écrans.
Sur l'ensemble du programme, j'ai planifié et dirigé un effort de discovery en plusieurs phases couvrant cinq régions mondiales, modérant moi-même personnellement la majorité des entretiens, ateliers et sessions d'utilisabilité. Lorsque la langue ou l'expertise locale rendait cela impraticable, j'ai dirigé des facilitateurs régionaux tout en restant responsable de la synthèse et du jugement, afin que le niveau d'exigence des preuves reste constant partout où le programme s'est déroulé.
Au-delà de la recherche, j'étais responsable de la forme de la solution de bout en bout : transformer des flux de travail fragmentés en service blueprints, définir le modèle d'interaction et l'architecture de l'information, et traduire les preuves en exigences fonctionnelles produit sur lesquelles le concept a été construit. Sans capacité d'ingénierie interne disponible, je me suis associé à une société d'ingénierie externe pour convertir cette direction en Preuves de Concept codées sur quatre plateformes. J'ai également dirigé le nom et l'identité visuelle du concept, et synthétisé l'ensemble du programme dans la recommandation exécutive sur laquelle la direction a finalement agi.
Chaque étape a délibérément réduit l'incertitude avant de passer à l'investissement suivant.
Le parcours en dix étapes derrière les cinq chapitres qui suivent.
Information fragmentée, pas encore de preuve pour une solution.
Comprendre le problème avant de concevoir quoi que ce soit.
Cartographier chaque système alimentant le flux de travail actuel.
Comprendre le service avant de concevoir l'interface.
Tester si le concept lui-même inspirait confiance.
Itérer le prototype face à des preuves réelles.
Comprendre comment les gens jugent réellement l'urgence.
Transformer ce raisonnement en modèle, pas en supposition.
Tester l'implémentation avant l'investissement réel.
Direction fondée sur les preuves, pas l'option la plus exaltante.
Discovery et recherche utilisateur
Comprendre le problème avant de concevoir une solution. Ce que ce chapitre a éliminé : l'incertitude sur le problème lui-même.
Notre premier objectif était de remettre en question les hypothèses plutôt que de les confirmer. À travers des entretiens, des enquêtes et des ateliers dans toutes les régions, nous avons exploré comment les gens géraient réellement des demandes concurrentes, et où se situait la véritable friction.
Le problème n'était pas simplement « trop d'alertes ». C'était une prise de décision fragmentée.
Les entretiens et les ateliers ont révélé des différences significatives selon la région, le type de client et le rôle : certains collègues géraient un seul compte stratégique, d'autres géraient des centaines de comptes répartis sur des centaines de sites. Ce sont ces différences, et non un seul persona moyen, qui ont ensuite façonné chaque décision suivante. Ce chapitre a également révélé des problèmes que le business case initial n'avait pas anticipés, au premier rang desquels l'information dupliquée, une communication inefficace et la fatigue décisionnelle.
“Nous avons plus d'informations qu'une banque ! Il y a des insights que nous n'avons pas le temps de vérifier. Nous devrions réduire, remplacer et centraliser, car les insights sont désagrégés dans différentes sources.”
Cartographie d'affinité et synthèse des résultats de recherche utilisées pour identifier les schémas comportementaux, les points de friction opérationnels et les zones d'opportunité qui ont informé l'expérience de l'état futur.
Cartographier l'écosystème
Concevoir le service avant de concevoir les écrans. Ce que ce chapitre a éliminé : l'incertitude sur la manière dont les alertes devaient se comporter sur l'ensemble du service.
Avant de concevoir une seule interface, j'ai cartographié comment les alertes circulaient dans l'organisation, en retraçant plus de trente types d'alertes opérationnelles à travers de multiples systèmes, rôles utilisateurs et processus métier. Cela a révélé où l'information prenait naissance, comment elle circulait entre les équipes, et où les utilisateurs rencontraient une complexité inutile.
Plutôt que d'optimiser des écrans individuels, j'ai conçu le service de l'état futur lui-même. Ce travail a établi une architecture de service évolutive couvrant à la fois les alertes sensibles au temps et non sensibles au temps, en définissant des comportements cohérents, des points de décision, des processus en coulisses, des responsabilités opérationnelles et des parcours utilisateurs avant même que la conception d'interface ne commence.
Ce n'est pas parce que l'organisation pouvait générer une alerte que l'utilisateur devait la recevoir.
“J'aurais du mal à traiter 89 alertes… cela n'arriverait tout simplement pas.”
Ces service blueprints sont devenus la référence partagée pour Produit, Ingénierie et Design, alignant tout le monde sur la manière dont le service devait fonctionner avant de décider de son apparence.
Sensibilité temporelle et priorité
L'une des découvertes les plus significatives de la recherche fut que le problème n'était pas simplement le nombre d'alertes reçues par les utilisateurs.
Le véritable défi consistait à comprendre quelles alertes nécessitaient réellement une attention, quand elles nécessitaient une action, et ce que les utilisateurs étaient censés faire ensuite.
J'ai élaboré une stratégie d'alertes pour l'état futur couvrant à la fois les alertes sensibles au temps et non sensibles au temps, établissant une relation cohérente entre urgence, priorité et comportement utilisateur avant même que la conception d'interface ne commence.
Ces principes sont devenus le fondement du cycle de vie des alertes, du cadre de priorisation et du service blueprint de l'état futur.
Découvrir le cadre du cycle de vie des alertes
Documentation complémentaire issue du programme de conception de service.
Points clés du Service Blueprint
- Service blueprint de l'état futur couvrant les alertes sensibles au temps.
- Définition des interactions visibles, des processus en coulisses et des responsabilités opérationnelles.
- Standardisation du cycle de vie des alertes sur de multiples systèmes d'entreprise.
- Identification des lacunes de service, des points de friction opérationnels et des opportunités avant l'investissement d'ingénierie.
- Établissement de schémas de service réutilisables qui ont informé chaque interface ultérieure.
Ce principe est devenu le fondement de chaque décision de conception qui a suivi.
Valider le concept
Valider le concept tôt. Ce que ce chapitre a éliminé : l'incertitude sur la justesse du concept lui-même.
Avant tout investissement d'ingénierie, j'ai testé un prototype interactif au travers de sessions modérées combinant un laboratoire d'utilisabilité en présentiel et de la recherche à distance dans toutes les autres régions.
L'objectif n'a jamais été de valider une interface. Il s'agissait de savoir si les gens faisaient confiance au concept.
“Tout est dans une vue d'ensemble et ce sera comme une vue à vol d'oiseau.”
“Pour moi c'est parfait parce que c'est court, direct, ça va droit au but. Je ne veux pas devoir cliquer sur chaque notification. Donc pour moi ça me dit exactement ce que c'est, pour qui, ce que c'est, quel est le problème. Donc je le vois tout de suite.”
Les gens avaient besoin de comprendre la logique derrière la priorisation et de sentir réellement qu'elle réduisait leur effort, une preuve qui a façonné l'itération suivante bien avant qu'une seule ligne de code ne soit écrite.
Recherche utilisateur modérée : comprendre l'appétence et les besoins des utilisateurs pour un système centralisé unique, au travers d'une recherche modérée combinant un laboratoire d'utilisabilité en présentiel et de la recherche à distance.
Tests d'utilisabilité en présentiel
J'ai planifié, construit et dirigé le premier programme de tests d'utilisabilité en présentiel et à distance de l'organisation : recrutement, conception du prototype, animation et entretiens, jusqu'à l'observation, la synthèse et la réinjection directe des résultats dans la conception produit.
Recherche utilisateur à distance
Sessions de recherche modérées à distance utilisées pour valider des concepts avec des participants de multiples régions, permettant un retour rapide et un affinement itératif tout au long du processus de conception.
Concevoir le modèle de décision
Ce que ce chapitre a éliminé : l'incertitude sur la manière dont les priorités concurrentes devaient réellement être arbitrées.
Une question restait sans réponse : quand plusieurs choses réclamaient l'attention en même temps, que devait décider le système de faire remonter en premier ? Plutôt que d'y répondre nous-mêmes, nous avons construit un programme de recherche dédié à la priorisation : des ateliers qui ont révélé comment les gens raisonnaient sur l'urgence, le risque, l'impact client et l'effort, suivis d'une enquête qui a validé ces schémas à grande échelle.
Le résultat n'était pas une autre interface. C'était un modèle de décision fondé sur les preuves.
“Peut-être que si vous êtes le manager et que vous voyez que c'est une alerte haute priorité, vous pouvez assigner une tâche à vos équipes ?”
Ce modèle est devenu la logique derrière le moteur de priorisation intégré à la Preuve de Concept. Il a également révélé une véritable variation régionale, apparue au travers des ateliers et de l'enquête plutôt que d'un quelconque test visuel : certains marchés pondéraient davantage la taille du client, d'autres le risque contractuel. Cette preuve a directement façonné la manière dont une future version du modèle pourrait s'adapter par région et par rôle, plutôt que d'imposer une seule règle à tout le monde.
Ateliers de priorisation
J'ai planifié et animé des ateliers de priorisation transverses autour des besoins utilisateurs, de la valeur opérationnelle et des priorités métier.
Les résultats de ces ateliers ont aidé à définir les exigences qui ont finalement alimenté l'algorithme de priorisation et la future stratégie d'alertes.
Ateliers de priorisation transverses ayant aidé à définir les exigences pour le futur algorithme de priorisation.
Confiance en l'ingénierie
Valider l'approche d'ingénierie. Ce que ce chapitre a éliminé : l'incertitude sur la manière dont le concept devait réellement être construit.
Ce n'est qu'une fois le concept lui-même validé que le programme est passé aux Preuves de Concept codées. En partenariat avec une équipe d'ingénierie externe, j'ai traduit la direction UX en versions fonctionnelles sur quatre plateformes, jamais destinées à être un logiciel de production, mais conçues comme un moyen de tester des approches d'implémentation avant d'engager un investissement d'ingénierie interne.
Plusieurs concepts codés ont été évalués. Les gens préféraient systématiquement l'expérience mobile autonome, mais les preuves racontaient une autre histoire : la plupart travaillaient principalement depuis des ordinateurs portables, beaucoup n'avaient pas de téléphone fourni par l'entreprise, et une application séparée resterait probablement inutilisée.
“Je trouve vraiment intéressant que ce soit dans le même système que celui que nous utilisons déjà…”
Ce n'était pas l'option la plus exaltante. C'était l'option la plus susceptible de réussir.
Cette recommandation est la preuve la plus claire de l'objet même du programme : le jugement, fondé sur les preuves, plutôt que la préférence personnelle.
Valider des preuves de concept codées : retours clients sur l'utilisabilité, la désirabilité et l'adéquation opérationnelle avant l'investissement d'ingénierie.
Résultat
Le programme a réussi, non pas en livrant du logiciel, mais en éliminant l'incertitude qui aurait fait de la livraison de logiciel un pari.
Ce qu'il a livré, c'est une direction produit validée, un modèle de priorisation fondé sur les preuves, des service blueprints de l'état futur, des exigences fonctionnelles produit, des Preuves de Concept fonctionnelles et, surtout, une confiance exécutive fondée sur des preuves mondiales plutôt que sur des hypothèses.
Voir plus en détail : Utiliser la recherche et les données pour guider le design (PDF) →
De l'incertitude à la direction produit.
Le programme s'est conclu par un film de concept qui a rassemblé des mois de recherche, de priorisation et de validation en une seule vision destinée aux parties prenantes. Plutôt que de présenter des fonctionnalités isolées, il a démontré comment les preuves avaient façonné chaque aspect de l'expérience proposée.
Une note de bas de page sur le nom : ce programme a commencé sa vie sous le nom « Digital Co-Pilot » — avant que le Copilot de Microsoft n'existe, comme il se trouve. Lorsque la collision de noms est devenue inévitable, j'ai dirigé le rebranding vers Nexa, façonnant le nouveau nom et la nouvelle identité aux côtés du travail produit ci-dessus.
Vidéo de révélation du concept : vision exécutive démontrant la direction produit validée, le modèle d'interaction et l'approche de priorisation.
Ce que cela démontre
Un bon discovery ne prouve pas qu'une idée est juste. Il donne à une organisation suffisamment de preuves pour prendre une décision en confiance, quelle que soit cette décision.
Le programme a commencé par comprendre l'information fragmentée et la prise de décision. Ce n'est que plus tard que l'assistance intelligente est apparue comme une capacité possible au sein de la direction validée, jamais comme la raison d'être du travail.
La plus grande valeur ici n'a jamais été l'interface. C'était de transformer l'ambiguïté en une décision qu'une organisation pouvait réellement assumer.
C'est le travail d'un Designer Produit Principal : jugement stratégique, pensée systémique et la discipline de recommander ce qui réussira réellement, et non simplement ce qui est le plus exaltant à construire.
Découvrez la même discipline appliquée à une autre échelle.