20 Exemples d’histoires d’utilisateurs et bonnes pratiques

Comment commencer à concevoir une appli ou un site web performant qui fera mouche auprès de vos utilisateurs ? Les récits d’utilisateurs sont votre meilleur ami lorsqu’ils sont associés à un outil de wireframe!

Les histoires d’utilisateurs nous aident à intégrer nos user persona dans le contexte du produit que nous sommes en train de concevoir. Alors que la bio d’un user persona décrit sa vie et ses malheurs, l’histoire d’utilisateur décrit comment il utilise une fonctionnalité de votre produit – en termes simples ! Dans l’environnement agile, les Product Owners, ainsi que les UX designers, ont tendance à écrire les user stories sur des fiches qui circulent au sein de l’équipe de design et suscitent la conversation. Nous pouvons également les écrire numériquement, en utilisant Office ou Google Docs pour les inclure dans le backlog Scrum. Le fait qu’elles soient rédigées dans un langage simple et dépourvu de tout jargon technique signifie que l’équipe de design se sent moins limitée par les aspects techniques. Elle peut ainsi faire preuve d’une plus grande créativité dans la conception des fonctionnalités. Poursuivez votre lecture pour découvrir d’excellents exemples d’histoires d’utilisateurs !

Une histoire d’utilisateur est une brève description de ce qu’un produit doit faire, à qui il s’adresse et pourquoi il est nécessaire. Elle est généralement rédigée en une ou deux phrases et suit un format simple pour faciliter la compréhension et l’action. Une histoire d’utilisateur typique ressemble à ceci : « En tant que ( user persona), je veux (une action) pour que (un avantage/une valeur) ». Cette structure aide les équipes à comprendre les besoins de l’utilisateur sans entrer dans les détails techniques.

Travailler avec des récits d’utilisateurs présente plusieurs avantages avérés, c’est pourquoi de nombreuses équipes agiles à travers le monde les adoptent. Voici quelques-unes des principales raisons pour lesquelles les équipes agiles donnent la priorité aux récits d’utilisateurs.

L’un des principaux avantages des récits d’utilisateur est de diviser des produits ambitieux et gigantesques en ensembles de fonctionnalités plus petits et plus réalisables. Les histoires d’utilisateurs sont simplement une brève déclaration des objectifs de l’utilisateur dans ses propres mots. Elles aident les groupes à éviter de s’embourber dans les détails, les protocoles, les aspects techniques et les procédures.

Les récits d’utilisateurs sont très utiles pour aider les équipes à déterminer les fonctionnalités à développer en priorité. Lorsqu’elles sont utilisées comme éléments du carnet de commandes, elles facilitent l’organisation et la répartition des tâches ou des exigences en matière de fonctionnalités dans les sprints. Ceci est crucial pour une rédaction efficace des histoires d’utilisateurs et des pratiques agiles d’histoires d’utilisateurs.

Les histoires d’utilisateurs donnent aux équipes agiles des critères concrets pour effectuer des tests. Chaque histoire doit avoir un résultat clair et démontrable, garantissant que l’histoire de l’utilisateur atteint le résultat souhaité. Cela permet aux équipes de mesurer plus efficacement les performances et les résultats au cours de chaque sprint.

Les récits d’utilisateurs permettent d’identifier la valeur que certaines fonctionnalités offriront aux utilisateurs. Les équipes agiles peuvent se concentrer sur les fonctionnalités les plus importantes et les plus immédiates, ce qui permet de travailler de manière plus efficace et plus rentable pour les clients et les parties prenantes, tout en bénéficiant à l’utilisateur.

Comme les récits d’utilisateurs sont dépourvus du jargon technique que l’on trouve dans de nombreux autres documents de développement de produits, ils permettent à l’équipe de se livrer à des spéculations plus créatives. Cela favorise un dialogue plus créatif et plus souple entre les équipes de développement et de design. Avec les récits d’utilisateurs, l’accent n’est plus mis sur les caractéristiques et les détails techniques, mais sur le point de vue de l’utilisateur et les utilisations potentielles du produit. Les parties prenantes non techniques qui souhaitent savoir sur quelles fonctionnalités on travaille et quelle est l’orientation du projet devraient également trouver cette méthode très utile.

Les récits d’utilisateurs peuvent donner vie aux user personas, en impliquant dans le projet ces personas fictifs mais basés sur la vie réelle. C’est comme si des représentants de milliers ou de millions d’utilisateurs guidaient l’équipe de développement sur ce dont ils ont besoin, au lieu que l’équipe se contente de l’imaginer. Les histoires d’utilisateurs peuvent être combinées pour former des cartes d’histoires d’utilisateurs, une technique agile productive où toutes les histoires sont organisées pour créer un calendrier de développement et une liste de priorités.

