Cet article est pour tous les product owners et product managers qu’on a privé de binôme UX.
Tenez bon, les entreprises commencent à entendre raison !
En attendant, voilà deux outils simples qui m’aident à penser mes écrans correctement.
L’UX ce n’est pas que les maquettes
Je suis obligé de faire un court “disclaimer” sur l’UX. Dans beaucoup d’entreprises, l’UX c’est l’UX designer et son métier est réduit à “celui qui produit les maquettes”. Du coup autant prendre un stagiaire, ou donner la responsabilité des maquettes au designer ou au product owner / manager.
Une définition plus correcte serait que l’UX designer c’est “celui qui comprend l’utilisateur et qui rend facile pour l’utilisateur de tirer la valeur de notre produit”. Les maquettes ont un sens et un objectif, elles s'inscrivent dans des parcours. Il faut du temps pour comprendre les utilisateurs, faire de l’immersion et des tests. Il faut aussi du temps pour apprendre à simplifier et clarifier l’expérience. C’est bête à dire, mais c’est un vrai métier à temps plein.
Implicite vs Explicite
Un des enjeux de l’UX, donc, c’est de rendre facile l’utilisation du produit. C’est assez simple quand on fait une page basique, mais, bien sûr, le problème survient avec la complexité : plus le métier et les actions sont complexes, plus vous aurez de mal à garder le focus et plus vos utilisateurs auront de problèmes.
En gros, vous allez avoir deux leviers principaux pour clarifier votre produit : vous reposer sur l’implicite, l’habituel, l’évident. Ou expliquer et former vos utilisateurs pour qu’ils acceptent la complexité.
C’est un arbitrage à faire, chacun des choix a des coûts spécifiques. Soit on prend le temps d’élaguer, on enlève des éléments de notre fonctionnalité. Soit on prend le temps de créer du contenu, du support, de l’accompagnement.
Product Board est un bon exemple : à priori, on ne comprend rien. C’est hyper chargé, ça n’a pas la forme classique des applications.. Vraiment, si on ne me dit rien et qu’on me laisse devant l’écran, ce n’est pas une première expérience agréable.
Pour compenser ça, il y a un énorme tutoriel, pas à pas, pour se guider dans la prise en main de l’outil. C’est une fonctionnalité à part entière.
C’est un choix qu’ils ont fait : leur outil est complexe et plutôt que de sacrifier des fonctionnalités, ils ont décidé d’embrasser cette complexité et de tout miser sur l’explication.
Comment on sait si c’est le bon choix ? Il n’y a qu’une façon : en prenant le temps d’observer et de parler aux utilisateurs. A chaque segment utilisateur. Régulièrement.
En attendant, vous êtes tous seuls devant vos specs et il faut produire des maquettes. Avec les deux outils que je vous propose, vous ne ferez pas le travail aussi bien qu’un UX, mais vous allez réduire franchement le risque de vous planter.
Outil 1 : Valider que la page fonctionne en isolation
On travaille en user stories, on découpe en composants, on passe des semaines sur notre fonctionnalité, elle nous est familière et crac, on tombe dans le panneau : la page dans son ensemble prête à confusion.
C’est dur de s’en rappeler, mais il faut garder ça en tête constamment : l’utilisateur se moque de vos US, de vos fonctionnalités, de vos composants, même de votre produit ! Ce qui l’intéresse, c’est de pouvoir faire facilement ce qu’il souhaite faire. Il ne voit la valeur de votre produit que par le résultat qu’il obtient.
Donc il faut toujours prendre un pas de recul et juger la page dans son ensemble après chaque modification : faciliter l’expérience utilisateur au niveau d’une page, c’est rendre facile pour l’utilisateur d’accomplir les tâches pour lesquelles il est venu sur cette page.
L’outil que j’utilise dans ces cas là n’en est pas vraiment un, en fait ce sont trois questions. C’est une technique que m’a fait découvrir Soreya Mokhtari. C’est très pratique parce c’est simple et qu’il n’y a pas besoin d’un background d’UX pour évaluer une page en suivant cette grille de lecture. Il ne m’en fallait pas plus.
Est ce que je sais de quoi ça parle ?
Est ce que je sais ce que je dois faire ?
Si je me pose une question, est ce qu’il est facile pour moi de trouver la réponse ?
Il faut essayer de se mettre à la place d’un utilisateur qui n’est pas encore habitué de la page. Est ce que c’est vraiment évident ? Ou est ce qu’on comprend parce qu’on travaille sur les écrans depuis un moment ?
Une autre façon de voir les choses c’est de se dire : si on se sent le besoin d’expliquer la page ou une partie de la page, c’est qu’il faut revoir la copie.
Attention à bien vous rappeler que vos utilisateurs ne sont pas une masse générique mais répartis en plusieurs segments. Ils n’interpréteront probablement pas tous vos pages de la même manière.
L’outil est déjà intéressant quand on l’utilise dans son coin, mais on a forcément un biais, on ne peut pas efficacement personnifier l’utilisateur qui découvre la page. Pour un résultat encore meilleur, c’est une bonne idée de faire des tests utilisateurs et de leur poser ces questions à chaque étape (pas littéralement sinon c’est vite lourd !). En général, vu que vous avez fait l’effort avant, ils vont savoir de quoi ça parle et ce qu’il faut faire. Mais quand on leur demande de vocaliser leurs questions, on découvre plein de petits éléments qui pourraient prêter à confusion. C’est votre todo liste.
Vous allez me dire “on n’a pas le temps de faire des tests utilisateurs pour chaque écran” et c’est aussi pour ça qu’on recommande un UX à plein temps dans l’équipe.
Outil 2 : Valider que la page fonctionne dans le parcours
Le travail sur une page en isolation est déjà assez fragmenté, alors vous voyez aisément l’ampleur de la déconnexion quand on traite tout un parcours : il peut s’être passé des années entre la réalisation des éléments du parcours, ou ils peuvent être développés par des équipes différentes.
Donc il y a un travail important mais pas forcément évident à faire à chaque fois que vous apportez une modification à votre produit : est ce que je ne suis pas en train de rendre difficile l’expérience globale de mes utilisateurs ?
Un jour, en feuilletant un livre (Mapping Experiences de Jim Kalbach), je suis tombé sur une représentation de parcours sous la forme d’une carte, l’experience map, et j’ai eu une révélation.
L’idée de l’expérience map, c’est d’afficher le parcours et d’ajouter du contexte à chaque étape. On va donner une continuité aux fonctionnalités : on sait d’où on vient et où on va, on va mettre en avant les changements de contextes, on va faire apparaître l’effort. Bref, en une seule visualisation, on a une grande richesse d’informations qui va nous aider à prendre les bonnes décisions.
Depuis, je me suis mis à utiliser une version simplifiée de la map, et qui comporte les éléments suivants :
- Les étapes majeures
- Les actions à chaque étape
- Les surfaces utilisées à chaque étape (écran, device, api, etc)
- Le contexte (environnement, mood)
Les étapes majeures et les actions sont les éléments fonctionnels de la map : on va pouvoir souvent associer des KPI à chaque étape. Le nombre d’actions à effectuer représente un niveau d’effort pour atteindre le but. En ayant ça sous le nez, on aura tendance à réfléchir à deux fois avant d’ajouter des étapes et des actions.
Afficher les surfaces et le contexte permet de visuellement distinguer au premier regard les ruptures dans le parcours. Un utilisateur au bureau, tranquille sur son ordi ou dans les transports, sur son mobile, ce n’est pas pareil. La liste des surface aide aussi à visualiser les impacts et dépendances avec le reste du SI.
Pour le contexte, j’aime bien utiliser l’empathy map à chaque étape majeure si applicable :
Comme pour le premier outil, on peut construire cette map dans notre coin en essayant de se mettre à la place des utilisateurs, et ça sera déjà pas mal. Mais il faut prendre en compte les biais et ne pas graver la map dans le marbre.
Si vous avez l’occasion, ça fonctionne mieux quand vous pouvez parler à des utilisateurs. Faire des immersions est toujours une bonne idée.
Attention, il va falloir aussi envisager les variations de parcours, par segment utilisateur, mais aussi par état (anonyme ou identifié, première connexion ou habitué etc).
Donc on a notre map, fièrement affichée sur un mur, ou en fond d’écran. Et on va s’en servir pour prendre du recul et se remettre en situation. Je m’en sert comme une checklist, une definition of ready : est ce que mon nouvel écran fait rupture ou garde la fluidité ? Est ce que j’ai pensé à tous les utilisateurs et leurs contextes ? Est ce que j’ai envisagé les impacts sur les autres équipes ?
Dernière remarque : Le produit évolue. Le marché et les utilisateurs aussi. Donc la map qui est vraie aujourd’hui ne le sera plus demain. Pour que l’outil soit utile, il faut le maintenir, ce qui demande de parler régulièrement aux utilisateurs. Vous voyez où je veux en venir : il vous faut un binôme UX.
Bonus : Le tandem PM - UX
Vous l’avez peut être remarqué dans cet article, mais je suis plutôt pour associer un UX à chaque PM.
Le rôle du PM c’est d’aller chercher l’impact business, de faire bouger les lignes. Si vous souhaitez simplement suivre le chemin tranquillement ou exécuter la roadmap, vous n’avez pas besoin d’un PM.
Un modèle que j’aime bien pour caractériser les features à impact est le modèle DHM de Gibson Biddle. Il y a trois critères à considérer : Delightful, Hard to copy et Margin enhancing. Est ce que les utilisateurs sont ravis, est ce que la compétition ne l’est pas, et est ce qu’on gagne des sous. Note : ce modèle est tellement central que j’en ferai probablement un article.
Le facteur clé pour aller chercher l’impact, c’est la recherche. Recherche sur le business, sur les concurrents, sur les utilisateurs, les clients. Auprès des sales, du support, du marketing, des experts.
Un bon PM sait faire les recherches et intégrer les apprentissages dans le produit, en cadence, pendant le développement. Pas dans son coin avant qu’on aie commencé.
L’UX est un expert en recherche utilisateur. Si vous voulez l’impact, il faut que les utilisateurs soient ravis. L’UX apporte une profondeur dans la compréhension de leur environnement, de leur psychologie, de leurs motivations qui va décupler les chances de taper juste.
Si une seule personne cumule PM+UX ou PM+PO+UX, elle a beaucoup de responsabilité, et inévitablement, l’opérationnel prendra le pas sur la recherche. Le court terme passe avant le long terme. Donc pas d’impact. Pourquoi payer pour un PM du coup ?
Naturellement, le PM et l’UX vont avoir des visions assez antagonistes : le PM a une vision business, séquencée, et va vouloir toujours livrer pour capter progressivement la valeur. L’UX a une vision large, centrée sur l’expérience globale de l’utilisateur et les actions qu’il souhaite accomplir. Si vous les mettez dans des bureaux et des équipes séparés, les résultats ne seront pas terribles et tout le monde sera frustré. Mais quand on en fait un binôme, un tandem, il y a une magie qui s’opère et chacun renforce l’autre. C’est comme ça qu’on obtient des features Delightful ET Margin enhancing.
En fait c’est simple : si on cherche l’impact, la croissance, l’innovation, alors il faut mettre le prix et embaucher un tandem PM et UX. C’est encore mieux s’ils se connaissent et ont déjà travaillé ensemble.