Guide pratique du Product Canvas

Passer au contenu principal

Guide pratique du canevas de produit agile

Guide pratique du Product Canvas

Il était une fois un homme de a déclaré avec une grande considération« En ne vous préparant pas, vous vous préparez à l’échec. » Cet homme était Benjamin Franklin, et ce qu’il a dit est toujours très vrai aujourd’hui.

La plupart d’entre vous connaissent le Méthodologie Scrum en combinaison avec Mendix comme une plateforme. Et la plupart d'entre vous savent probablement que Scrum ne dit rien sur la façon de se préparer pour vos produits. Cependant, même dans un contexte Agile, une bonne préparation reste la clé du succès.

Mendix a connu un grand succès avec la méthodologie Product Vision et Product Canvas pour préparer nos projets et nous préparer pour le premier sprint. Plongeons dans le Product Canvas et son utilisation.

Qu'est-ce qu'un canevas de produit ?

Avant de commencer à travailler sur un nouveau produit, vous devez comprendre son objectif, son public et ses objectifs. C'est là qu'intervient un canevas de produit.

D’après Miro, un canevas de produit est un outil de planification qui combine des méthodologies Agile et des principes UX pour aider les équipes à créer des produits qui offrent d'excellentes expériences utilisateur.

Romain Pichler, l’inventeur du Product Canvas, le décrit comme « un outil simple mais puissant qui vous aide à créer un produit avec une expérience utilisateur exceptionnelle et les bonnes fonctionnalités. Il combine le développement agile et la conception de l’expérience utilisateur en complétant les user stories avec des personas, des storyboards, des scénarios, des croquis de conception et d’autres artefacts UX. »

 

Comment planifier le changement avec la vision du produit et le canevas du produit

Une idée fausse courante concernant Méthodologies Agiles c'est qu'aucune préparation ou documentation n'est nécessaire et que le processus sera guidé comme par magie par le résultat et le feedback de chaque sprint.

Ce n'est évidemment pas vrai. La bonne Manifeste Agile la déclaration conseille « Réagir au changement plutôt que de suivre un plan. » Cela signifie que vous devez avoir un plan qui s'adapte facilement aux changements, ce qui conduit à une préparation adéquate.

Dans ce contexte, le terme adéquat signifie ce qui suit :

  • Se préparer à offrir de la valeur commerciale
  • Former une vision claire du projet
  • Une préparation suffisante pour permettre la prévision
  • Juste assez de détails pour commencer le premier sprint

Tout ce qui va au-delà est excessif. N'oubliez pas que nous essayons de créer un « plan » qui peut être facilement ajusté en fonction des changements. Plus le plan est vaste et détaillé, plus il est rigide et difficile à modifier.

Alors que la méthodologie Product Vision et Product Canvas sont préconisées par Mendix En raison des succès que nous avons obtenus, ce n'est en aucun cas la seule méthodologie disponible. Même en suivant des méthodologies différentes, comme un « Sprint Zéro », cet article de blog sera d'une grande utilité, car il offre un aperçu des types de questions auxquelles il faut répondre pour préparer un projet.

Jetez un coup d'œil rapide sur un tableau de vision de produit

La première étape consiste à créer une vision globale du projet. Pour cela, utilisez le tableau de vision produit. Cette partie étant assez simple, nous n'entrerons pas dans les détails dans cet article de blog.

Tableau de vision du produit

Fondamentalement, le Product Vision Board répond aux questions suivantes :

  • Pourquoi créons-nous l'application ?
  • Quel est notre groupe d’utilisateurs cible ?
  • Quels sont leurs besoins ?
  • Comment envisageons-nous que notre produit réponde à ces attentes ?
  • Quels sont nos objectifs commerciaux en faisant cela ?

Le Product Vision Board sert également de base au Product Canvas. Ces deux tâches relèvent de la responsabilité du Product Owner. Cependant, cela ne signifie pas qu'il doit faire tout le travail. Il est fortement conseillé de faire appel à l'équipe Scrum et aux experts si nécessaire.

Le canevas du produit et sa mise en page