La manière dont les équipes agiles rédigent les récits d’utilisateurs varie souvent d’une organisation à l’autre et d’une équipe à l’autre. Pour réussir à rédiger des histoires d’utilisateurs, vous devez toujours prendre en compte les éléments suivants afin de fournir à votre équipe une image complète de ce qui est exactement nécessaire à chaque étape du développement du produit : – User
– Action
– Bénéfice Avec ces trois éléments, vous pouvez rédiger une brève histoire d’utilisateur concernant la fonctionnalité(exigence du produit) dont votre persona a besoin et pourquoi il en a besoin. Nous rédigeons normalement l’histoire de l’utilisateur avec la structure suivante : En tant qu’utilisateur de ____, je veux ____ pour pouvoir ____. Supposons que vous souhaitiez créer une application de conduite sociale qui permette aux conducteurs de voir où se trouvent leurs amis. Elle leur permet également de publier des mises à jour sur les retards de circulation, les accidents ou les conditions météorologiques en utilisant leur voix. Vous pourriez remplir la structure ci-dessus de la manière suivante :

Vous pouvez ensuite inclure ce que l’on appelle un critère d’acceptation (que nous examinerons plus en détail ci-dessous) qui énumère les spécifications techniques requises pour garantir que les besoins de l’utilisateur sont satisfaits. Il peut s’agir des éléments suivants

• L’application doit reconnaître la commande vocale de l’utilisateur pour commencer un nouveau message.
• L’application doit lire les messages de l’utilisateur et les lui renvoyer.
• L’application doit demander à l’utilisateur de confirmer qu’il souhaite publier.
• Les notifications doivent être envoyées aux amis du réseau.

Mais qu’en est-il lorsque vous devez écrire plus d’une histoire d’utilisateur, par exemple ? Après tout, votre application ou votre site web comportera de nombreuses fonctionnalités et vos témoignages d’utilisateurs seront courts. Comment les classer en sous-fonctionnalités ? La réponse est en écrivant des histoires épiques.

Les histoires épiques vous aident à brosser un tableau plus large en résumant une action complexe composée d’actions plus petites. En ce sens, l’histoire d’utilisateur épique est comme une vue d’ensemble d’une fonctionnalité de produit. Les récits épiques sont rédigés exactement de la même manière que les récits d’utilisateurs, mais ils sont moins spécifiques. En voici un exemple :

Cet exemple d’histoire d’utilisateur épique peut ensuite être subdivisé en exemples d’histoires d’utilisateurs plus spécifiques pour la même application, comme dans l’exemple suivant :

Ou bien :

Enfin, vous devez toujours rédiger vos user stories du point de vue de votre user persona. Par exemple, n’écrivez pas une histoire qui, pour qu’elle soit testée, nécessiterait qu’une autre fonctionnalité soit d’abord développée ou designée. Lorsque vous faites cela, vous vous engagez sur un terrain dangereux qui, dans le monde agile, est appelé « impasse ». Cela ressemble beaucoup à l’échec et mat aux échecs. C’est le moment où vous n’avez nulle part où aller. Mark Shead, auteur de Starting Agile, a donné l’exemple suivant d’une histoire d’utilisateur vague et mal écrite lors de sa vidéo Agile User Stories (Histoires d’utilisateur agiles) :

Dans ce cas, la base de données devrait déjà exister, ce qui rendrait le résultat de l’histoire de l’utilisateur (stockage des informations) dépendant de la base de données.

De nombreuses équipes qui se trompent dans les histoires d’utilisateurs se retrouvent souvent dans cette impasse ou ce marasme. Le client leur demande une mise à jour et ils répondent que pour commencer à développer l’application, ils doivent d’abord terminer le « travail d’installation ». Or, dans l’idéal, ce « travail d’installation » ne devrait jamais exister. Si les histoires d’utilisateurs ne peuvent pas lancer l’action dès le début, vous vous trompez probablement. Les bonnes histoires d’utilisateur peuvent être indépendantes et se fondre dans d’autres pour donner une image du produit dans son ensemble. Parfois, une idée n’est pas mauvaise, elle est simplement mal présentée, comme c’est le cas dans l’exemple de l’histoire d’utilisateur mal écrite ci-dessus.

Tout d’abord, et avant toute chose, avant de vous lancer dans la rédaction de vos user stories, il est essentiel que vous meniez les recherches appropriées sur les utilisateurs et que vous définissiez vos user persona. Pourquoi ? Parce que c’est précisément sur ces user persona que se baseront vos histoires d’utilisateurs. Les user personas sont la première étape pour rédiger une histoire d’utilisateur réussie, car si vous ne savez pas qui est l’utilisateur, comment est-il possible de rédiger votre histoire du point de vue de l’utilisateur ?

Lorsqu’il s’agit de la technique de rédaction d’une histoire d’utilisateur, il y a trois exigences de base à garder à l’esprit avant de commencer. Ou, si vous essayez de vendre l’idée à d’autres parties prenantes. C’est ce qu’on appelle les 3 C :

• Carte
• Conversation
• Confirmation

L’objectif des histoires d’utilisateurs est de fournir une déclaration simple sur une carte. Rapide et facile. Le « C » suivant est « Conversation » – l’intérêt des user stories est de susciter une conversation créative et une collaboration entre les équipes agiles. Enfin, le dernier « C » est « Confirmation », qui fait référence aux critères d’acceptation que nous pouvons tester une fois que nous avons construit la fonctionnalité de l’histoire d’utilisateur.

