Comment écrire votre histoire d'utilisateur parfaite

1. Intro: Bonjour, là. Je m'appelle Adam. Je suis chef de produit et j'aimerais vous parler de la façon de rédiger votre histoire utilisateur parfaite. Oui, c'est vrai. Votre style, votre personnalité, votre passion et votre engagement, votre équipe, vos parties prenantes, votre produit et votre histoire utilisateur. Parce qu'il n'existe pas de modèle universel qui le rend parfait et qui s'applique à tous les niveaux. Si vous pensez avoir atteint la perfection dans la rédaction de vos histoires d'utilisateurs, vous pourriez avoir une surprise lorsque vous changez d'équipe pour des projets. À chaque interaction avec chaque nouvelle fonctionnalité, votre approche va légèrement changer et c'est normal. est vous qui devez vous adapter pour que l'histoire soit correcte, atteigne l' aspect souhaité en termes de clarté, de granularité et d'attrait. Donc, le niveau de compréhension de chacun. La même histoire d'utilisateur que vous écrivez doit parler la langue de l'équipe de développement qui est techniquement avertie, mais elle doit également parler la langue des propriétaires d'entreprise qui peuvent ou peuvent ne pas avoir de connaissances techniques. Ma définition d'une histoire d'utilisateur parfaite repose sur la déclaration suivante. Si vous prenez un étranger pour modéliser la rue et lui montrer l' histoire de l'utilisateur que vous avez écrite. Ils ne devraient pas être en mesure de le comprendre. Il devrait être assez facile pour quiconque de se pencher sur l'exigence, le contexte et les fonctionnalités qui résulteront de la mise en œuvre de cette histoire utilisateur particulière. Donc ce que nous allons parler de ses directives, conseils, de ses conseils et astuces, et de tout ce que vous devez savoir pour pouvoir écrire votre histoire d'utilisateur parfaite quelle que soit l'équipe, le projet ou l' industrie d'ailleurs. 2. Comment écrire votre histoire utilisateur parfaite: Bonjour, là. Je m'appelle Adam. Je suis chef de produit et j'aimerais vous parler de la façon de rédiger votre histoire utilisateur parfaite. Oui, c'est vrai. Votre style, votre personnalité, votre passion et votre engagement, votre équipe, vos parties prenantes, votre produit et votre histoire utilisateur. Parce qu'il n'existe pas de modèle universel qui le rend parfait et qui s'applique à tous les niveaux. Si vous pensez avoir atteint la perfection dans la rédaction de vos histoires d'utilisateurs, vous pourriez avoir une surprise lorsque vous changez d'équipe pour des projets. À chaque interaction avec chaque nouvelle fonctionnalité, votre approche va légèrement changer et c'est normal. est vous qui devez vous adapter pour que l'histoire soit correcte, atteigne l' aspect souhaité en termes de clarté, de granularité et d'attrait. Donc, le niveau de compréhension de chacun. La même histoire d'utilisateur que vous écrivez doit parler la langue de l'équipe de développement qui est techniquement avertie, mais elle doit également parler la langue des propriétaires d'entreprise qui peuvent ou peuvent ne pas avoir de connaissances techniques. Ma définition d'une histoire d'utilisateur parfaite repose sur la déclaration suivante. Si vous prenez un étranger de modéliser la rue et lui montrer l' histoire de l'utilisateur que vous avez écrite. Ils ne devraient pas être en mesure de le comprendre. Il devrait être assez facile pour quiconque de se pencher sur l'exigence, le contexte et les fonctionnalités qui résulteront de la mise en œuvre de cette histoire utilisateur particulière. Donc ce que nous allons parler de ses directives, conseils, conseils et astuces, et tout ce que vous devez savoir pour pouvoir écrire votre histoire d'utilisateur parfaite, quel que soit le l'équipe, le projet ou l' industrie d'ailleurs. Mais tout d'abord, qu'est-ce qu'une histoire d'utilisateur ? Une histoire d'utilisateur est une représentation claire d'une exigence, qui illustre le point de vue de l'utilisateur et explique comment une fonctionnalité particulière apportera une valeur spécifique aux clients. Il est écrit sous la forme d'une histoire utilisant un format spécifique, mais en anglais clair. Et dans un langage tel que n'importe quel humain peut facilement lire et comprendre sans contextes antérieurs ni informations supplémentaires. Dans quelle mesure une histoire d'utilisateur est-elle granulaire ? Eh bien, vous avez un niveau de projet à un niveau important, au niveau des fonctionnalités, puis vous avez des histoires d'utilisateurs. Ils sont donc essentiellement l' expression la plus granulaire de l'exigence. Cependant, aussi granulaire que cela puisse être, l'histoire de l'utilisateur doit encore définir une fonctionnalité entièrement testable et livrable . Peu importe la taille. Pourquoi utilisons-nous des histoires d'utilisateurs ? Nous les utilisons pour traduire les besoins de l'entreprise en fonctionnalités axées sur l'utilisateur. Nous les utilisons pour créer une compréhension commune de ce que nous voulons construire, de sorte que nous finissons construire la bonne chose et comment elle sera construite. Pour que nous finissions par le construire, n'est-ce pas ? Nous les utilisons pour avoir une source unique de vérité et une façon plus standardisée de structurer et de communiquer avec l'équipe, mais également en dehors de l'équipe avec nos parties prenantes internes ou externes. Enfin, nous les utilisons pour établir des attentes et créer des habitudes. Quels sont les avantages d'une meilleure expérience utilisateur ? Une livraison plus rapide de la satisfaction des clients, une meilleure courbe d'apprentissage, décision plus rapide, moins de gaspillage. Construisez donc la bonne chose et construisez-la de la bonne façon. Sinon, des questions se poseront et non pas le bon gars et le mauvais genre. Cela se traduira bientôt par incertitude, un manque de confiance, questionnements et des repousses toutes les choses méchantes qui nuiront gravement votre relation avec l'équipe de développement. Sans oublier les retards, les heures tardives du vendredi soir à la fin du sprint, la multitude de bugs qui vont inévitablement se glisser dans le produit que vous êtes censé nourrir. Et enfin, mais non des moindres, résoudre à peine le besoin et Load pour connaître la satisfaction des clients. Investissez dans de bonnes histoires d'utilisateurs, car les histoires d'utilisateurs doivent être indépendantes afin qu' elles puissent être sans aucun type de dépendance négociable, car une histoire utilisateur n'est pas un contrat pour une fonctionnalité. Valable, ce qui signifie qu'il doit fournir de la valeur aux clients, estimable à un niveau raisonnable d'approximation, petite taille, de sorte qu'il s'intègre dans une itération, puis testable de sorte que les conditions de succès peuvent être testées. Parlons un peu de l' anatomie d'une histoire d'utilisateur. Vous pouvez avoir différents types d'histoires d'utilisateurs. Vous pouvez avoir des histoires d'utilisateurs régulières. Vous pouvez avoir des histoires d'utilisateurs techniques. Vous pouvez avoir des pointes, qui sont essentiellement. Récits d'utilisateurs d'investigation, etc. Qu'est-ce qui fait une bonne histoire d'utilisateur ? Eh bien, pour commencer, une histoire d'utilisateur a un titre. Le titre doit être concis, clair et intuitif. Pensez aux gros titres des journaux. C'est le titre de votre histoire utilisateur. Il est alors préférable de fournir un peu de contexte sur la raison pour laquelle nous voulons implémenter cette fonctionnalité ? Quelle valeur cela apporte à nos clients, et quel est le besoin, c'est l'âme. Le raisonnement derrière cela est que l'équipe de développement ne peut pas travailler isolément. Ils ne se contentent pas de s'asseoir dans une bulle en attendant que quelqu'un leur donne des histoires d'utilisateurs. Sans qu'ils comprennent le contexte complet et les implications. ils saisissent le contexte des exigences, plus ils seront capables de trouver une meilleure solution technique avec un retour d'information précieux pour l'entreprise, etc. Alors, comment exprimer ce contexte ? Eh bien, dans le cadre de l' anatomie d'une histoire d'utilisateur, vous commencez par un célèbre comme un, je veux. Donc, cette formule. Permettez-moi de vous donner un exemple. Si le titre de l'histoire de mon utilisateur est l'utilisateur peut effectuer une recherche sur le site Web, alors l'expression du contexte, serait-elle, par exemple, en tant qu'utilisateur du site Web, je souhaite pouvoir effectuer un effectuez une recherche sur le site Web afin trouver l'article que je recherche. Vous trouverez ensuite la section Critères d'acceptation. C'est ici que vous notez les exigences réelles, car le contexte n'est pas l'exigence. Il s'agit d'une description de haut niveau du raisonnement derrière cette exigence. Regardez que vous écrirez dans cette section, l'équipe de développement se transformera en réalité. Les développeurs vont écrire le code. Les testeurs vont ensuite tester la fonctionnalité. le propriétaire du produit ou les analystes métiers effectueront les tests d'acceptation des utilisateurs UAT en fonction de ces exigences spécifiques. quoi devraient donc ressembler les critères d'acceptation ? Eh bien, idéalement, vous le structueriez dans des scénarios. Par exemple, le scénario numéro un, le deuxième scénario, etc. Chacun d'entre eux a un titre et une composition spécifiques. Et c'est là que nous utilisons l'autre partie fameuse du corps d'une histoire d'utilisateur, la séquence donnée quand alors. La donnée est la condition préalable. Il décrit ce que vous devez déjà avoir en place. Au moment où vous arrivez à cette étape. Le moment où est le déclencheur. Il montre ce qui doit se passer. Afin de déterminer un comportement spécifique. C'est alors le comportement attendu. Il illustre ce qui devrait se produire à la suite d' un déclencheur spécifique. suivant notre exemple précédent, avec le client qui doit pouvoir effectuer une recherche sur le site Web. Notre premier scénario et les critères d'acceptation sonneraient ainsi. Scénario numéro un, le titre serait l'option Rechercher est disponible pour l'utilisateur. Ensuite, nous avons la séquence donnée quand alors. Voyons donc. Étant donné que l'utilisateur a accès au site Web, lorsque la page du produit du site Web est affichée, le module de recherche est disponible dans le coin supérieur droit de l'écran. Alors, qu'avons-nous fait ici ? abord, nous avons décrit la condition préalable étant donné que l'utilisateur a déjà accès au site Web. Pourquoi ? Parce que si l'utilisateur n' accède pas au site Web, il n'y a pas de fonctionnalité à parler. Ensuite, nous spécifions le déclencheur lorsque la page du produit du site Web est cette plaque. Pourquoi ? Parce que l' équipe de développement doit savoir quand cette fonctionnalité nouvellement implémentée doit être disponible pour les utilisateurs. Voulons-nous utiliser la fonctionnalité de recherche sur toutes les pages du site Web ? Non. Nous voulons qu'il soit disponible uniquement lorsque nous accédons à la page des produits. Alors, quand est le déclencheur ? Tu te souviens de ça ? Ce n'est qu'après que nous avons demandé le comportement attendu. Le module de recherche est ensuite disponible dans le coin supérieur droit de l'écran. Pourquoi ? Parce que nous devons illustrer ce qui devrait se passer. Si j'accède au site Web et que j'ai atterri sur la page des produits. Le comportement attendu dans notre cas est que maintenant je peux voir la zone de recherche. OK ? Nous pouvons donc voir la zone de recherche sur cette page. Mais comment faire en sorte que cela fonctionne ? Eh bien, c'est assez facile. Nous pouvons rédiger un autre scénario cadre des critères d'acceptation. Nous allons maintenant avoir le scénario numéro deux avec le titre suivant. L'utilisateur peut rechercher un produit spécifique par nom, suivant la formule magique donnée. Voici ce que nous avons. N'oubliez pas. À ce stade, nous ne pouvons voir que la zone de recherche. Il ne fait encore rien. Alors, c'est parti. Étant donné que l' utilisateur a soumis des critères de recherche spécifiques à l'aide de la zone de saisie de recherche. Lorsque l'utilisateur clique sur l'appel à l'action du CTA de recherche. Le filtrage est ensuite effectué selon les critères spécifiés. La liste des résultats de recherche s'affiche et contient tous les produits correspondant aux critères de recherche. Une remarque importante ici, vous pouvez avoir plusieurs conditions préalables . Et vous pouvez les exprimer en utilisant end. Par exemple, étant donné que l'utilisateur a soumis des critères de recherche spécifiques à l'aide la zone de saisie de recherche et que la zone de saisie de recherche contient des caractères valides. Vous pouvez également avoir plusieurs comportements que prévu, comme dans notre exemple précédent. Le filtrage est ensuite effectué selon les critères spécifiés. La liste des résultats de recherche s' affiche et contient tous les produits correspondant aux critères de recherche. Mais il ne peut y en avoir qu' un seul lorsque le déclencheur doit être une expression singulière, un seul événement. outre, en termes de scénarios, nous devons faire attention à préciser tous les cas possibles. Scénarios de cas satisfaisants, cas d' échec et scénarios de cas Edge. Et pour le faire correctement, nous devons marcher un kilomètre à la place du client et toujours remettre en question chaque action et chaque décision. C'est le seul moyen de maximiser nos chances découvrir tous les cas d'utilisation possibles. Alors, tu y vas. Beaucoup de choses doivent être prises en compte lors de la rédaction d'histoires d'utilisateurs. Et c'est un processus qui ne doit pas être pris pour acquis. Rédiger des histoires d'utilisateurs appropriées. Une fois que l' équipe de développement peut facilement comprendre et mettre en œuvre ceux qui sont clairs, concis et avec la bonne quantité et informations de qualité, est un processus complet qui peut faire de votre la vie est plus facile ou peut causer des cauchemars et beaucoup de problèmes. Quelques trucs et astuces à prendre en compte. Commencez gros et décomposez-les au besoin. Les histoires d'usages sont destinées à être raffinées. Ne vous concentrez pas sur tout cela en même temps. Pensez aux flux utilisateur, puis créez des tranches verticales pour les prendre en charge. Ça veut dire, utiliser Story Mapping, non ? Et examinez-les en équipe. Parce que cela crée une compréhension partagée. Ce n'est pas un seul homme. Montrez-le comme une entreprise collaborative. Concentrez-vous sur les besoins sous-jacents du client, non sur les perceptions et les états. Ne transpirez pas le format. Il existe de nombreuses façons valables de rédiger une histoire utilisateur. Il suffit de déterminer ce qui fonctionne le mieux pour l'équipe, puis d'être cohérent. Les histoires d'utilisateurs sont les structures qui démarrent et capturent la conversation autour d'une fonctionnalité basée sur la valeur centrée sur vos utilisateurs. Et n'oubliez pas que vous n' êtes pas votre utilisateur. Enfin, investissez dans vos histoires. Et surtout, demandez qui, quoi et pourquoi. Utilisez toutes ces informations comme votre Northstar. Même si vous ne serez probablement pas en mesure de créer des utilisations parfaites à atteindre et à chaque fois. Mais la pratique est parfaite. Continuez donc le bon travail. Nous avons reconnu l' importance de rédiger des histoires d'utilisateurs appropriées et faciliter la vie dans votre travail plus agréable.