Après avoir défini votre vision produit, il est temps de déterminer comment concrétiser cette vision. Cela vous permettra de répondre aux questions suivantes :

  • Qui sont nos utilisateurs ?
  • Quelles sont leurs tâches et comment envisageons-nous qu’ils les accomplissent ?
  • Quelles sont les contraintes de haut niveau pertinentes ?
  • À quoi ressemblera le design dans les grandes lignes ?
  • Quelles sont nos épopées et nos user stories prêtes à accomplir cela ?

Toile de produit

En comparant les questions auxquelles il sera répondu avec le Product Canvas, il devient clair que la disposition réelle du Product Canvas ne raconte pas l'histoire de manière chronologique. Mais pour bien comprendre comment créer un Product Canvas, cette chronologie est très importante.

Disposition chronologique du Product Canvas

La disposition chronologique du Product Canvas

L'image ci-dessus montre les étapes logiques à suivre pour créer un Product Canvas. Une étape mène à la suivante, en commençant par un récapitulatif de la vision du produit, la recherche sur les utilisateurs réels du produit et la création de Personas, jusqu'à la création de Ready Stories pour le premier sprint.

Notez que les contraintes sont dessinées parallèlement à la création des parcours utilisateurs. Il est également possible de le faire au préalable car certaines contraintes peuvent ou non affecter les parcours utilisateurs.

7 étapes pour créer un canevas de produit

Étape 1 : Vision et nom du produit

La boîte Vision du produit n'est rien d'autre qu'un résumé du tableau de vision du produit. Une bonne façon d'y parvenir est de vous demander comment vous décririez les parties les plus importantes de la vision en seulement une ou deux phrases.

