Pourquoi présenter son travail ?
Le processus de conception d’un designer est par nature itératif. En travaillant en cycles courts, on s’assure de toujours coller aux réels besoins du projet, d’aligner les stakeholders sur les intentions de design proposées et au final de tenter d’apporter la solution la plus optimale au problème.
Savoir présenter son travail est donc une composante inhérente au métier de Product Designer. Mais bien souvent, on néglige cette partie, soit par manque de temps, d’intérêt ou par par crainte du jugement des autres.
Bien savoir présenter son travail, c’est rendre compte de l’avancée de projet. C’est fournir les justifications derrière des choix et permettre de les challenger en équipe. C’est créer un climat de confiance et de transparence au sein des équipes.
Un autre avantage dans cette présentation régulière du travail est la contrainte temporelle associée. En se fixant des checkpoints réguliers, on gagne en efficacité, en vélocité, mais aussi en motivation.
“Avant la prochaine review je prépare le prototype complet du flow d’inscription.”
Quel feedback cherche-t-on à obtenir ?
En fonction de la typologie de feedback que l’on cherche à obtenir, il peut être judicieux d’organiser différentes présentations pour éviter d’avoir à gérer un meeting ou tous les aspects du projet sont remis en question mais où aucune action concrète n’est prise.
Voici quelques exemples de feedback que l’on peut souhaiter et comment organiser un meeting pour y parvenir…
Challenger la conception des interfaces
Vous tâcherez ici de faire participer les autres designers de votre équipe qui ne connaissent pas forcément les détails du projet sur lequel vous travaillez. Il faudra donc entamer la discussion par un rappel du contexte et de l’historique s’il y en a un. On cherchera ici à demander du feedback sur tous les aspects visuels de notre interface. Parmi les sujets à aborder, on retrouve :
- La bonne utilisation du Design System
- La hiérarchie visuelle (contraste, lisibilité, accessibilité…)
- La cohérence visuelle avec l’expérience globale du produit
- Le choix de composants et de patterns
Réfléchir autour du parcours utilisateur
Au même titre que la partie visuelle de l’interface, l’expérience et le parcours utilisateur sont des points d’importance où l’on peut solliciter du feedback. À cette étape, il est aussi judicieux d’inclure d’autres stakeholders du projet (Product Manager, Développeurs) en complément des designer. Les décisions autour de l’expérience sont à la croisée des enjeux business, des besoins utilisateurs et de la faisabilité technique, d’où l’intérêt de convier différents métiers. À nouveau, pensez bien à expliciter le contexte autour de la partie d’expérience que vous allez présenter. Quel écran précède votre flow et quel écran lui succède. Pourquoi avez-vous fait ces choix et quelles ont été les contraintes qui vont y ont poussé ? En termes de feedback à solliciter, on retrouve :
- La simplicité de l’expérience au regard des actions à accomplir par l’utilisateur
- La cohérence entre la solution et les retours utilisateurs en notre possession
- La cohérence fonctionnelle avec le reste de l’application
S’assurer de la cohérence avec les enjeux business et de la faisabilité technique
Chaque solution que vous concevez s’inscrit dans une stratégie plus globale de développement de votre produit. Il peut alors être intéressant de vérifier régulièrement si la priorisation des fonctionnalités de votre expérience est alignée avec les enjeux business.
Le Product Manager de votre projet sera en capacité de vous aiguiller sur l’impact estimé des différentes parties de la solution. Ces feedbacks doivent vous permettre d’aboutir sur une priorisation et potentiellement la réalisation de “lots” qui viendront alimenter différentes versions de la fonctionnalité sur laquelle vous travaillez.
Le développeur quant à lui sera le plus à même de vous fournir des retours sur la faisabilité de votre solution. Il disposera de la vision sur l’aspect technique et pourra juger du coût de développement.
Parmi les sujets à aborder, on retrouve donc :
- La prise en compte des critères de succès dans la conception
- Le respect des contraintes techniques
- La priorisation des fonctionnalités
- La stratégie de releaseTravailler de prototype en prototype
Nous l’avons évoqué plus tôt, il peut être intéressant de travailler en “boucle de prototype”.
https://daverupert.com/2022/06/demo-to-demo-loop?ref=refind
On va donc chercher à travailler de manière itérative entre les sessions de feedbacks en améliorant progressivement le prototype associé à notre solution.
L’idée est de garder un niveau de fidélité relativement élevé pour simplifier les échanges pendant les meetings tout en permettant aux développeurs de se baser sur ce livrable pour l’implémentation. On évite ainsi les discussions “projectives” sur d’éventuelles améliorations et on se concentre sur l’existant.
En travaillant de “prototype en prototype” on se donne aussi une timeline plus claire sur les prochaines étapes à réaliser, et on peut aussi suivre plus simplement l’évolution de la solution.
Le mode asynchrone
Difficile de trouver le créneau idéal pour récolter du feedback, avec les contraintes de chaque stakeholders, ça peut même vite tourner au casse-tête. Le fonctionnement asynchrone peut alors être votre allié, quand il s’agit de présenter des évolutions relativement simples et faciles à comprendre.
Trouver le bon équilibre entre ces deux modes de fonctionnement est délicat et doit s’inscrire dans la dynamique et la culture de votre entreprise. Il est intéressant de prioriser l’importance des retours que vous attendez et de ne réserver les meetings synchrones qu’aux “checkpoints majeurs”.
Loom est une application efficace pour présenter vos maquettes ou votre prototype. Vous pouvez lier cette vidéo avec votre outil de ticketing favoris pour permettre à vos équipes de vous laisser des commentaires et échanger par écrit.
Outre le gain de temps réalisé pour tous les membres de votre équipe, vous assurez aussi une traçabilité de l’information et vous facilitez aussi l’onboarding de nouveau stakeholders sur la fonctionnalité.
“Je te laisse regarder la série de loom sur cette feature comme ça tu auras tout le contexte qui nous a amené à faire ces choix.
Attention cependant à ne pas tomber dans l’effet inverse en entamant des discussions écrites sans fin. Si vous sentez qu’un échange s’enlise et que vous ne tirez pas de réels enseignements, organisez une réunion très courte (15min) pour statuer sur le sujet.
Savoir rendre les feedbacks actionnables
Savoir demander du feedback est primordial dans le processus de conception, mais encore faut-il le rendre actionnable. Essayez du mieux que possible de toujours vous poser ces 3 questions :
- Est-ce que j’ai sollicité ce feedback ?
- Est-ce que cela s’applique au problème que j’essaie de résoudre ou à la solution que je conçois ?
- Est-ce que cela m’aide et me donne des pistes pour itérer sur mon travail ?
- Est-ce qu’il est assez précis et argumenté ?
Si ces trois réponses sont oui, alors il y a de fortes chances que le feedback associé soit important à prendre en compte. Dans le cas contraire, c’est à vous d’aller creuser avec votre interlocuteur pour chercher à comprendre ce qu’il a voulu vous transmettre.
Parfois vous vous rendrez compte ensemble que ce retour n’a pas lieu d’être dans la conception de cette fonctionnalité en particulier, ou parfois encore, vous aurez besoin de préciser les actions associées pour pouvoir vous l’approprier correctement.
