Comment identifier et qualifier de futures fonctionnalités en étant user-centric ?

Si vous vous êtes déjà retrouvés dans la situation où vous ne saviez pas comment identifier et qualifier les futures fonctionnalités d’un produit tout en restant focaliser sur les besoins utilisateurs, alors vous vous trouvez au bon endroit. Dans cet article, je vais vous aider à comprendre comment y parvenir.

Que vous soyez un Product Manager, un Product Owner, un Product Designer, ou un développeur, vous avez très certainement à cœur de concevoir et d’améliorer sans cesse le produit sur lequel vous travaillez.

Peut-être vous êtes-vous déjà interrogé sur les critères d’évaluation qui vous permettrait de prendre des décisions sur la mise en place d’une fonctionnalité plutôt qu’une autre ? Aussi, peut-être que votre équipe et vous-même vous vous posez la question de savoir si les fonctionnalités que vous concevez sont génératrices de valeur. Et comme vous êtes un. e adepte des bonnes pratiques UX, il ne vous viendrait pas à l’esprit de faire un choix qui ne serait pas dans une logique centrée sur les utilisateurs.

Voici mon premier conseil :

“ Pour répondre aux enjeux utilisateurs et à la stratégie de votre produit, laissez de côté l’aspect “fonctionnalité” et focalisez-vous plutôt sur des critères de valeurs. “

Dans cet article, nous allons voir comment identifier et qualifier des fonctionnalités de produits en nous focalisant sur la valeur et en utilisant les techniques du design d’expérience.

Repenser sa façon de définir sa vision fonctionnelle.

Comment pilotez-vous aujourd’hui la vision fonctionnelle de votre produit ? Peut-être, vous basez-vous sur votre propre idée du produit ? Peut-être, vous basez vous sur des entrants d’un ou plusieurs pôles organisationnels de votre entreprise ? Peut-être, travaillez-vous sur des éléments de marché ? Peut-être, travaillez-vous à partir d’éléments issus de la recherche auprès de vos utilisateurs cibles et vous prioriser simplement selon les demandes ?

Se baser sur des convictions, imposées ou non, ou sur des entrants liés purement à l’entreprise, n’est pas l’idéal, mais ne doit pas vous bloquer. Évidemment, je ne peux que vous recommander de travailler à partir de données utilisateurs, qui reste le choix le plus pertinent et qualitatif. Mais attention, cela ne suffit pas de traduire une demande utilisateur fraichement recueillie en fonctionnalité pour croire que le besoin sera assouvi ou que la réponse à la problématique sera réglée. Cela serait bien trop simple.

Quels que soient le contexte de travail et les possibilités données à votre projet ; mon ambition à travers cet article est de vous partager une démarche “ simple “ qui vous permettra d’identifier et de qualifier les fonctionnalités à inscrire dans votre backlog.

Mais pour ce faire, vous allez peut-être devoir changer radicalement votre façon d’appréhender votre vision fonctionnelle.

Vous devez inclure une nouvelle façon de penser qui est issue principalement du lean UX et du design thinking, afin d’aboutir à des fonctionnalités les plus pertinentes et qualitatives et donc génératrices de valeur.

Ce ne sont pas des méthodologies nouvelles en soi, mais elles ont fait leurs preuves depuis un moment. Par ailleurs, ce sont bien souvent ces mêmes processus de design qui viennent désormais soutenir les phases de product discovery pratiquées par les équipes de product management.

Design Thinking & Lean UX à la rescousse du product discovery.

Si je vous dis que vos fonctionnalités doivent être faisables (réalisable dans un avenir prévisible), viables (s’intégrant dans la durée dans le modèle économique de votre produit) et désirables (correspondant aux attentes de vos utilisateurs). Vous allez me dire : “ oui logique “. Parfait, car c’est ici la définition donnée par Tim Brown, fondateur d’IDEO et initiateur de l’approche Design Thinking, quand il évoque les critères d’évaluation d’une idée.

La pensée design est une philosophie de conception qui permet, entre autres, de générer des idées par la valeur tout en répondant aux critères cités juste avant. Alors, pourquoi s’en priver ?