La méthode INVEST est une excellente règle empirique pour vous guider vers la rédaction des meilleures histoires d’utilisateurs possibles. La méthode INVEST est un moyen mnémotechnique pour les meilleures pratiques suivantes :

Les histoires d’utilisateurs, bien qu’elles soient souvent incluses dans des épopées, devraient également être compréhensibles en tant qu’éléments autonomes.

Les récits d’utilisateurs doivent offrir une grande flexibilité. C’est pourquoi elles ne doivent pas inclure de détails techniques spécifiques. Après tout, la flexibilité est la nature même de l’environnement scrum.

L’histoire de l’utilisateur doit offrir de la valeur, à la fois à l’équipe et à vos user persona. Elle doit donner à votre équipe une idée claire des objectifs qu’une fonctionnalité doit atteindre lorsqu’elle la conçoit et la développe. Et pour l’utilisateur, cela signifie un produit qui répond constamment à ses besoins.

Il devrait être possible d’estimer la quantité de travail nécessaire pour une fonctionnalité proposée dans une histoire d’utilisateur. Cela vous aidera à affecter les points de scrum pertinents à la tâche du backlog et à gérer le temps de manière efficace.

Une histoire d’utilisateur doit être courte et mémorable. Il suffit de deux lignes pour décrire ce que l’utilisateur souhaite réaliser grâce à une fonctionnalité spécifique de votre produit. S’il s’agit d’une description globale de votre application ou d’une catégorie de fonctionnalités, écrivez un récit épique et décomposez-le en sous-récits. L’histoire de l’utilisateur devrait idéalement tenir en une seule itération. Vous ne devez pas non plus mentionner de spécificités concernant le design de l’UI dans une user story.

Comme pour la plupart des éléments du processus de développement, vos histoires d’utilisateurs doivent être facilement testables et comporter des mesures claires et déductibles pour les indicateurs clés de performance. C’est généralement là que les critères d’acceptation entrent en jeu.

Ensuite, la meilleure chose que nous puissions vous conseiller pour rédiger régulièrement de bonnes histoires d’utilisateurs est d’utiliser un modèle. C’est un excellent moyen de s’assurer que vous et tous les membres de votre équipe qui rédigent des histoires d’utilisateurs couvrent toujours le qui, le quoi et le pourquoi. Ce sont les détails dont vous avez besoin pour vous assurer de capturer toutes les informations nécessaires de la manière la plus concise possible.

Il existe de nombreux modèles numériques utiles qui peuvent également être imprimés ou utilisés dans Jira ou un autre système Kanban. Mais ce qui est formidable, c’est que les modèles peuvent également comporter de nombreux autres champs qui peuvent être utiles, comme les points de mêlée et une zone pour écrire vos critères d’acceptation. L’utilisation d’un modèle pour les épopées composées de nombreuses histoires secondaires peut également être un excellent moyen d’organiser une série de micro-fonctionnalités tournant autour d’une macro-fonctionnalité plus importante.

Les histoires candidates sont une étape facultative lorsqu’il s’agit de rédiger des histoires d’utilisateur. Ce sont les histoires que votre équipe écrit en premier pour lancer le processus lorsque vous essayez de déterminer ce que l’utilisateur veut sur la base de ses personas. Cette étape facultative peut être un excellent moyen de faire du brainstorming en utilisant des fiches physiques lors d’une réunion. Les histoires candidates n’ont même pas besoin de suivre la structure typique des vraies histoires d’utilisateurs. Les histoires candidates réussies produites par votre équipe peuvent ensuite être développées pour devenir de vraies histoires d’utilisateur.

Les critères d’acceptation sont essentiels pour les histoires d’utilisateurs. Ils précisent ce qui doit être fait pour qu’une histoire soit considérée comme terminée, garantissant ainsi que le produit répond aux besoins de l’utilisateur.

L’objectif principal des critères d’acceptation est de définir les conditions qui doivent être remplies pour qu’une histoire d’utilisateur soit acceptée. Ils permettent de s’assurer que tout le monde, des utilisateurs aux développeurs, comprend ce que le produit fini doit faire.

Il existe plusieurs façons de rédiger des critères d’acceptation. L’une des méthodes les plus répandues est le format « donné/parce que/parce que » :

• Dans une situation donnée,
• Lorsque quelque chose se produit,
• Un certain résultat devrait alors s’ensuivre.

Une autre méthode simple est la liste de contrôle. Il s’agit d’énumérer toutes les conditions qui doivent être remplies sous forme de puces. Cette approche est claire et facile à utiliser.

Rédigez les critères d’acceptation de manière simple et claire. Faites en sorte que votre langage soit compréhensible. Veillez à ce que les exigences puissent être testées afin de les quantifier et de les valider. Impliquez tous les membres de l’équipe dans le processus afin d’obtenir leur avis.

L’inclusion de critères d’acceptation bien définis dans vos histoires d’utilisateurs améliore la rédaction de celles-ci. Ils fournissent des lignes directrices claires pour le développement et les tests, en s’assurant que le produit final répond aux besoins de l’utilisateur. Il s’agit d’un élément important de la méthode agile des user stories, qui aide les projets à rester sur la bonne voie et à s’aligner sur les objectifs des utilisateurs.

