Le Product Design en cycle court : les bonnes pratiques

Le design d’une chose est par essence le fruit d’un processus long où se succèdent phases d’appropriation, de projection, de dessein, et phases de réalisation, de conception, de dessin. Mais aujourd’hui, les méthodes de Discovery utilisées dans le Product Design s’adaptent mal au rythme rapide imposé par l’approche Agile, car elles ont été créées pour fonctionner en cycle en V.

Alors, comment être efficace lors d’une phase de discovery en cycle court?

Deux forces contraires

Les méthodologies actuelles ont trouvé naturellement leur place dans la formalisation en double diamant, permettant ainsi d'enchaîner ces phases en adaptant son mindset au momentum, grâce la chape métaphorique de l’ouverture-fermeture.

La conception de projets pour des usagers trouve ainsi tout son sens dans l’approche user centric, mais perd toute sa précision combinée à un fonctionnement en cycle en V. En effet, cette méthode crée un trop gros écart entre la récolte des besoins et usages et la livraison du dispositif et des features attendues, créant ainsi un chassé-croisé constant entre le besoin de l’utilisateur et le produit livré.

Les méthodes Agiles sont la meilleure solution pour résoudre ce problème. Imposant un rythme court et régulier de Delivery (features), elles nous obligent à ajuster perpétuellement notre connaissance des usagers, et donc à proposer des solutions plus adaptées. Cependant, travailler à ce rythme peut nous faire commettre des erreurs lors de la phase de recherche, et de la même façon, ne pas comprendre le besoin.

Le problème auquel nous sommes confrontés aujourd’hui, est que la recherche design est issue de l’approche académique et universitaire des sciences sociales et psychologie comportementale, une approche quasi-scientifique, qui est longue et rigoureuse.

Rigoureuse dans sa réalisation du début à la fin afin de ne pas biaiser les résultats, et longue parce que le processus complet nécessite du temps.

Cependant, la phase de Discovery en équipe produit, peut amener trois problèmes majeurs :

🤦‍♀️ Ne jamais coller au besoin : en récoltant peu, et pas de façon continue, en réalisant des features en fonction de trop peu de faits (voir l’Atomic Research), ou pire, en fonction d’un seul fait, et non en fonction d’insights récoltés. En ne fonctionnant pas en Lean, vous prenez le risque de traiter des résultats qui ne sont pas représentatifs d’un point vue macro (sur plusieurs Sprints), votre produit ne sera pas ajusté petit à petit et ne collera jamais à l’usage.

🐇 Perte de temps : chaque nouvelle feature étant objectivée, une mauvaise récolte peut amener à un échec lors de sa mise en production. En ne prenant pas compte de la qualité de la récolte, on peut imaginer des features non-évolutives (côté usages métiers ou sur le plan fonctionnel), se voir repartir à zéro lors de futures itérations et ne pas construire l’expérience adéquate.

🤷 Abandon de la recherche : l’incompatibilité de la Discovery un rythme court peut amener les équipes à laisser de moins en moins de temps pour cette recherche, et parfois, complètement la supprimer.

Quelques bonnes pratiques

Anticiper la réalisation

Identifiez les obstacles que vous risquez de rencontrer en améliorant votre méthode actuelle ou en mettant en place une méthode de recherche rapide

Se fixer des objectifs atteignables

Une bonne évaluation du temps est nécessaire pour préparer des séries de tests en cycle court. Validez en amont un nombre fixe de tests par semaine ou par Sprint si possible, afin de pouvoir prévoir le taux de fiabilité de chacune de vos récoltes selon le modèle de Nielsen et Landauer (par exemple). En ayant ce chiffre bien en tête, vous aurez plus de recul sur vos recommandations, et le développement de chaque recommandation sera évalué en connaissance de cause.

Adapter sa méthode au contexte

Choisissez le nombre de participants en fonction du niveau de granularité dont vous avez besoin.

• Si vous souhaitez faire de la recherche exploratoire, afin de déterminer des problèmes récurrents, 4-6 participants seront suffisants pour détecter la grande majorité des problèmes à chaque Sprint. Vous pouvez aussi maximiser ce faible nombre de participants en focalisant chaque test sur un usage très précis.
• Si vous souhaitez aller plus loin dans la compréhension des usages, pour créer des fonctionnalités plus poussées, prenez en compte que le temps pour traiter les insights sera plus long étant donné qu’il y en aura plus. Vous aurez aussi besoin de réaliser plus d’aller-retours avec les équipes pour valider un prototype complexe.

Ne priorisez que les insights bloquants

Déterminer le KPI de priorisation en fonction du nombre de participants et selon les 2 dimensions :

• Le nombre de retours par insight : plus les retours concernant le même sujet sont nombreux, plus on peut estimer qu’il est important,
• Nombre de moyens de récolte : si un même retour a été récolté et identifié via différents canaux (interviews utilisateurs, users test, focus group, analyse quanti des usages…) on peut en déduire qu’il a de l’importance.

Automatiser les retours

Mettre en place des tests utilisateurs sans expert au moment du test peut être une solution pour récolter des feedbacks de façon automatique. Pour cela, proposer un template à remplir pendant et après les tests. Focalisez-vous sur les retours macro et globaux (compréhension de l’interface, look & feel de l’app, correspondance avec les “attentes”…) et pas sur des points précis (analyse de son propre besoin, logique des parcours, compréhension d’un wording…). Construisez ces tests automatiques de sorte à pouvoir entrer les résultats dans une courbe d'évaluation UX par exemple, ou toute autre forme permettant de pouvoir comparer les résultats de façon objective, sur plusieurs lots de tests différents dans le temps.

