“Design moi une appli métier” (3/3) Le co-design, facteur clé de succès
Fruit de l’expérience acquise au travers des projets menés à l’Experience Center de PwC, “Design moi une appli métier” est une série d’articles consacrée aux applications métiers dans les entreprises. Après avoir étudié en quoi ces applications pouvaient jouer un rôle stratégique dans les entreprises, et montré que le (re)design d’applications métiers ne se limitait pas à l’ergonomie d’interface, nous verrons dans ce troisième (et dernier) article pourquoi nous avons fait du co-design la clé de voûte de notre approche méthodologique.
S’immerger pour mieux comprendre
Bien que l’UX (User eXperience) et les approches centrées utilisateurs ne cessent de se développer depuis plusieurs années, il ne se passe pas un projet sans que l’on entende, de la part de l’un ou l’autre de nos interlocuteurs, l’objection suivante: “pas besoin de demander leur avis aux utilisateurs, on connaît déjà leurs besoins.” … Dans la grande majorité des cas, cette “connaissance” repose non pas sur des observations issues du terrain mais sur des opinions, sur une vision plus ou moins déformée de la réalité des utilisateurs (ici, les collaborateurs d’une entreprise).
Pourtant, l’expérience nous montre que la recherche utilisateur joue un rôle critique quand il s’agit de comprendre l’expérience d’un collaborateur… Voire encore plus critique que dans le cas d’une expérience client (BtoC), qui dans des secteurs tels que le e-commerce présentent des caractéristiques assez similaires d’une entreprise à l’autre (trouver facilement le produit que l’on cherche, bénéficier de modalités de paiement/livraison/renvoi simplifiées, …).
Pour cette raison, nous débutons toujours nos projets par une phase de recherche utilisateur, laquelle prend diverses formes: shadowing, observation in-situ, interviews sur le lieu de travail, etc. Durant cette phase d’immersion, il s’agit de capter tout un ensemble d’informations sur la manière dont les collaborateurs effectuent leurs tâches, s’organisent et échangent avec leurs interlocuteurs (collègues, clients, prestataires, …), interagissent avec leur environnement de travail (espaces, matériel, outils digitaux, …). Afin de ne pas biaiser les observations et retours des utilisateurs, nous adoptons une posture à l’égard des collaborateurs qui leur permet soit d’oublier notre présence (dans le cas d’observation terrain), soit d’instaurer un climat de confiance (en favorisant des échanges individuels, en l’absence des pairs ou des supérieurs).
“ La recherche utilisateur permet de dépasser les préjugés qui préexistaient, de donner plus de profondeur à des insights caricaturés, et plus généralement de faire remonter des éléments qui n’avaient pas été identifiés (ou mal identifiés) jusque-là. “
Une fois la matière récoltée, notre travail consiste à retranscrire les points saillants de l’expérience, sous diverses formes (personae, user journeys, mappings, etc.). Nous cartographions ainsi les usages actuels, mais aussi et surtout les points de tension, les attentes majeures, voire les stratégies de contournement adoptées par les collaborateurs ! Toutes ces informations sont ensuite présentées à l’ensemble des parties prenantes du projet afin d’offrir une compréhension commune des enjeux, de dépasser les préjugés qui préexistaient, de donner plus de profondeur à des insights caricaturés, et plus généralement de faire remonter des éléments qui n’avaient pas été identifiés (ou mal identifiés) jusque-là.
Ainsi, le fait d’avoir observé et échangé avec des techniciens en charge de la gestion du réseau électrique français nous a permis de réaliser que ces derniers ne pouvaient exercer leur métier dans de bonnes conditions à cause des outils dont ils étaient dotés. D’un part, ces techniciens ne disposaient pas de tous les outils dont ils avaient besoin: n’ayant pas de solution dédiée, ils étaient contraints d’utiliser Google Maps pour cartographier les anomalies et pannes de réseau ! D’autre part, ils devaient jongler entre de nombreux supports (documents “papier”, téléphone, ordinateur fixe). Nous avons ainsi conçu une application permettant d’enrichir et de centraliser tous leurs usages au même endroit, sur une tablette, afin de répondre à leur contexte de mobilité quotidienne.
De même, nous complétons notre recherche utilisateur par une phase d’immersion “technique”, au cours de laquelle nous rencontrons les équipes IT afin de mieux comprendre l’écosystème d’outils digitaux et l’architecture technique sous-jacente.
L’objectif est triple. D’abord, cela permet au designer de se placer dans une posture ouverte et constructive vis à vis des développeurs, qui considèrent souvent les designers (parfois à juste titre) comme ceux qui proposent des choses sexy mais totalement irréalisables. Ensuite, elle conduit souvent à comprendre les raisons pour lesquelles telle ou telle contrainte technique a conduit à la dégradation de l’expérience côté collaborateur. Enfin, elle permet de faire un état de l’art de tout ce que la technologie de l’entreprise peut offrir, dans le but d’imaginer de nouvelles solutions jusqu’ici inexplorées. L’idée ici, c’est d’explorer toute la face immergée de l’iceberg afin de faire le lien avec sa face visible (le quotidien des collaborateurs).
Ainsi, dans le cadre d’un projet pour un assureur, nous avons passé du temps en immersion avec l’équipe de développeurs afin de comprendre comment fonctionnait l’arbre de décision et le moteur de calcul utilisé pour déterminer le pricing des produits d’assurance proposés par l’entreprise. Cette compréhension fine du fonctionnement technique nous a ainsi permis de proposer une interface à la fois intuitive et exhaustive, car l’outil ne devait pas brider les possibilités fonctionnelles pour les collaborateurs qui s’en servaient.
Dans le cas de problématiques non-digitales (matériel, espace de travail, etc.), les échanges peuvent et doivent également ne pas se limiter aux équipes IT, mais aussi s’étendre aux personnes en charge des ressources humaines, des achats, de la maintenance, etc.
Une collaboration absolument nécessaire
En somme, cette phase d’immersion, qui consiste à explorer les différents aspects du projet (humains, organisationnels, techniques), a pour but de proposer une approche véritablement holistique, intégrant tous les points de vue autour de la table. Or, dans le cas des applications métiers, l’expérience nous montre que cette collaboration n’est pas seulement souhaitable: elle est aussi nécessaire, voire indispensable ! La raison en est simple : il s’agit d’outils digitaux tellement spécifiques qu’il est impossible pour un designer de produire une interface réaliste et pertinente en travaillant seul, dans son coin.
Du point de vue fonctionnel, les outils métiers se distinguent des interfaces “grand public” (ex: site e-commerce, médias, espaces clients, …). En effet, le designer ne peut pas se projeter et “deviner” les besoins fonctionnels, leur importance relative (ce qui est prioritaire et doit être facilement accessible vs ce qui est secondaire) ou encore la meilleure façon de l’exécuter… Seuls des échanges quotidiens avec les utilisateurs permettront d’obtenir ces informations (inventaire des contenus et fonctionnalités), puis de sélectionner un concept d’interface qui sera ensuite affiné dans les moindres détails par des propositions et itérations successives.
“ Contrairement aux interfaces “grand public”, les applications métiers sont des outils digitaux tellement spécifiques qu’il est impossible pour un designer de produire une interface réaliste et pertinente en travaillant seul, dans son coin. “
Ainsi, nous n’aurions jamais été en mesure de créer l’outil idéal de suivi d’actifs financiers si nous n’avions pas travaillé main dans la main avec des spécialistes, conseillers financiers et traders pour comprendre quelles étaient les actions et les informations/données les plus importantes à traiter dans le cadre de leur métier.
De même, le designer ne sera pas en mesure de proposer un design réaliste s’il ne collabore avec les développeurs et responsables IT de l’organisation, qui détiennent toute la connaissance relative à l’architecture technique, aux autres outils et données disponibles. Or, ces différentes informations se révèlent cruciales lorsqu’il s’agit de déterminer si une nouvelle fonctionnalité est envisageable, s’il existe un trigger technique pour générer une alerte ou encore si l’entreprise dispose d’un certain type de donnée qui pourrait être remontée dans un tableau de bord ou un document de reporting. En l’absence de telles informations, le designer pourra proposer un écran attractif pour les utilisateurs, mais irréalisable d’un point de vue technique… Ce qui se révèle déceptif et contre-productif !
C’est pourquoi les designers de l’Experience Center de PwC collaborent toujours de façon très étroite avec les équipes IT de nos clients. Ceci nous permet de mieux connaître les possibilités/contraintes techniques, puis de soumettre des propositions aux développeurs afin de revoir notre copie lorsque les écrans n’étaient pas réalisables. Ce type d’échange s’est révélé décisif lorsque nous avons conçu un écosystème d’outils de conseil en vente immobilière basé sur la data. En effet, il a fallu pour chaque outil déterminer quelles données étaient pertinentes par rapport à des cas d’usages précis, puis mettre en musique ces données (hiérarchisation, scénarisation et visualisation des données sur l’interface) afin de de proposer une expérience de vente immobilière impactante, permettant à l’acheteur de faire un choix éclairé.
De façon plus générale, on peut donc en déduire que le designer n’a pas seulement pour rôle d’imaginer et de produire des solutions ex-nihilo, à la manière d’un artiste ou d’un “créatif”. En réalité, il s’agit aussi et surtout de se positionner comme un sorte de chef de cuisine, qui doit imaginer le meilleur plat possible (une interface) à partir d’ingrédients donnés (besoins fonctionnels), d’ustensiles de cuisine (le back-office et l’architecture technique) et de condiments (les données et bases de données).
Comme souvent en cuisine, la première recette n’est pas la meilleure. Il faut de nombreuses itérations sur l’équilibre des saveurs (la hiérarchisation des fonctionnalités), l’assaisonnement (l’utilisation des données) ou le mode de cuisson (l’utilisation d’un moteur en back-office) pour parvenir au résultat final. Il faut aussi et surtout organiser des dégustations (les tests utilisateurs), pour s’assurer que le plat que l’on vient de créer répond au besoin/désir de celui qui va le manger.
Le design comme élément catalyseur, accélérateur… mais aussi fédérateur !
Si nous préférons nous comparer aux chefs de cuisine plutôt qu’aux artistes, c’est parce que nous avons souvent entendu nos clients nous dire: “c’est vous les designers, c’est à vous de créer la solution”…. Et si c’était plus subtil que ça ?
Dans tous les projets que nous menons au sein d’organisations, le designer n’est pas uniquement là pour fournir un produit fini, mais aussi et surtout pour créer les conditions permettant aux clients de co-construire eux-mêmes la solution qui leur manque. Pour cela, le designer jouer un rôle triple.
Le designer est d’abord un catalyseur. En chimie, le catalyseur produit par sa seule présence une réaction entre deux substances qui, jusque là, ne réagissaient pas l’une par rapport à l’autre: c’est exactement la même chose dans un projet de design. Lorsque les parties prenantes d’un projet (ex: les experts métiers, les développeurs, les reponsables du marketing, …) ne se parlent pas, ou se parlent sans se comprendre ni s’accorder, la magie n’opère pas et le projet reste au point mort. En revanche, si on introduit un designer (= le catalyseur), ce dernier va forcer la rencontre et les échanges entre les différentes parties prenantes afin de déclencher la réaction tant-attendue. Il va également apporter un regard neuf, une forme de fraîcheur et de recul qui permettra aux clients de considérer les enjeux/solutions sous un nouvel angle.
“ Le designer n’est pas uniquement là pour fournir un produit fini, mais aussi et surtout pour créer les conditions permettant aux clients de co-construire eux-mêmes la solution qui leur manque. ”
En plus de produire une réaction, le designer joue également le rôle d’accélérateur au sein de l’entreprise. Pour cela, les ateliers de cadrage permettent de raccourcir au maximum les circuits décisionnels et modalités de validation au sein de l’entreprise: ce qui auparavant prenait des semaines (voire des mois) se retrouve condensé en quelques jours ! Et ces principes s’appliquent également lors de la phase de production des écrans: nous structurons nos projets sous forme de “design sprints”, dont le but consiste à produire un nombre défini d’écrans dans un temps limité (1 à 2 semaines): une fois le sprint terminé, nous passons aux écrans du sprint suivant, et ainsi de suite.
Toutefois, cette rapidité ne se fait pas au détriment de la collaboration: les sprints se composent de courtes réunions quotidiennes permettant de présenter le travail réalisé la veille, de lister les retours pour proposer une nouvelle version dès le lendemain. A titre d’exemple, nous avons réalisé, testé et validé plus de 150 écrans en l’espace de 2 mois pour l’un de nos clients, en faisant dialoguer au quotidien une grande variété de parties prenantes (développeurs, designers internes, experts métiers/utilisateurs, business analysts, …)
Pour toutes ces raisons, nous observons que le designer joue finalement un rôle de “fédérateur” au sein de l’organisation où il intervient. Parce que nous incitons nos clients à échanger, à collaborer, à co-designer, ces derniers se sentent investis dans le projet à titre collectif: ce n’est ni la réussite du designer, ni la réussite de l’IT ou du marketing seul, c’est la réussite de l’équipe projet dans son ensemble ! Fédérer de nombreux acteurs autour d’un projet collectif génère des effets positifs pendant la phase de conception: la dynamique enclenchée s’auto-alimente (ambiance positive = davantage de catalysation et d’accélération).
Cette dynamique garantit également la réussite du projet après la phase de conception pour deux raisons. D’abord, le fait que les utilisateurs concernés par l’outil aient pu participer à l’élaboration de leur propre outil favorise grandement l’adoption de ce dernier dans l’organisation. Ensuite, même lorsque nous terminons le projet et quittons les locaux de nos clients, nous laissons derrière nous les 2 ingrédients qui permettront à nos clients de faire vivre l’outil et de l’améliorer dans le temps. Le premier ingrédient est lié à la connaissance de l’outil (à quoi sert-il ? quels principes régissent son fonctionnement et son utilisation ?), tandis que le second est lié à l’organisation agile (de nombreux clients adoptent le fonctionnement sous forme de sprints et installent une ou plusieurs war rooms, ou salles projets).
Conclusion: 4 principes pour réussir la transformation autour d’un outil métier
En conclusion, l’expérience que nous avons accumulé au fil des projets nous montre que les outils métiers peuvent et doivent jouer un rôle majeur dans la transformation des entreprises. Nous avons tâché de résumer les enjeux et questions majeures en 4 principes clés:
1- Raisonnez en termes de bénéfices
Certes, les outils métiers constituent un investissement (financier, technique et humain) pour l’entreprise, mais les bénéfices sont là: une bonne appli métier rend une entreprise plus efficace, plus attractive auprès des collaborateurs et permet in fine de proposer une expérience client de meilleure qualité.
2- Partez des besoins utilisateurs, et revenez-y sans cesse
Les comportements, besoins et usages liés à un métier ne sont pas des choses qui se devinent: cela s’observe et s’analyse. Si vous voulez identifier les vrais problèmes à résoudre, prenez le temps de comprendre vos collaborateurs. Si vous voulez vous assurer que la solution que vous construisez est pertinente, testez-là auprès d’eux !
3- Valorisez l’apport de l’IT
On associe trop souvent l’IT, les développeurs aux “contraintes techniques”. En prenant le temps de vraiment explorer le fonctionnement et les atouts / savoir faire technologiques de l’entreprise, on découvre souvent des ressources inexploitées, des challenges techniques qui ne demandent qu’à être tentés et relevés !
4- Faites le pari du design et du collectif
On l’a vu, le designer n’est pas qu’un simple producteur de solutions, il contribue à catalyser une organisation, à accélérer un projet et fédérer une équipe. Choisir une approche par le design permet de produire une solution pertinente, réaliste et pérenne dans le temps.
Merci à Antoine NASSER et Valentin SAINT-FRISON pour leur relecture attentive et leur challenge bienveillant.
Pour en savoir plus, n’hésitez pas à nous contacter sur Medium, Linkedin ou par mail / téléphone (antoine.nasser@pwc.com / +33.6.16.33.33.57). Nous serons ravis d’échanger avec vous ! :)