Une façon de décider si une fonctionnalité d’une histoire d’utilisateur est testable est de rédiger des critères d’acceptation pour chacune des fonctionnalités que vous créez. Parfois, les critères d’acceptation peuvent inclure une liste de plusieurs variables qui doivent être vraies après le développement de la fonctionnalité. Voici un exemple :

Les critères d’acceptation pourraient ressembler à ce qui suit : « Après s’être enregistré, l’utilisateur doit avoir la possibilité, sur l’écran de connexion, de se connecter avec son compte Google. » Parfois, il suffit de lire l’histoire de l’utilisateur pour comprendre quels devraient être les critères d’acceptation. Cependant, quelle que soit la longueur de l’histoire, il est toujours bon de rédiger vos critères d’acceptation. Cela évite à votre équipe de tomber dans des habitudes paresseuses et de ne jamais en écrire. Il est préférable de penser déjà aux critères d’acceptation lorsque vous écrivez votre histoire d’utilisateur. Si vous ne pouvez pas penser aux critères d’acceptation, cela signifie que la fonctionnalité ne peut pas être testée. Cela signifie que vous devriez repenser cette fonctionnalité particulière. Si, en revanche, vous trouvez que les critères d’acceptation sont trop longs pour figurer sur une carte d’index, vous devriez envisager de les répartir dans une autre histoire d’utilisateur, ou peut-être même d’en faire une histoire épique. Voilà autant d’éléments auxquels vous pouvez penser lorsqu’il s’agit de rédiger des critères d’acceptation.

Les récits d’utilisateurs sont comme le cœur d’un projet d’équipe, les guidant pour qu’ils se concentrent sur ce que leurs clients veulent vraiment en transformant les grandes idées en petites étapes réalisables.

Ces histoires d’utilisateurs sont rédigées du point de vue de l’utilisateur, ce qui permet à l’équipe de comprendre ce dont l’utilisateur a besoin et pourquoi. Cela permet à chacun de se concentrer sur la création d’un produit qui sert vraiment ses utilisateurs.

Les histoires d’utilisateurs sont comme des blocs de construction, ajoutés à la liste de tâches globale de l’équipe. La personne qui dirige l’équipe décide ensuite quelles sont les histoires qui comptent le plus pour ses clients, en déterminant celles qui doivent être abordées en premier. Lorsque l’équipe se réunit pour planifier, elle choisit les histoires sur lesquelles elle se concentrera ensuite à partir de cette liste principale.

Chaque histoire est assortie d’un ensemble de conditions, comme une liste de contrôle, qui doivent être remplies avant que l’histoire ne soit considérée comme « terminée ». Cela permet de s’assurer que tout le monde est d’accord sur ce à quoi ressemble un travail fini, et de maintenir la barre haute tout au long du projet.

Les récits d’utilisateur offrent de grands avantages pour les projets agiles. Elles divisent les grands projets en tâches plus petites et plus faciles à réaliser, ce qui permet à l’équipe de rester plus facilement organisée et sur la bonne voie. Cela signifie que l’on en fait plus et que les choses avancent plus vite.

Ils facilitent également la communication, tant au sein de l’équipe qu’avec les autres personnes impliquées dans le projet. Un langage simple permet à chacun de comprendre les objectifs du projet et ce qui doit être fait, afin que tout le monde soit sur la même longueur d’onde.

De plus, les récits d’utilisateurs favorisent la collaboration entre les membres de l’équipe. Elles initient des discussions sur les moyens les plus efficaces d’atteindre les résultats souhaités, en générant des idées et des solutions innovantes. Cette approche collaborative garantit que le produit s’adapte et évolue en fonction des besoins réels des utilisateurs et de leur retour d’information.

Examinons quelques exemples d’histoires d’utilisateurs dans des projets agiles et la manière dont elles fonctionnent dans des situations réelles :

• Pour un site web : « En tant que visiteur, je souhaite m’inscrire facilement à la lettre d’information afin de recevoir des mises à jour et des promotions.
• Pour une application mobile : « Si j’utilise l’application et que j’oublie mon mot de passe, je veux un moyen simple de le réinitialiser.
• Pour une boutique en ligne : « Lorsque je fais des achats en ligne, je veux filtrer les articles par prix afin de trouver facilement ce qui correspond à mon budget. »

Chacun de ces exemples se concentre sur ce que veut l’utilisateur et sur la valeur qu’il retire de l’utilisation de cette fonctionnalité spécifique. C’est ainsi que les équipes construisent des produits que les gens trouvent vraiment utiles et qu’ils veulent continuer à utiliser.

Dans le cadre du développement d’un produit, il est essentiel de comprendre les utilisateurs. Pour ce faire, un certain nombre d’outils sont utilisés. En voici un en quoi ils diffèrent et quand les utiliser.

Les besoins des utilisateurs sont des énoncés simples de ce qu’ils veulent faire ou des problèmes qu’ils veulent résoudre. Ces objectifs servent de base à l’élaboration et à la hiérarchisation des fonctionnalités.

