Marketing & Ventes
Outils & données
Implémenter HubSpot
Optimiser HubSpot
CRM & DEV
MARKETING
INTÉGRATION D'OUTILS
Corentin Jacquemin, Directeur Marketing chez DigitaWeb
Plusieurs raisons peuvent expliquer l'échec du lancement d’un produit ou d’une solution mais une des causes les plus probables reste que le client n’arrive pas à en voir la valeur. En tant que marketeur, il est indispensable de pouvoir démontrer la valeur qu’une solution ou qu’un produit apporte à vos clients.
Pour cela, il est important de prendre le temps de penser et rédiger une User Story, récit utilisateur en français, pour comprendre les attentes de vos clients avant de vous lancer dans la production d’une solution. Par ailleurs, les user stories sont très utiles pour concevoir un site web ou une application par exemple.
Mais qu’est ce qu’une bonne User Story et comment la rédiger ?
La User Story est un concept issu de la méthode agile Scrum et, dans l’idée, c’est assez simple : il faut se mettre à la place des clients afin de déterminer quels sont leurs besoins. Par exemple, une User Story peut se formuler de cette manière : “ En tant que [profil client], je souhaite [objectif de la fonctionnalité] afin de [résultat] “. Prenons un cas concret pour mieux comprendre :
En tant qu’agriculteur, je souhaite pouvoir contrôler et garantir la qualité de mes légumes afin de les valoriser au mieux auprès de mes clients.
La User Story, écrite comme ceci, permet de relater le problème que rencontre le client sans orienter la solution qui va en découler.
Rédiger une User Story est le moyen le plus efficace de faire en sorte que l'équipe concentre tous ses efforts sur la livraison d’une solution aux véritables problèmes des utilisateurs et ainsi de valider que cette solution proposée répond bien aux besoins de ces derniers.
De plus, cela permet aux équipes de développement de mieux comprendre les demandes des clients et donc de les motiver et de les inciter à faire preuve de créativité et d'esprit critique lors de la création de solution.
En effet, rédiger la User Story permet d’impliquer toutes les parties prenantes à la réflexion portée sur le choix de la solution. En ayant cette vue, les équipes de développement peuvent être force de proposition et proposer des alternatives plus efficaces et plus en adéquation avec le besoin du client.
Ainsi, en ajoutant beaucoup de détails à sa User Story, on favorise indirectement le travail d’équipe et on aide à prévenir les éventuelles limitations de la solution envisagée auxquelles nous n’avions pas pensé.
La première étape pour bien rédiger un récit utilisateur est justement de bien identifier et d'apprendre à mieux connaître cet utilisateur. En effet, il y a généralement plus d'un type d'utilisateur qui va interagir avec vos différentes solutions. Ainsi, inclure une étape portant sur la définition du persona dans la conception d’une solution permet de mieux connaître l'éventail des objectifs et des besoins de vos utilisateurs. De plus, cela pourra être utilisé comme une sorte de liste de contrôle pour les concepteurs.
Ron Jeffries a proposé le concept des 3C pour décrire les éléments constitutifs d'une User Story. Ces trois éléments sont :
Carte : Les User Stories sont écrites sur des cartes (physiques ou digitales). Ce support permet d’y annoter des commentaires ou des informations supplémentaires. Par exemple, on pourra y retrouver la durée prévue du développement et des tests de la solution. Cette carte est utilisée dans le backlog du produit, la description doit donc être précise et détaillée.
Conversation : Les exigences du projet sont communiquées et comprises au cours d'un certain nombre de conversations menées entre les différentes parties prenantes (Product owner, développeurs, testeurs, etc.). Les détails supplémentaires qui ressortent de ces conversations vous permettent de décider en équipe quelles règles (c'est-à-dire quels tests) représentent la meilleure façon d'exécuter cette fonctionnalité. Le fait de consigner ces détails par écrit permet de les confirmer ultérieurement, lorsque vous êtes prêt à construire et à tester la fonctionnalité.
Confirmation : Les critères d'acceptation, discutés lors de la conversation, sont utilisés pour confirmer que la user story est terminée. Ces critères d'acceptation pourront évidemment être repris pour d’autres user stories s’ils sont pertinents. Définissez dès le départ ce qui doit fonctionner (les tests à réussir) pour que cette fonctionnalité soit acceptable. Des tests positifs et négatifs doivent alors être utilisés pour couvrir tous ces critères. Ainsi, pour confirmer que le récit utilisateur est terminé, les critères d'acceptation définis doivent être testés et satisfaits.
Après avoir correctement pris le temps de rédiger votre User Story (US), il est important de la vérifier pour voir si elle peut être optimisée. Pour cela, vous pouvez utiliser la méthode INVEST pour vérifier que vous n’avez rien oublié. Selon cette dernière, une bonne user story devrait être :
Independent : La US ne doit pas dépendre d’autres user stories pour être efficace. Ou plutôt, la réalisation technique de la solution répondant au problème posé par la US ne doit pas dépendre de celle d'une autre US.
Negotiable : La US ne doit prendre en compte que le besoin de l’utilisateur sans trop rentrer dans le détail technique de votre fonctionnalité. En effet, le récit utilisateur sert à traduire un besoin utilisateur de manière simple et naturelle sans entrer dans un jargon technique afin qu’il permette la collaboration de toutes les expertises.
Valuable : C’est assez élémentaire mais il ne faut pas oublier que la US doit chercher à fournir de la valeur à l’utilisateur final.
Estimable : Les US doivent pouvoir être estimées afin qu’elles puissent être correctement intégrées dans les plannings. Plus concrètement, il s’agit de s’assurer que l’équipe a une discussion autour de la solution technique pour réaliser la Story afin de donner une estimation de l’effort pour la réaliser.
Small : La US doit correspondre à la capacité en temps et en compétences dont votre équipe dispose, donc faites en sorte de prendre cela en compte avant de la livrer.
Testable : Une US doit être confirmée via les critères d’acceptation que nous avons évoqués précédemment.
Ainsi, si votre User Story remplit toutes ces conditions, vous pouvez alors considérer qu’elle est correctement rédigée !
La User Story est un outil qui ne sert pas seulement à créer une fonctionnalité, mais aussi à promouvoir la collaboration et la transparence entre les membres des équipes et les différentes parties prenantes. La rédaction de bons récits utilisateur est une nécessité pour les projets agiles, car elles clarifient les exigences et aident à concevoir des fonctionnalités et des produits qui sont approuvés et appréciés par le client. C’est également pour cette raison que même pour ceux ne se considérant pas “agile”, la User Story peut être un outil très efficace.