J’ai récemment eu l’occasion d’animer un meetup pour la School of PO.
J’y ai partagé mon retour d’expérience sur le rôle de l’UX au sein des équipes produit (10 ans dont 4 en équipes Scrum).
Lors de ce meetup, j’ai proposé une vision élargie de l’UX qui ne se cantonne pas à la production de personae, journeys et design. Un retour à sa mission essentielle : aider le PO à créer de la valeur pour l’utilisateur, tout en limitant les risques pour l’entreprise.
Déroulement du meetup
A la School of PO, les meetups se déroulent toujours en deux volets : une partie talk, puis une partie atelier où les inscrits mettent la main à la pâte. De cette façon on mobilise 3 des 4 piliers de l’apprentissage isolés via les neurosciences :
- L’attention sélective lors du talk (si l’animateur joue bien son rôle 😉). Aidée par le format court du talk qui dure maximum 25 minutes (ou 1 pomodoro 🍅).
- L’engagement actif lors de l’atelier. Les inscrits confrontent immédiatement ce qu’ils viennent d’apprendre à une mise en oeuvre pratique.
- Le retour d’information lors de l’atelier. L’animateur est là pour aiguiller les inscrits, les aider à surmonter l’erreur et l’incertitude, et les renforcer positivement.
- La consolidation ne peut pas se faire sur une durée aussi courte, reste aux inscrits à mettre en oeuvre ce qu’ils ont appris dans leur vie professionnelle.
Le talk
Le point de départ de mon talk était très simple et tiré de l’expérience : UX, c’est LE job à la mode. Tous les POs en veulent dans leur équipe, mais sont-ils vraiment prêts à travailler avec eux ? Est-ce que l’arrivée d’un UX dans l’équipe crée magiquement de la valeur pour l’utilisateur ? Spoiler : NON.
Le constat
- Ce que le PO attend a priori de l’UX est réduit à la fin : la forme, la maquette, au risque de passer à côté du fond.
- Le PO, cédant à la pression et à la politique de l’entreprise, ne donne pas toujours les moyens à l’UX de remplir sa mission : aller à la rencontre des key users, faire émerger des besoin du terrain, itérer, voire pivoter.
L’iceberg UX
J’ai formalisé ma vision de manière visuelle. La conception commune du métier d’UX s’arrête à la partie émergée de l’iceberg :
- Optimisation
- Manipulation
Mais si l’on se contente d’optimiser un produit qui n’a pas de valeur pour l’utilisateur, est-ce que l’on se préoccupe réellement de son expérience ? Pour moi non.
Mon tunnel d’achat aura beau être user friendly, si je vends un produit dont personne ne veut, mon produit n’a pas de valeur. Je suis passée à côté du besoin de l’utilisateur. Je n’ai pas bien conçu mon produit, j’ai omis de faire valider mes hypothèses.
L’UX, ça coûte de l’argent. Mais ça en fait surtout gagner.
Il ne faut pas opposer expérience utilisateur et intérêt business de l’entreprise. Ce n’est pas par pur altruisme que les sociétés se sont intéressées aux besoins des utilisateurs. C’est parce que ce sont eux qui les font vivre.
- Dans le cas d’un produit digital BtoC ou BtoB, un produit qui n’a pas de valeur pour l’utilisateur ne rapportera pas d’argent à l’entreprise.
- Dans le cas d’un produit digital BtoE, un produit qui n’a pas de valeur fera fuir ses ressources humaines. Et aussi perdre de l’argent à l’entreprise (conception et maintien de features inutiles, etc.)
Commencer par les fondations
Dynamique d’équipe
Accepter l’échec
Concevoir un produit, ce n’est pas produire quelque chose. C’est avant tout accepter de se poser les bonnes questions. Cela implique d’accepter l’échec, d’accepter de changer d’hypothèses suite à des feedbacks users, d’accepter de privilégier l’intelligence collective.
Sans cela, on voit bien que l’implication des utilisateurs dans la conception du produit reste à la surface. Il m’est arrivé de penser que parfois c’est simplement utilisé comme com’ interne à l’entreprise. « Regardez, mon service est plus innovant que le vôtre, je fais de l’UX ». Et après ? Si les feedbacks utilisateurs n’ont aucun impact sur le produit parce que l’équipe n’accepte pas de jeter à poubelle un travail, (si, si !) autant ne pas faire d’UX research.
D’où l’intérêt de faire tester ses hypothèses par les utilisateurs le plus rapidement possible, pour éviter de tomber dans le piège du sunk cost fallacy.
Qui fait quoi?
Pour que l’équipe soit à l’épreuve des échecs, mieux vaut que l’entente entre les membres soit bonne. Cela passe avant tout par la transparence sur les rôles.
Les métiers digitaux évoluent très vites. Sont de plus en plus spécialisés mais peuvent être exercés très différemment d’une personne à l’autre. Les rôles agiles sont brandis par des personnes qui ne savent pas trop quoi mettre concrètement derrière.
D’où l’intérêt de clarifier dès la constitution d’une équipe : qui attend quoi de qui ? Dans cette équipe, avec ces personnes, qu’est-ce qu’on met concrètement derrière ces intitulés ? L’atelier Scrum roles & responsibilities est parfait pour initier cette discussion. Pour souder l’équipe et lui permettre d’accepter les questions / décisions qui fâchent.
Conception
Vision produit transparente & itérative
Il m’arrive souvent d’arriver dans des équipes produits qui n’ont pas réfléchi à la vision. Comprendre : l’équipe n’a pas identifié quel problème le produit allait résoudre pour quel utilisateur. Un changement d’architecture technique, une demande du N+1, ce ne sont pas des visions produit.
Pour moi, la vision produit doit :
- partir d’une problématique utilisateur, afin de concevoir un produit qui a de la valeur,
- être partagée avec toute l’équipe produit de manière transparente, afin de donner sens au travail de l’équipe,
- être itérative, c’est-à-dire évoluer en fonction des feedbacks users (on s’est peut-être trompés au départ).
Valeur du projet & mesures
L’UX est là pour aider le PO à concevoir un produit qui a de la valeur. Encore faut-il pouvoir mesurer cette valeur. Fixer un objectif mesurable de manière quantitative est intéressant à deux niveaux :
- démontrer la valeur du travail de l’équipe. Augmenter la motivation et avoir la confiance / les budgets de l’organisation pour continuer à travailler.
- prioriser les features du produit. Les PO enthousiastes veulent toujours en faire le maximum et diluent ainsi l’efficacité et la valeur du produit. On n’a jamais le temps et le budget pour tout faire. Autant commencer par ce qui a le plus de valeur.
Deux outils redoutablement efficaces : Product Vision Board et Impact Mapping.
Priorisation
Elle intervient à tous les niveaux et tout au long du projet :
- Priorisation des personae, des objectifs mesurables, des features.
- Priorisation des stories, redécoupage, respécification.
Si l’on veut pouvoir reprioriser tout au long du projet à partir du retour d’expérience terrain (test utilisateurs, mises en prod…), il faut avoir une vision. Sinon, sur quoi se baser ? Un verbatim utilisateur isolé, une intuition de l’équipe : c’est une mauvaise idée. On risque de s’engouffrer sans réfléchir dans une solution sans s’être posé les bonnes questions au préalable.
Les outils cités plus haut ont la vertu de faire prendre du recul à l’équipe, lui faire sortir la tête du guidon pour concevoir quelque chose qui répond à un vrai besoin. On peut se tromper en début de projet. Ce n’est pas grave, on peut recommencer en cours de projet. Refaire une storymap, faire un Design Sprint pour débloquer une situation, si l’on se sent perdu. Tout sauf paniquer et produire quelque chose juste pour avoir un livrable.
Outils UX utiles
- Design sprint, Framing ou Sprint 0 avec toute l’équipe
- Storymap
- Impact map
- Proto Personae / Personae
- Experience map
- Ebauche des features prioritaires : flows, sketches, wireframes
Validation
Vérifier vite et souvent
- L’équipe s’est investie émotionnellement dans la conception et la production d’une feature (développée ou sous forme de prototype).
- L’entreprise a dépensé de l’argent pour payer l’équipe.
Autant tester le plus rapidement possible nos hypothèses, si l’on veut avoir une chance de les jeter, donc de vraiment intégrer les retours utilisateurs à la conception du produit. Sinon on va se heurter au sunk cost fallacy / escalade de l’engagement et refuser les retours utilisateurs.
Comment faire pour tester vite et souvent ? Ce n’est pas forcément compatible avec du test utilisateur traditionnel, long et coûteux. Spoiler : la démo ne vaut pas un test utilisateur.
Tester avant de développer
Via des sketches ou prototypes interactifs, Guerilla test, Usability testing, Tri de cartes…
Si c’est déjà développé, pourquoi ne pas faire mieux qu’un test : une mise en production ? Et éviter ainsi le risque d’illusion de validité qui va de pair avec les tests utilisateurs.
Choisir ce que l’on teste
Oui : l’architecture de l’information, un cas d’usage concret, une feature identifiée comme ayant beaucoup de valeur…
Non : un feedback sur du design ou sur de l’UX. C’est subjectif, ce n’est pas le métier de l’utilisateur. Il faut faire confiance à l’expertise des UX & UI sur les conventions d’utilisation, la psychologie appliquée au design, le design émotionnel et d’interfaces. Ils ont fait des études pour ça, ils font de la veille. Si, si.
Optimiser les hypothèses validées
Optimisation
Le rôle de l’optimisation UX
Le travail d’optimisation UX est important pour :
- faire adopter un nouveau produit, une nouvelle version,
- se démarquer par rapport à la concurrence.
Comment faire concrètement ?
- Utiliser la psychologie appliquée au digital pour améliorer l’expérience utilisateur : diminution du temps ressenti, gamification, reward, mascotte, design émotionnel…
- Itérer tout au long du développement produit.
Surtout, surtout, ne pas hésiter à retourner à une phase de conception si l’on se rend compte que des wireframes ont été faits sans vraiment réfléchir à la valeur du produit pour l’utilisateur.
Manipulation
Le rôle de la manipulation
La manipulation est utile pour arriver aux fins business de l’entreprise mais n’est pas forcément dans l’intérêt de l’utilisateur. Elle peut aider par exemple à :
- déclencher un acte (achat…),
- récolter des données utilisateur (formulaire…).
Comment faire concrètement ?
- Psychologie orientée manipulation (récompense, rareté…). Très utilisée dans les jeux freemium par exemple.
- A utiliser avec précaution. Cela peut avoir un effet contre-productif si c’est mal dosé ou utilisé sur le mauvais persona. Bref, si ça se voit !
L’atelier
L’atelier était basé sur un cas de conception produit concret. L’idée était de faire travailler de petits groupes sur la conception produit basée sur de l’UX research et des objectifs business pour identifier une problématique, plutôt que de se jeter sans réfléchir dans de la production de features / wireframes. Ca a bossé dur ! Et l’échange qui a suivi était très intéressant.