Quand l’utiliser ? Utilisez les besoins des utilisateurs au tout début du développement du produit pour définir ce que le produit doit faire.

Les types d’utilisateurs sont des descriptions détaillées des différents types de personnes susceptibles d’utiliser votre produit. Il s’agit de personnages basés sur des recherches et comprenant des informations telles que l’âge, les habitudes, les souhaits et les défis.

Quand l’utiliser ? Créez des profils d’utilisateurs dès le début du processus de design afin de mieux comprendre vos utilisateurs et d’adapter le produit à leurs besoins spécifiques.

Les histoires d’utilisateurs sont des explications étape par étape de la manière dont un type d’utilisateur interagit avec le produit pour atteindre un objectif. Elles montrent comment le produit est utilisé et peuvent mettre en évidence des problèmes potentiels.

Quand l’utiliser ? Utilisez les récits d’utilisateurs pendant la phase de design pour schématiser la façon dont les utilisateurs interagissent, trouver des domaines à améliorer et rendre le produit plus facile à utiliser.

Les récits visuels sont des représentations visuelles d’histoires d’utilisateurs, combinant souvent des images et des mots pour montrer clairement l’expérience de l’utilisateur.

Quand l’utiliser ? Utilisez des images d’utilisateurs pendant les revues de design et les présentations pour faciliter la communication, obtenir des commentaires et améliorer le produit en fonction de ce que les utilisateurs voient et expérimentent.

Besoins de l’utilisateur : Définir ce que le produit doit faire.

Types d’utilisateurs : Représenter les différents types d’utilisateurs et éclairer les choix de design.

Histoires d’utilisateurs : illustrent la manière dont les utilisateurs interagissent et facilitent l’utilisation du produit.

Images d’utilisateurs : Améliorez la communication et visualisez l’expérience de l’utilisateur.

Nous avons inclus à la fois des exemples d’histoires d’utilisateurs traditionnelles écrites sur des cartes d’index ou des notes autocollantes, ainsi que des exemples d’histoires d’utilisateurs numériques qui peuvent facilement être partagées sur une plateforme en ligne. Certains se présentent même sous la forme de modèles téléchargeables tels que des fichiers Word et Excel ! Plongeons dans le vif du sujet :

Cet exemple de récit d’utilisateur Plan de produit comporte cinq sections importantes. La première est le titre de l’histoire. Vous pouvez donner le nom de la fonctionnalité sur laquelle porte l’histoire, par exemple « critiques de livres ».

Dans la section Priorité, vous pouvez attribuer une priorité faible, moyenne ou élevée. Il est important d’attribuer des priorités aux éléments de votre backlog, car certaines fonctionnalités seront plus demandées, selon votre matrice de traçabilité des exigences. La section Estimation se trouve à côté de Priorité. Vous pouvez y indiquer le temps que vous pensez qu’il faudra à l’équipe pour livrer cette fonctionnalité. Ici, vous pouvez attribuer le nombre approprié de points de mêlée. Ensuite, dans cet exemple de récit d’utilisateur, vous avez la section du récit d’utilisateur lui-même, et enfin, les critères d’acceptation. Les critères d’acceptation sont souvent inscrits au dos de l’index, mais comme il s’agit d’une copie numérique en deux dimensions, les critères d’acceptation sont clairement inscrits juste en dessous, comme une sorte de conclusion. Certains trouveront peut-être utile que tout soit inclus sur la même page.

Ce document Word modifiable est facile à utiliser et contient des instructions claires pour chaque clause et critère d’acceptation. À notre avis, les instructions qui suivent chaque clause du récit de l’utilisateur, ainsi que celles relatives aux critères d’acceptation, sont assez simples à suivre.

Pourquoi est-il important d’avoir ces instructions dans votre modèle de récit utilisateur ? Parce que si votre équipe n’a pas écrit d’histoires d’utilisateur pendant un certain temps, ou si vous devez travailler sur de nombreuses histoires, il est bon d’avoir ce type d’instructions pour vous aider. Elles vous rappellent utilement la qualité des informations qui doivent figurer dans chaque clause.

Quoi de mieux qu’Excel pour regrouper des informations dans des tableaux ? Ce modèle de récit d’utilisateur excel est également un peu différent en ce sens qu’en plus des champs habituels, il vous donne la possibilité de remplir d’autres informations importantes.

Les champs supplémentaires que vous pouvez trouver dans cet exemple d’histoire d’utilisateur comprennent la valeur commerciale de l’utilisateur, le calcul du risque, le coût du retard et la pondération du travail le plus court en premier. Ces informations supplémentaires peuvent également être utiles, selon le type de caractéristiques du produit sur lequel vous travaillez, ou le type de clients ou d’entreprises pour lesquels vous travaillez.

Dans cet exemple de récit thématique basé sur Excel, vous disposez d’une colonne pour l’estimation de la priorité, les critères d’acceptation, ainsi que d’une colonne « Release » pour la date de publication.