Si vous ne connaissez pas l’approche Design Thinking, je vous recommande la lecture du livre “ L’esprit Design “ de l’auteur Tim Brown. Vous trouverez également un bon nombre d’ouvrages pratiques sur le sujet grâce à votre libraire préféré.

L’approche design thinking, comme décrit par Tim Brown consiste a passer par 3 étapes qui se chevauchent au cours du projet :

1. Une phase d’inspiration (aussi appelé exploration ou recherche), dans laquelle on rassemble des données issues de plusieurs sources possibles.

2. Une phase de conceptualisation (qui est également appelé idéation, voir même “ design thinking “ par abus de langage, ce qui n’est pas du tout la bonne façon de voir les choses), où les données recueillies dans la phase d’inspiration sont analysées puis traduites en idées.

3. une phase de réalisation (aussi appelé génération ou prototypage), où les idées de la phase de conceptualisation sont traduites à leurs tours en plan d’action pour aboutir à la conception d’un premier produit ou service.

Adaptons cette approche en l’associant aux méthodologies lean UX de Jeff Gothelf et Josh Seiden qui s’axent sur la conception de meilleurs produits avec des équipes agiles.

Les deux approches combinées permettent de se concentrer sur la qualification et la priorisation par la valeur, afin de faciliter une démarche de product discovery et de mieux définir les fonctionnalités du futur backlog du produit.

La démarche que je vous propose ici est une démarche que j’ai composée en puisant dans ces 2 approches. Voici comment procéder, en 3 étapes.

Étape 1 — Exploration

☞ Captez de la donnée des utilisateurs concernant votre produit. Quels besoins et quelles attentes les utilisateurs ont-ils envers votre produit ? Cela peut être des citations utilisateurs, des données issues de rapports analytiques ou des études de marché…

☞ Reportez toutes ces informations au même endroit pour en faire un mur de recherche. Vous pouvez utilisez un mur dans un espace dédié ou bien encore le faire de façon digital avec, par exemple, l’outil MIRO.

☞ Posez-vous ensuite la question suivante : “ Pourquoi ont-ils ces besoins ? Pourquoi de telles attentes ? “ Cette étape est cruciale : redéfinir le besoin permet de ne pas se jeter tête baissée dans la rédaction de fonctionnalité qui, peut-être, ne serait pas la bonne réponse au problème.

☞ Vous obtenez alors une liste de supposition issue de vos données de recherche. Vous pouvez reformuler vos données en suppositions de fonctionnalité qui combineront valeur utilisateur et valeur produit/entreprise en suivant le canevas suivant :

