Avant de construire votre MVP, il est important d'en définir son périmètre fonctionnel et de le structurer.
Le périmètre fonctionnel d'un MVP
Partons de la définition Larrouse d'un périmètre. La voici : « la longueur de la ligne qui délimite les contours d'une surface ». Imaginez donc le « périmètre fonctionnel » de votre MVP comme un cercle ne contenant que la (ou les) fonctionnalité(s) principale(s) de votre produit.
Le schéma ci-dessous expose une proposition de périmètre fonctionnel du MVP de notre Airbnb de la sieste, Nap Spot. Il s'agit de la partie verte.
En dehors de ce cercle (dans la zone bleue) se trouvent des fonctionnalités ou des idées à implémenter dans le futur, mais pas essentielles au fonctionnement du produit.
Le périmètre fonctionnel de votre MVP représente donc l'ensemble (restreint) des actions que vous allez rendre disponibles à vos utilisateurs.
Le risque lorsque vous définissez le périmètre fonctionnel de votre prototype est double :
votre périmètre est trop réduit, auquel cas vous n'arriverez pas à reproduire l'expérience utilisateur que vous souhaitez offrir à vos clients ;
votre périmètre est trop large (souvent le cas le plus fréquent), ce qui impliquerait des investissements en termes de temps (notamment le vôtre), énergie et argent beaucoup trop importants.
Dans ce cours, vous découvrirez comment réaliser un prototype fonctionnel pouvant se placer parfaitement entre ces deux cas. En somme, un MVP assez fonctionnel pour réellement tester une hypothèse, mais ne nécessitant que très peu d'investissements.
Comment définir le périmètre fonctionnel ?
Il existe plusieurs options pour préparer dans les meilleures conditions la première étape du cycle d'apprentissage lean (construire). Vous avez maintenant une idée assez précise de ce que vous souhaitez construire, il est alors temps de la structurer.
Le backlog produit
Dans les méthodes agiles et notamment SCRUM, le document censé rassembler toutes les fonctionnalités d'un produit s'appelle le backlog produit.
En somme, le backlog produit et une liste de fonctionnalités triées par ordre de priorité et documentées (si nécessaire).
L'importance des informations présentes dans le backlog s'adapte à la phase de maturité du produit. Lorsque vous commencez à construire un MVP, vous aurez tendance à vous concentrer sur sa sortie rapide sur le marché plutôt que sur la maintenance d'un backlog produit parfait.
Le backlog produit est en effet un outil évolutif qui grandira avec votre produit et votre équipe. C'est une des raisons pour lesquelles un outil comme Trello est un compagnon de choix pour créer son backlog.
Un outil pour organiser votre backlog : Trello
Trello est un outil pratique pour centraliser, structurer et rassembler les informations concernant le fonctionnement d'un produit (peu importe son stade d'avancement). C'est un outil en ligne complètement gratuit, super accessible et très flexible.
Si vous ne connaissez pas encore Trello, jetez un œil à ce lien pour avoir un aperçu de sa puissance : https://trello.com/tour.
Une fois dans votre tableau, créez une première liste appelée « Backlog Produit ». Et voilà ! Il n’y a plus qu’à !
Très bien, le backlog produit, c’est une liste priorisée des fonctionnalités d’un produit. Mais alors, comment devrais-je décrire une fonctionnalité ?
Excellente question ! Il pourrait être tentant de simplement remplir votre liste avec des cartes nommées « Module de réservation » ou « Possibilité de créer un compte ». Cependant, il est de coutume, lorsque l’on souhaite « poser sur papier » une fonctionnalité, de rédiger ce que l’on appelle des user stories (récits utilisateurs en Français).
Anatomie d’une user story
Une user story est« une courte phrase décrivant en détail l’action que l’on souhaite rendre disponible à nos utilisateurs ».
Dans notre liste « Backlog produit » sur Trello, elle serait représentée par une simple carte.
Une user story (aussi appelée US) se compose de 3 parties distinctes, un type d'utilisateur, une action à réaliser et une finalité.
🤔Voyons en détail à quoi cela ressemble !
« En tant que [type d'utilisateur], j'aimerais pouvoir [action à réaliser] dans le but de [finalité]. »
2. Le type d'utilisateur
Libre à vous de segmenter votre audience. Vous pourriez très bien appeler toutes les personnes visitant votre site des « utilisateurs ». Plus vous détaillez votre user story, mieux vous vous mettez en situation.
Une personne qui visite pour la première fois votre site pourrait alors s’appeler un « visiteur » plutôt qu’un « utilisateur ». Un utilisateur quant à lui pourrait rentrer dans la catégorie des personnes ayant créé un compte ou même déjà « utilisé » votre service (réserver une sieste par exemple).
Partons donc sur un visiteur et rédigeons la première partie de notre user story :
« En tant que [visiteur de Nap Spot]... »
2. L’action à réaliser
Vous l’avez compris, cette partie sert à décrire avec précision l’action que notre utilisateur doit être capable de réaliser sur votre application. Encore une fois, le contexte est clé.
Si vous rédigez la story concernant la création d’un compte alors mettez-vous bien à la place du visiteur de votre site (qui n’est pas encore un utilisateur 🤓) :
« En tant que visiteur de Nap Spot, j’aimerais pouvoir [créer un compte]... ».
Pour aller plus loin, vous pouvez commencer à documenter votre fonctionnalité en indiquant dans la carte Trello les informations nécessaires à la « création d’un compte » (via une checklist par exemple).
Pour aller plus loin, c'est aussi dans cette carte que vous pouvez ajouter d'éventuelles wireframes (si besoin) concernant la fonctionnalité et toute la documentation nécessaire à son bon développement.
3. La finalité
Bien qu'optionnelle, cette partie de la story vous permet de vous immerger encore plus dans l’exercice. Elle consiste à décrire la finalité de l’action réalisée.
Reprenons notre exemple :
« En tant que visiteur de Nap Spot, j’aimerais pouvoir créer un compte afin d’être en mesure [d'utiliser le service proposé] ».
Comme vous pouvez le constater, cet exercice permet dans un premier temps de se mettre à la place de notre utilisateur, mais aussi de communiquer simplement l'objectif et le comportement attendu d’une fonctionnalité à des équipes de développement (et autres).