Les colonnes de cet exemple d’histoire d’utilisateur sont bien ordonnées, avec les thèmes disposés verticalement et les types de colonnes horizontalement. Il s’agit d’un excellent modèle pour une histoire épique composée de plusieurs histoires secondaires.

En parlant d’exemples d’histoires d’utilisateurs épiques, vous pouvez jeter un coup d’œil à ce modèle d’histoire d’utilisateur épique. Il constitue un excellent moyen de regrouper les sous-stories en fonction de leurs histoires épiques. Chaque caractéristique de l’histoire épique est listée verticalement, les colonnes étant consacrées à l’utilisateur, à l’action ou au souhait et à l’avantage. La dernière colonne consiste ensuite en une disposition verticale des histoires d’utilisateurs dans des sous-fleuves enveloppés dans chaque cellule.

La façon dont cette histoire d’utilisateur épique est présentée permet de montrer une hiérarchie claire entre les histoires épiques et leurs histoires d’utilisateur multiples et détaillées. Il est ainsi très facile de parcourir et d’obtenir une vue d’ensemble rapide de toutes les fonctionnalités qui doivent être appliquées ou développées pour satisfaire l’utilisateur.

Ce modèle téléchargeable d’histoire d’utilisateur de Powerslides nous montre une autre façon élégante d’organiser nos histoires d’utilisateur. Ces cartes peuvent être montrées dans une présentation PowerPoint, mais aussi imprimées et distribuées. Nous apprécions également la division claire des sections les plus importantes : l’histoire de l’utilisateur et l’identification de l’utilisateur, ainsi que quelques sections qui la différencient des autres exemples.

Dans la section histoire, nous pouvons voir l’histoire de l’utilisateur et les critères d’acceptation. Cependant, sous la section user persona se trouve une zone où vous pouvez joindre une photo de votre user persona, ainsi que quelques cases à cocher pour le type de fonctionnalité sur lequel il se concentre et des champs pour la priorité et l’estimation du temps.

Ce que nous aimons dans cette bonne vieille histoire d’utilisateur en forme de carte d’index, c’est sa simplicité et la façon dont elle ramène les choses à l’essentiel. Il peut arriver que vous ayez besoin de rédiger rapidement une histoire pour une fonctionnalité de produit ou une vue d’ensemble rapide des fonctionnalités comme une épopée.

Cet exemple simple et traditionnel d’histoire d’utilisateur nous montre exactement à quel point cela peut être facile. L’avantage des fiches est que vous pouvez également écrire les critères d’acceptation au verso et faire circuler la fiche d’histoire de l’utilisateur au sein de l’équipe.

Nous avons ici un exemple d’histoire d’utilisateur traditionnelle qui reflète la manière dont on pourrait rédiger une histoire d’utilisateur sur une carte d’index. L’histoire montre clairement ce que l’utilisateur veut réaliser et pourquoi il veut le faire. Dans ce cas, il veut annuler ses réservations pour ne pas perdre tout son argent en cas de problème.

Au verso de la carte, les critères d’acceptation sont énumérés. Ils indiquent toutes les fonctions de l’application qui doivent être prises en charge pour que les avantages de l’utilisateur et les avantages des objectifs de l’entreprise soient satisfaits.

Cet exemple d’histoire d’utilisateur d’application bancaire est un excellent moyen d’expliquer une fonctionnalité requise et pourquoi l’utilisateur en a besoin d’une manière succincte. Il va directement à l’essentiel, à savoir qui est l’utilisateur et ce qu’il doit accomplir. En fait, l’un des aspects les plus intéressants de cet exemple est qu’il fait même allusion à l’une des douleurs que l’utilisateur d’une application bancaire (dans ce cas, le titulaire d’une carte de crédit) pourrait typiquement ressentir, comme s’inquiéter du solde de sa carte de crédit, conserver un bon score de crédit et ne pas être dans le rouge.

L’utilisateur dans cet exemple de récit d’utilisateur veut payer son solde, donc la première chose que l’équipe de design pourrait faire est de commencer à travailler sur une solution qui lui donne un accès plus ou moins instantané au solde de sa carte de crédit. Soit il s’agit de la première chose qu’il voit lorsqu’il ouvre l’application, soit il y a une option claire qui lui permet de voir le solde de sa carte à portée de main.

Notre prochain exemple d’histoire d’utilisateur de Whizible est également un modèle que vous pouvez télécharger pour vous donner, à vous et à votre équipe, une longueur d’avance. Ce modèle vous permet d’écrire une liste de plusieurs histoires d’utilisateur sur la même carte. Les colonnes horizontales du haut affichent la phrase type de l’histoire d’utilisateur, ce qui signifie qu’il suffit de remplir les espaces vides.

Cela permet de gagner du temps lors de la rédaction de plusieurs user stories et d’aller droit au but. Par exemple, nous pouvons déduire de cet exemple d’histoire d’utilisateur que le gestionnaire de contenu a l’histoire suivante : « En tant que gestionnaire de contenu, je souhaite obtenir un rapport hebdomadaire sur l’analyse du contenu afin de pouvoir contrôler l’efficacité du rédacteur de contenu.

