Disclaimer: Ce REX fait suite à une mission qui se termine pour moi. Je suis intimement convaincu de l’importance d’une bonne “expérience utilisateurs” lors de la conception d’un produit informatique, quel qu’il soit. Je suis également profondément convaincu que l’UX est un ensemble de métier (anthropologie, architecture de l’information, ergonomie, UI design, design thinking, linguistique,…) bien spécifique qui nécessite de la pratique, de l’expérience et des méthodes spécifiques. Avoir un ou plusieurs spécialistes dans une équipe est bien évidemment ce que je préconise. La réalité est que souvent, pour des raisons de budget, de taille de projet ou d’équipe, ou même de convictions (triste), les products owners/managers sont amenés à travailler en l’absence de personnes sans compétences spécifiques dans ce domaine. Cet article s’adresse principalement à ces personnes. L’objectif étant de partager une façon de faire qui puisse peut être les aider au quotidien à inclure des “morceaux” de ces méthodologies pour placer l’utilisateur au sein de la conception de leurs produits.
Après une année et demi à travailler en tant que seul product owner sur un gros système d’information ( 3–4 applications WEB et des APIs) avec une équipe restreinte (entre 2 à 3 développeurs), sans UX designer, et avoir essuyé quelques plâtres, voici le “design process” que j’essaie d’appliquer au quotidien ainsi que les méthodologies dont je me suis inspiré.
Inspirations : Interviews utilisateurs & clients, tests utilisateurs, job-to-be-done framework
La première étape est à la base de mon rôle de product owner:
Inspiration : Customer Journey Mapping, Experience Map, Méthode Graal
La seconde étape consiste à décliner le parcours de l’utilisateur, le processus qu’il suit ou devra suivre, les actions qu’il effectue sous forme de processus ou de map, avant même d’imaginer ou d’esquisser les premiers bouts d’IHMs. Cette étape a différents objectifs :
<img class="progressiveMedia-noscript js-progressiveMedia-inner" src="https://cdn-images-1.medium.com/max/1600/1*n3Jh5iQ1JnJMCPRMlgdP0w.png">
Un exemple de processus et de douleurs utilisateurs
Inspiration:Heuristiques de Nielsen
UX designer n’est pas mon métier principal, alors j’évite de me risquer à inventer de nouveaux patterns. Je laisse cette mission aux équipes des géants du web car elle sont bien mieux armées que moi. Pour ma part je vise l’efficacité. Du coup, quand le parcours est clairement identifié et que j’ai pu poser des verbes et des noms sur les tâches que va effectuer l’utilisateur dans l’ordre chronologique, j’effectue deux types de recherches.
Le premier type sert d’inspiration. Je parcours d’autres applications, plus ou moins connues du public, et j’en extrais les patterns standards. Cela permet également d’identifier les patterns auxquels sont exposés au quotidien les personnes à qui mon produit s’adresse.
Exemples de standards “web” (Airbnb, TripAdvisor, Amazon)
Le second type de recherche a pour vocation de conserver la consistence dans l’application. Késako? La consistence d’une application c’est l’ensemble des règles et des conventions que vous avez choisi d’adopter et de généraliser dans votre application. Par exemple : si la barre de recherche est en haut à droite, elle doit l’être dans toute votre application. En gros, plus vous avez des patterns différents dans votre application, moins elle est consistante. (C’est presque de la dette UX)
Pour ce type de recherche je vais donc cette fois parcourir mon application pour me rappeler des patterns auxquels les utilisateurs sont déjà exposés dans le contexte de mon produit. Cela favorisera la prise en main de la nouvelle fonctionnalité en cours de cadrage.
Exemple de “pattern” simple mais qui permet d’établir les principes de votre appli.
Inspiration:Lean UX, Lean Startup, Design Sprint, Tests utilisateurs
L’objectif de cette partie est d’obtenir le plus rapidement possible de quoi exposer aux utilisateurs ce que va devenir leur outil. Du dessin au feutre sur paper board à la maquette Balsamiq voire au design graphique si vous maitrisez Sketch ou autres.
J’essaie, quand c’est possible à ce moment, d’inclure un développeur. Pourquoi? Plusieurs choses. Un développeur a eu une vie avant le projet et a certainement déjà réalisé des interfaces, il serait bête de ne pas profiter de ses connaissances et de son expérience. Un deuxième avantage est que cela peut vous permettre de lever les loups liés à la complexité technique de telle ou telle réalisation.
Enfin, je présente / teste mes maquettes auprès des utilisateurs et je les laisse effectuer un parcours “nominal” afin de détecter avant tout développement, les erreurs et incohérences du nouveau design.
Cette phase est plutôt itérative. Il est fréquent de devoir itérer sur la solution.
Inspiration:Lean Startup, Scrum, Méthode Graal
Après la prise en compte des différents retours, j’effectue mon travail plus classique de product owner. Je découpe mes user stories à partir du travail réalisé et je les priorise afin d’avoir au plus tôt une fonctionnalité complète. L’équipe pourra enfin pousser en production et tester.
Exemple de découpage de mon processus en users stories indépendantes
Comme je l’ai évoqué en introduction, je ne suis pas UX Designer mais mon métier m’oblige à placer l’utilisateur au centre de mes préoccupations alors j’essaie.
Je me contrains pour que ce processus me prenne moins de 20% de mon temps de PO. C’est trop peu sur ce sujet. (Pour l’anecdote, vous savez combien de personnes ont travaillé sur les émotions Facebook et pendant combien de temps? Au moins 6 et pendant 1 an …).
En même temps prioriser, découper, re-prioriser, spécifier, écrire des tests fonctionnels automatisés, échanger avec les développeurs, recetter prend énormément de temps. Mais c’est notre mission: constamment se partager entre “faire le bon produit” et “bien le faire”.
Ne soyez donc pas trop sévère avec vous même, votre travail ne sera jamais vraiment comparable à celui d’un “vrai” UX Designer.
Je vous conseille également de vous acculturer aux méthodologies d’UX Design en lisant des articles, s’abonnant à des newsletters, regardant des videos et en échangeant avec des UX designers. J’ai la chance chez OCTO d’en côtoyer au quotidien, de travailler avec eux, de comprendre comment ils et elles fonctionnent et cela m’a beaucoup aidé dans ma progression sur ce sujet. Bref, soyez curieux.
Enfin travaillez avec vos utilisateurs et votre équipe. Se faire challenger est important dans la recherche de meilleures manières de faire. Testez des choses, trompez-vous et vous verrez vous vous améliorerez.
Si vous vous posez des questions à ce sujet, souhaitez proposer des alternatives ou si vous recherchez un Product Owner pour votre projet, n’hésitez pas à me contacter : aichane@octo.com ou sur twitter @AnaelIchane.
Enfin si vous avez apprécié cet article: likez, tweetez, commentez ou partagez sans états d’âmes.