▸ Je pense que mes utilisateurs ont besoin de [description du besoin], 
▸ et ces besoins peuvent être satisfaits par... 
▸ pour résoudre le problèmede / afin que / car [point de souffrance initial soulevé par l'expression du besoin]

Prenons l’exemple suivant :

“ Je pense que mes utilisateurs ont besoin d’accéder facilement à leurs fichiers et ce besoin peut être satisfait par une recherche rapide et efficace de ces fichiers pour résoudre le problème de devoir parcourir tous les dossiers à la recherche du bon fichier. “

Nous avons ici une supposition qui exprime concrètement un besoin !

Étape 2 — Idéation

Gardons cette supposition à l’esprit. Désormais, générons le maximum d’idées d’hypothèses qui pourraient répondre à la problématique, exprimée par cette supposition.

Dans notre exemple, cela revient à générer le maximum d’idées autour de la problématique suivante :

“ Comment pourrions-nous permettre aux utilisateurs d’accéder rapidement à leurs fichiers par une recherche rapide et efficace ? “

Noter qu’ un petit atelier d’idéation collaboratif avec les utilisateurs finaux de votre produit vous permettra de générer un maximum d’idées de fonctionnalités pour votre produit. (Si vous n’avez pas accès à des utilisateurs finaux, ce n’est pas un drame. Travaillez avec votre équipe projet, mais il sera indispensable de confronter vos idées avec vos utilisateurs finaux lors de vos phases d’itération à partir du MVP de votre fonctionnalité).

Lors de cet atelier, vous allez générer des hypothèses de solutions pour répondre à la problématique.

Pourquoi rédiger des hypothèses ? La rédaction des hypothèses vous permettra de qualifier vos suppositions, mais surtout de dégager les points importants qu’il faudra vérifier pour valider ou non l’hypothèse.

Appuyez-vous sur vos suppositions de fonctionnalité pour formuler des hypothèses. Ce format vous permettra de mettre en place plus facilement une phase de test en y mettant des indicateurs de succès. Voici un canevas de modèle d’hypothèse que vous pouvez mettre en place :

▸ Nous pensons parvenir à [...], 
▸ si les utilisateurs atteignent avec succès [...], 
▸ grâce à [cette fonctionnalité].

Lors de votre atelier, proposez simplement ce canevas d’hypothèse aux participants avec un exercice de brainstorming. Je vous conseille de faire réfléchir les participants de façon individuelle afin de générer le maximum d’idée d’hypothèse pour ensuite échanger tous ensemble afin d’obtenir plus d’information sur les idées exprimées et regroupez les informations si nécessaire.

Avec notre exemple cela pourrait donner :

Hypothèse 1 : “ Nous pensons parvenir à faire gagner du temps à nos utilisateurs si ces derniers trouvent rapidement leurs fichiers grâce à un moteur de recherche indexé “.

Hypothèse 2 : “ Nous pensons parvenir à faire gagner du temps à nos utilisateurs si ces derniers accèdent rapidement à leurs fichiers en passant par une gestion intelligente et automatique des dossiers selon des filtres personnalisables. “

Hypothèse 3 : …

Il n’y a pas de limites aux nombres d’hypothèses ! Le plus important est la génération d’hypothèses de fonctionnalité en rapport avec le problème à résoudre.

Remarquez ici que nous avons une indication de mesure de validation de l’hypothèse qui est le temps ( gain de temps dans la recherche), un objectif à atteindre ( trouver rapidement des fichiers) et des façons d’atteindre l’objectif différemment ( indexation ou filtre).

Étape 3 — Design, prototypage et validation des idées

À ce stade, il n’y a pas de miracle, la seule façon de valider les idées et de tester leurs valeurs auprès des utilisateurs.

Rappelez-vous toujours cette phrase : “ Une idée sans un test est juste une idée “

Chaque idée générée est une hypothèse qui doit être transformée en fonctionnalité pour basculer en phase de conception, afin de les “ prototyper “ et surtout de “ tester leurs valeurs auprès des utilisateurs cible. “

Ici entre en jeu l’équipe design et développement pour développer un ou plusieurs prototypes testables.

Attention, le niveau de fidélité du prototype ne dépend que de vous et de votre équipe projet. De la valeur générée et du temps alloué. Mais le prototypage et le test vous permettront de valider ou non si l’idée est bien génératrice de valeur ( gain de temps dans notre exemple) et permet d’atteindre l’objectif ( accès rapide à des fichiers dans notre exemple).

Sans prototype et sans test, vous revenez au point de départ. C’est-à-dire, se jeter tête baisser dans une fonctionnalité qui, peut-être, ne serait pas la bonne réponse au problème. Et ainsi dépenser un coût de développement conséquent et inutile.

Adaptez, itérez et construisez votre propre démarche.

La démarche que je viens de vous proposer, je l’utilise avec des équipes orientées 100 % sur la conception de produit.

En partant de simples hypothèses issues de brides de donnée, cela permet, aux équipes de conception, de rapidement challenger des idées de fonctionnalités et de les qualifier avant même de rédiger la moindre user story. Cette démarche vient compléter la phase de recherche en amont permettant justement de s’assurer du sens et de la valeur d’une fonctionnalité à développer dans le produit.

Prenez des libertés et adaptez, construisez votre propre démarche. Gardez à l’esprit qu’ une fonctionnalité qui sera développée dans le produit doit être faisable, viable et désirable et donc doit être issue à la base d’une donnée analysée, travaillée en idée et testée.

Peut importe la façon de faire, le plus important et de tester et de s’assurer de la pertinence de votre fonctionnalité tout en restant agile et itératif !

Image de couverture by Eric Neil Vázquez from Pixabay

Originally published at http://www.clementvanmeyel.fr on May 21, 2021.