Nous avons choisi cet exemple de récit d’utilisateur d’Amazon parce qu’il nous donne un aperçu du type de récit attendu dans un environnement agile au sein d’une grande entreprise technologique multinationale. Ce qui est intéressant, c’est qu’il est très simple. Il n’y a pas de jargon technique et tout le monde, quelle que soit la discipline, peut le comprendre, ce qui est l’objectif des récits d’utilisateurs.

Dans cet exemple, l’utilisateur est inscrit chez eux et souhaite acheter un Kindle pour son ami. L’une des façons dont l’équipe pourrait répondre à cette histoire, en fonction de leur user persona, pourrait être d’inclure une section cadeau sur l’écran d’accueil. Elle pourrait dire quelque chose comme « Le cadeau d’anniversaire idéal ». D’autre part, elle pourrait choisir d’afficher un message indiquant à l’utilisateur qu’il peut envoyer instantanément des cadeaux lorsqu’il parcourt des articles tels que le Kindle. Une autre action qu’ils pourraient vouloir suivre est de s’assurer que le client peut ajouter de nouvelles adresses ou choisir sa liste d’adresses actuelle rapidement et facilement. Si vous utilisez Amazon, vous verrez que c’est effectivement le cas !

Dans cet exemple, nous avons une vue de ce à quoi ressemble la liste des histoires d’utilisateurs dans un backlog dans un environnement de développement de produits agile.

Comme nous pouvons le voir ici, les éléments du backlog sont regroupés par ordre de priorité et les tâches sont représentées par des user stories. Dans chaque histoire d’utilisateur, nous pouvons noter les différents points scrum attribués pour indiquer la quantité de travail nécessaire pour chaque fonctionnalité.

Nous aimons cet exemple d’histoire d’utilisateur simple de BBC Sport. Ce que nous aimons, c’est qu’il transmet beaucoup d’informations en quelques mots seulement, ce qui est exactement ce qu’une bonne histoire d’utilisateur est censée faire.

Dans cet exemple, la BBC envisageait d’ajouter un bouton de partage à ses articles sportifs, dans l’idée que les lecteurs puissent partager des informations sportives et obtenir l’avis de leurs amis. Cet exemple est complet, il transmet beaucoup d’informations et sa logique est simple. Elle justifie définitivement le besoin d’un bouton de partage et indique que quelqu’un a fait pas mal de recherches sur sa base d’utilisateurs avant de rédiger cette histoire d’utilisateur.

Cet exemple d’histoire d’utilisateur d’Easy Agile est un peu différent. Tout d’abord, nous avons remarqué qu’il est remarquablement facile à lire. Pour commencer, chaque ligne alterne entre couleur et blanc, afin de séparer facilement les concepts et de faciliter le balayage. Les sections gauche et droite de la carte, c’est-à-dire les instructions et la formule de la phrase, sont codées en vert et en bleu.

Ensuite, les instructions à gauche de cet exemple d’histoire d’utilisateur servent de guide utile pour les catégories « Qui », « Quoi » et « Pourquoi ». Elles nous aident à envisager l’histoire sous l’angle de l’entreprise, en posant les questions suivantes : « Pour qui construisons-nous ? », « Qui est l’utilisateur ? » et « Quelle est l’intention ? » Si cet exemple devait être reproduit, il serait incroyablement utile et servirait d’incitation à commencer à rédiger des histoires d’utilisateurs.

Voici quelques exemples d’histoires d’utilisateurs provenant d’un site web de voyage. Nous avons droit à quatre histoires différentes qui nous donnent un aperçu des diverses fonctionnalités qu’ils pourraient développer pour aider leurs user persona à atteindre leurs objectifs. Cependant, nous constatons que trois des quatre histoires sont incorrectes. Enfin, pas vraiment incorrectes, mais plutôt incomplètes. Pourquoi ? Parce que les histoires d’utilisateurs doivent toujours indiquer la raison pour laquelle ils veulent accomplir une action.

La fonctionnalité doit toujours apporter un avantage à l’utilisateur. Cela permet à votre équipe de donner la priorité aux fonctionnalités spécifiques qui apporteront une réelle valeur ajoutée à vos utilisateurs. Des utilisateurs satisfaits sont synonymes d’un produit performant et d’une entreprise prospère. Le premier exemple concerne les réservations d’hôtel. Une version plus complète pourrait être la suivante : « En tant qu’utilisateur, je veux réserver une chambre d’hôtel : En tant qu’utilisateur, je souhaite réserver une chambre d’hôtel à proximité du centre-ville, afin de ne pas avoir à voyager loin tous les jours. Il est peu probable que l’utilisateur n’ait pas à l’esprit un emplacement spécifique pour l’hôtel, qu’il s’en rende compte ou non. L’ajout de la partie « pourquoi » vous aide à trouver des solutions plus créatives susceptibles d’aider l’utilisateur, par exemple en lui indiquant des hôtels plus proches du centre-ville ou de l’aéroport, en fonction de son budget. Cela peut éviter à l’utilisateur de quitter la page et de rechercher les adresses des hôtels sur Google Maps et de vérifier les distances. Sinon, il pourrait tout aussi bien s’agir de n’importe quel autre site de voyage qui n’offre pas de fonction distinctement utile à l’utilisateur. Le dernier exemple d’histoire d’utilisateur, en revanche, est complet et utile à l’équipe de design ; il montre exactement ce que l’utilisateur veut – pouvoir sauvegarder les réservations passées et éviter un effort supplémentaire de saisie de données. Il peut également aider à définir des critères d’acceptation plus précis et plus rigoureux.