Travailler en MVP et non en feature cible

Le MVP permet de valider l’usage et d’évoluer jusqu’à la feature cible (vers le design souhaité). Théoriquement. Seulement, il est rare de réussir à se projeter dans l’usage d’une feature qui n’existe pas encore, côté Designer, mais aussi côté utilisateurs. Désigner immédiatement un MVP permet de gagner du temps, même si avoir un design cible en tête permet aussi d’aligner tout le monde et d’avoir un cap. Favorisez une “vision cible“ d’un design pour un usage plutôt qu’un design cible, c’est moins engageant et ça ouvre plus le champ des possibles. Les features en MVP vont évoluer au fil des sprints et s’adapter aux usages et à la “vision cible”. Less is more.

La question sous-jacente, est comment découvrir la Minimum Value Proposition d’une feature ? Est-ce qu’elle répond à son besoin profond en temps qu’utilisateur ? Est-ce qu’elle participe réellement à la réalisation de l’action ? Ma réponse : le Jobs To Be Done, et des metrics.

Les bonnes pratiques à mettre en place

• Mettre en place des tests de façon régulière en mode Lean. Mieux vaut peu d’avis que pas d’avis !
• Favoriser les tests en présentiel. Vous passerez toujours à côté d’informations essentielles si vous comptez sur le participant pour expliquer la moindre de leurs actions et pensées à haute voix. Les informations non-dites et le langage non-verbal du participant sont des informations exceptionnelles.
• Penser à la communication, pour mieux vous organiser, entre les équipes et à la passation, aux personnes qui passeront derrière vous : vous devez laisser des recherches propres derrière vous. Créez un tableau regroupant les dates de chaque test, ainsi que les testeurs et les participants. Dans ce tableau, joignez un lien permettant d'accéder à vos notes brutes ainsi qu’aux logiciels utilisés pour traiter les données en masse (Miro, Mural, Figma...).

📚 Lire notre article "Pourquoi et comment utiliser Figma ?"

• Ce tableau vous permettra de mieux vous organiser, car vous y inscrirez vos tests à l’avance, mais il jouera aussi un rôle d’historique pour retrouver des notes.

Exemple de méthodologie pratique en cycle court

Voici un exemple qui peut vous permettre de gagner beaucoup de temps lors de la restitution de vos tests utilisateurs.

Étape 1 : Gérer ses retours rapidement

• Post-test : imprimez votre grille de questions ou votre protocole, cela vous permettra de pouvoir prendre des notes sur votre ordinateur
• Sur votre board (Miro ou autre), un participant = une couleur. Préparer votre board en séparant les étapes des parcours à tester, vous y regrouperez les données brutes
• Dans les données brutes récoltées (vos notes lors du test), récupérez uniquement les verbatims et les actions à réaliser.

• Ranger les données récoltées sous forme de post -it. Une idée/action/verbatim = un post-it
• Clusteriser les post-it par page, sous forme de grandes catégories (ici A, B, C, D...)

• Fusionnez tous les clusters similaires (clusteriser les clusters entre autre) dans un tableau unique

Vous avez maintenant des catégories générales dans chaque page. Dans ces catégories se trouvent différents clusters de post-it de couleurs différentes.

Étape 2 : Priorisez

Posez-vous maintenant les questions suivantes :

• Quelles sont les catégories les plus fournies ?
• Qu’est-ce qui revient le plus souvent ?
• Qu’est-ce qui fait l’unanimité ?

Une méthode pour prioriser vos clusters :

• Notez le nombre de post-it de couleurs différentes par cluster par rapport au nombre de participants total.
• Fixez un KPI. Par exemple, “je décide de traiter les catégories dont + 50% des participants ont parlé”

On peut ensuite s’amuser à faire un mapping de priorisation selon les deux axes évoqués précédemment s’il y a beaucoup de retours et si cela peut nous aider, comme ci-dessous.

Ici, on traitera dans l’ordre D, B, C puis A.

En conclusion

Les méthodes classiques pour la Recherche UX ne conviennent pas toujours à des équipes structurées en Product Team, car le temps alloué aux recherches est souvent dépendant du rythme de l'équipe.

Il est donc essentiel d’adapter nos méthodes, pour tenir la promesse que nous faisons à l’utilisateur : lui apporter de la valeur à travers le produit, en portant sa voix au cœur de la réflexion.

Le Product Designer est un UX - UI Designer avec des méthodes de travail optimisées pour travailler en mode Agile, et souvent orienté Delivery. Le rôle d’un Product Designer est intimement mêlé au Product Growth, car il doit construire le produit de sorte à rendre accessible sa valeur à l'utilisateur le plus vite possible.

Si vous devez travailler vite, et que par rapport aux bonnes pratiques UX, vous avez récolté peu d’insights, dites-vous que la feature va évoluer, et que Sprint après Sprint, vous serez plus proche du besoin de l’utilisateur que si vous n’avez fait qu’une seule grosse série avec un plus gros panel. Vos recherches sont en réalité échelonnées dans le temps.

Il n’y a pas une seule façon pour adapter ses méthodes de travail, cela dépend du contexte, du rythme de l’équipe, et des résultats attendus. Et il n’y a pas de bonne façon de faire, l’important, c’est que ça fonctionne, et avec ces bonnes pratiques, on est sûr que ça va fonctionner pour votre produit !