L'élément le plus sous-estimé de tout processus de développement d'application (interne à l'entreprise) est le nom de l'application. Il est rare de démarrer le premier sprint d'un projet dans lequel un bon nom d'application est déjà présent. Il est vrai que trouver un bon nom est un travail difficile. Il doit être accrocheur tout en ayant un lien fort avec l'application réelle. Ce n'est pas une tâche facile.

La principale raison pour laquelle il faut choisir un bon nom dès le début est l'effet positif qu'il aura sur toutes les personnes impliquées dans le projet. Comme les personas, les gens commenceront à développer un lien émotionnel avec l'application qu'ils créent ou contribuent à créer. Et, si ce n'est pas fait dès le début, ce n'est qu'un de ces détails qui ne se retrouve jamais en tête de la liste des priorités s'il ne s'agit pas d'une application externe à l'entreprise.

Étape 2 : Créer des personas

Avant de commencer à réfléchir à la manière de développer des fonctionnalités, il est essentiel de comprendre pour qui et pourquoi nous développons ces fonctionnalités. Pour cela, nous effectuons des recherches sur les utilisateurs qui aboutissent à des personas.

Exemple de Persona

Exemple de Persona

Fondamentalement, une Persona se résume à un archétype d'utilisateur basé sur la recherche. Il est important de noter que la méthodologie d'utilisation des Personas pour modéliser un groupe d'utilisateurs n'est pas une astuce créative non éprouvée utilisée par les spécialistes du marketing et les concepteurs UX, mais est en fait basée sur la recherche scientifique. Tant dans le contenu que dans l'efficacité de leur utilisation. Ils aident à développer l'empathie, à orienter le projet, à communiquer et à former un consensus au sein de l'équipe de projet, et à aider à prendre et à défendre des décisions.

De plus, la partie recherche de cette étape permettra de valider toutes les hypothèses formulées lors de la création de la vision du projet. N'oubliez pas que dans la vision du projet, nous avons indiqué quel est le groupe cible d'utilisateurs et quels sont leurs besoins. Cette étape est presque toujours réalisée sans parler à un seul utilisateur. Ce n'est pas nécessairement une mauvaise chose, mais cela nécessite de vérifier les hypothèses formulées. Comme pour la résolution des bugs, le temps et les efforts nécessaires pour modifier l'application au début d'un projet sont 10 à 100 fois plus importants qu'après sa mise en production.

Lorsqu'il s'agit d'un environnement au rythme rapide Mendix L'un des défis du projet est le manque de temps, ce qui rend impossible la création de personas (traditionnels) basés sur des recherches scientifiques quantitatives. Heureusement, les personas provisoires offrent une solution dans laquelle un nombre très limité d'entretiens sont réalisés à titre de recherche. Certes, ils ne servent que de point de départ et sont moins utiles que les personas traditionnels, mais ils peuvent être créés en un ou deux jours, ce qui les rend très attractifs pour Mendix projets.

Étape 3 : Créer des parcours utilisateurs

À ce stade, vous et votre équipe savez exactement qui sont vos utilisateurs, quels sont leurs besoins et ce qu'ils essaient d'accomplir avec l'application que vous allez créer. L'étape suivante consiste à combler l'écart entre vos personas et leurs tâches et le fonctionnement de l'application. Les parcours utilisateur offrent un excellent moyen d'y parvenir.

Vous pouvez définir différents niveaux de parcours utilisateur qui ont chacun leurs propres avantages et inconvénients.

1. Parcours client

Il est courant dans le monde du marketing de cartographier l'expérience globale dans laquelle l'application a sa place (et n'est souvent qu'une partie du parcours complet). Il est fort probable que le parcours client ait déjà été cartographié. Si tel est le cas, il doit être utilisé dans le cadre de la préparation.

Exemple de parcours client

Exemple de parcours client

2. Story-boards

Les storyboards sont une méthode beaucoup plus concrète qui ressemble beaucoup aux romans graphiques ou aux storyboards de films. Ils offrent un excellent moyen non seulement de définir la manière dont un utilisateur interagira avec l'application, mais aussi d'ajouter du contexte si nécessaire.

Exemple de storyboard

Exemple de storyboard

Notez que l'exemple ci-dessus offre beaucoup de contexte. Ce qui est bien, mais pas toujours nécessaire. Il est également possible d'esquisser grossièrement les écrans sous forme de dessins et d'ajouter du texte et des flèches pour raconter l'histoire. Il est également bon de souligner qu'un storyboard n'a pas besoin d'être « joli ». Il doit aider à concevoir le parcours et à communiquer des idées au sein de l'équipe.

3. Flux d'utilisateurs

Au niveau d'abstraction le plus bas se trouvent les flux utilisateurs, qui sont très similaires aux microflux. Ils représentent schématiquement le flux qu'un utilisateur peut suivre pour accomplir une tâche.

Exemple de flux d'utilisateur

Exemple de flux d'utilisateur

La création de flux d'utilisateurs est considérée comme un minimum car ils sont faciles à créer (même PowerPoint est un excellent outil à utiliser pour cela) et sont très puissants pour concevoir l'expérience tout en alignant toute l'équipe sur la manière d'y parvenir.

Nous vous recommandons de créer des storyboards, car ils offrent beaucoup plus de contexte et facilitent la conception de l'expérience, car certains détails (moins pertinents) peuvent être ignorés. Ces détails peuvent être cartographiés ultérieurement à l'aide de flux d'utilisateurs.

Remarque pratique : ne planifiez pas chaque parcours utilisateur, mais concentrez-vous sur les plus importants. Après tout, il s'agit d'une méthode de travail agile, ce qui signifie qu'il ne faut pas trop préparer.

Étape 4 : Définir les contraintes pertinentes

Comme je l'ai mentionné précédemment, le moment précis de la création des contraintes n'est pas gravé dans la pierre. Gardez simplement à l'esprit que certaines contraintes peuvent influencer les parcours utilisateur et doivent donc être créées avant ou en parallèle avec les parcours utilisateur. Un bon exemple serait la contrainte de ne pouvoir utiliser les fonctionnalités réseau qu'à l'intérieur du bureau physique, ce qui fait de la localisation d'un utilisateur un élément très important de tout parcours utilisateur.

Une astuce pour définir les contraintes est de les garder pertinentes. Une liste d'une centaine de contraintes n'est plus un outil productif pour la préparation mais un obstacle contreproductif. Il y aura suffisamment de temps dans les sprints réels pour définir et gérer les contraintes.

Etape 5: Conception

La section de conception est la première étape de la traduction des parcours utilisateur vers l'application à créer. Les activités réelles de cette étape peuvent varier considérablement en fonction du type d'application, du type de client et de la maturité de ce client en termes d'utilisation de l'application. Mendix

En général, nous pouvons identifier au moins quatre outils qui se sont avérés très efficaces.

1. Plans de site (ou plans d'application)

Un outil largement utilisé dans la conception et le développement de sites Web, mais un peu moins courant dans la conception et le développement d'applications. Il s'agit essentiellement de cartographier la structure (de la page) de l'application.

Exemple de plan de site

Exemple de plan de site

2. Wireframes

Croquis de conception d'écrans réels avec des niveaux de fidélité et d'abstraction différents. C'est une chose familière à la plupart des gens. Étant donné que cette étape est destinée à préparer le projet, il est important de ne pas en faire trop. Concentrez-vous sur la conception d'un système plutôt que sur des pages individuelles et trouvez un équilibre entre la conception des grandes lignes de l'expérience utilisateur dans son ensemble et la préparation du premier sprint. Nous pouvons définir trois niveaux de fidélité, chacun avec ses propres avantages et inconvénients : basse fidélité, fidélité moyenne et haute fidélité.

Exemple de wireframes et différents niveaux de fidélité

Exemple de wireframes et différents niveaux de fidélité

Tout comme pour les parcours utilisateurs, la basse fidélité est considérée comme un minimum, et au moins quelques wireframes de fidélité moyenne sont recommandés. Bien qu'il soit préférable de les faire réaliser par un concepteur d'interface utilisateur ou d'expérience utilisateur, tout le monde peut créer des wireframes de basse fidélité. Il existe d'excellents outils, comme Balsamique, pour le faire, et même un stylo et du papier ou un tableau blanc peuvent suffire pour commencer. Il est toujours plus rapide d'essayer différentes conceptions et solutions avec le wireframing que d'attendre que tout soit modélisé pour ensuite le modifier. De plus, un bon wireframe vous indiquera exactement comment modéliser cet ensemble de pages spécifique.

3. Tuiles de style

Le langage visuel d'une interface utilisateur est très important pour la convivialité et l'image de marque de l'application. Essayer de créer ce langage visuel avec la meilleure expérience utilisateur de l'application peut être un peu exagéré, tant au niveau de la phase de conception que de la communication et de la discussion de cette conception avec les membres de l'équipe ou les parties prenantes. La technique d'utilisation des mosaïques de style repose sur la conception du langage visuel d'une application sans réellement concevoir cette application.

Exemple d'une tuile de style

Exemple d'une tuile de style

Comme vous pouvez le voir dans l'exemple, la conception de la mosaïque de style définit clairement le langage visuel et l'image de marque de l'application sans nous montrer l'application réelle. Une méthode très rapide et efficace à utiliser. Surtout si une certaine expérimentation est encore nécessaire, ce qui peut conduire à plusieurs mosaïques de style parmi lesquelles choisir une.

4. Lignes directrices en matière de conception / d'identité d'entreprise

La plupart des entreprises disposent déjà de lignes directrices et d'éléments qui traitent de la conception de sites Web ou d'applications en ligne. S'ils existent, ils doivent absolument être inclus dans la section conception du Product Canvas.

Étape 6 : Créer des épopées

À ce stade, vous avez couvert et étudié vos utilisateurs, vous savez ce qu'ils essaient d'accomplir, vous avez conçu la manière dont ils peuvent y parvenir en utilisant l'application et vous avez même créé un cadre de conception. Vous disposez de toutes les informations dont vous avez besoin pour créer vos épopées, la première étape de la traduction de la conception de votre application en récits utilisateurs.

Notez que les épopées peuvent être considérées comme de très grandes histoires d'utilisateurs qui ne peuvent pas être terminées en un seul sprint ou qui doivent être divisées en histoires d'utilisateurs distinctes afin de pouvoir créer des histoires d'utilisateurs « prêtes » à partir d'elles. La plupart du temps, une épopée décrira une fonctionnalité plus vaste qui doit être découpée en sections pour la réaliser.

Un exemple serait l’épopée « Permettre à nos utilisateurs d’acheter leurs courses en ligne ». Cette épopée peut être divisée en récits d’utilisateurs traitant de la sélection des courses dans le magasin, de la définition d’une adresse de livraison et du paiement des courses à l’aide d’une option de paiement en ligne.

La raison pour laquelle créer des épopées plutôt que de simples user stories est une bonne idée est que cela permet de gagner beaucoup de temps et de concentrer le projet. La création de user stories prêtes à l'emploi prend beaucoup de temps. De plus, un backlog comprenant 500 user stories n'est pas facile à gérer. Il est préférable d'avoir 10 épopées et 20 user stories.

Étape 7 : Créer des histoires prêtes

La dernière étape de la création de votre Product Canvas est la création d’histoires utilisateur prêtes à l’emploi qui couvrent au moins le premier ou les deux premiers sprints.

Notez qu'une user story prête signifie qu'elle est conforme à la définition de ready. Comme c'est la première fois qu'une user story prête est livrée, il est judicieux d'impliquer (si elle est déjà disponible) toute l'équipe Scrum dans cette étape.

MendixExpériences positives avec l'utilisation de la méthode

At Mendix, nous avons eu de très bonnes expériences avec l'utilisation de la méthodologie Product Vision & Canvas. Nous l'avons utilisée pour une série de projets afin de lancer le projet. Nous avons même utilisé une version compacte du Product Canvas pour un projet de preuve de concept qui n'a duré qu'une semaine et dans lequel nous avons inclus des storyboards, des plans de site, des wireframes et des tuiles de style.

Certains des effets positifs que nous avons eu à Mendix, recueillis à partir des commentaires reçus des chefs de projet, des Scrum Masters et des développeurs :

  • Même un travail de préparation limité augmente considérablement la qualité du résultat final
  • Les ressources du Product Canvas fournissent l'attention nécessaire pour compléter une demande en moins de temps
  • Effet du premier coup : chaque étape du Canvas est composée de recherche, d'expérimentation, de conception et de réflexion. Améliorer le point de départ de la phase de développement. Ce qui conduit à son tour à presque aucune reprise en cours de projet
  • Amélioration de la communication et de l'efficacité au sein de l'équipe

Grâce à ces expériences positives, l’utilisation d’une phase de préparation et, plus particulièrement, de la méthodologie Product Vision et Canvas est désormais considérée comme la meilleure pratique.

Comment utiliser un canevas de produit

Bien que cet article de blog décrive le Product Canvas de manière très détaillée, l'une des leçons importantes est en fait l'avantage d'une phase de préparation avant de démarrer le premier sprint. La méthode donnée fonctionne bien avec Mendix projets, mais en fin de compte, tout est question de contenu, des questions auxquelles on répond avec le résultat de la phase de préparation, et des bénéfices que cela aura sur le reste du projet.

Un autre détail intéressant est que certaines équipes choisissent de continuer à utiliser le Product Canvas ou des parties de celui-ci tout au long du projet au lieu de se limiter à la préparation. Par exemple, elles utilisent une partie d'un mur de leur salle de guerre comme Product Canvas.

Mendix Les équipes ont utilisé les flux d'utilisateurs dans le cadre de la définition des user stories. La raison en était que la manière schématique du flux d'utilisateurs était beaucoup plus rapide et plus efficace pour que l'équipe comprenne pleinement l'histoire de l'utilisateur que le contenu textuel de l'histoire de l'utilisateur.

Mais surtout, peu importe qu'un projet soit petit ou grand, de faible ou de grande complexité, la bonne quantité de préparation se traduira toujours par un développement plus ciblé et plus efficace avec une augmentation de la qualité de l'application réelle.

Télécharger des modèles de canevas de produits

Téléchargez les modèles de canevas de produits et de vision :

Choisissez votre langue