Agile USA, avec son exemple d’histoire d’utilisateur de note autocollante pour un gestionnaire de compte, résume succinctement ce qui devrait être inclus dans ce type de livrable. C’est un exemple assez simple qui montre comment des informations vitales pour guider l’équipe de design et de développement peuvent facilement être résumées sur une simple note autocollante. Ce que nous apprécions dans ce type d’exemple, c’est qu’il n’est pas intimidant et qu’il est facilement compréhensible par n’importe qui.

Il vous permet de suivre une formule simple pour les rédiger, ce qui est nécessaire en matière de créativité, en particulier lorsque vous devez rédiger un article après l’autre sur les caractéristiques d’un produit le jour de la rédaction de l’article.

Nous avons décidé d’inclure cet exemple d’histoire d’utilisateur d’Alexander Cowan parce qu’il reflète clairement le degré de réflexion nécessaire à la création d’une histoire d’utilisateur, même la plus basique. La rédaction d’une histoire d’utilisateur ne consiste pas simplement à imaginer une situation hypothétique impliquant un utilisateur hypothétique. Elle doit au contraire s’appuyer sur des recherches réelles et des user persona. Cet exemple d’histoire d’utilisateur nous aide à tirer parti de ces informations en nous rappelant les raisons fondamentales pour lesquelles nous écrivons cette histoire.

Les invites de cet exemple sont très utiles pour vous aider à élaborer une histoire d’utilisateur qui reflète le user persona que vous et votre équipe aurez mis du temps à créer. Ce que nous apprécions également dans cet exemple d’user persona, c’est le fait que les invites vous aident à définir les critères d’acceptation en posant la question suivante : « Comment saurons-nous si cela fonctionne ?

Cette application de fitness consiste à aider les utilisateurs à rester motivés en suivant leurs entraînements quotidiens. L’histoire de l’utilisateur est simple : « En tant que passionné de fitness, je souhaite suivre mes entraînements quotidiens afin de surveiller mes progrès et de rester motivé. »

L’objectif est d’aider les amateurs de fitness à suivre leurs progrès et à rester motivés. L’application doit permettre aux utilisateurs d’enregistrer différents types d’exercices et leur fournir des résumés hebdomadaires et mensuels. De cette manière, les utilisateurs peuvent voir où ils en sont et rester motivés.

En outre, il devrait envoyer des notifications pour rappeler aux utilisateurs leur programme d’entraînement. Cette histoire d’utilisateur est claire, exploitable et se concentre sur le besoin de suivi et de motivation de l’utilisateur.

Imaginez un junior designer freelance qui cherche un environnement confortable pour travailler tout en savourant une tasse de café. L’histoire de l’utilisateur décrit : « En tant que designer junior indépendant, je veux boire un café dans une atmosphère confortable tout en travaillant, de sorte que je m’attends à une commande rapide, à un espace libre pour moi avec l’ordinateur portable et à la possibilité de charger l’appareil. »

Cet article met en évidence les besoins des travailleurs indépendants, en soulignant l’importance d’un espace de travail confortable avec un service rapide, un grand espace pour un ordinateur portable et l’accès à des installations de recharge. En se concentrant sur ces détails, le café peut créer une atmosphère accueillante qui attire les free-lances et les travailleurs à distance.

Cette histoire d’utilisateur est centrée sur une personne qui souhaite optimiser ses achats d’épicerie expérience. L’histoire de l’utilisateur est la suivante : « En tant que personne qui travaille dur, je veux faire mes courses sans perdre de temps afin de pouvoir passer plus de temps avec moi-même. »

Cette histoire met en évidence le besoin de l’utilisateur d’un processus d’achat efficace et rapide, en soulignant l’importance de gagner du temps et d’améliorer la commodité. Il s’agit d’offrir une expérience d’achat rationalisée qui permette à l’utilisateur de gérer efficacement ses tâches tout en profitant de plus de temps libre.

Le bon support pour votre récit de l’utilisateur et les bonnes informations à y inclure dépendront de votre organisation, de la taille et de l’échelle de votre projet et de la complexité des fonctionnalités que vous concevez. Quelle que soit la manière dont vous choisissez de transmettre votre histoire d’utilisateur, la chose la plus importante à garder à l’esprit est la recherche. Une fois que vous avez effectué des recherches adéquates sur les utilisateurs et défini les profils de vos user persona, vous êtes prêt à rédiger vos récits d’utilisateur. En suivant les bonnes pratiques énoncées dans cet article et en vous inspirant (ou même en téléchargeant) les exemples et les modèles présentés, vous devriez être sur la bonne voie pour rédiger une excellente histoire d’utilisateur.