User Stories : En tant que [Designer UX], je veux…

Examinons un outil si simple mais si puissant qu’une fois que vous l’avez appris, vous l’appliquerez à tous vos projets : les user stories. Il s’agit d’une excellente méthode de design qui améliore la collaboration entre toutes les parties prenantes.

Les besoins des utilisateurs sont au cœur de l’agile : les user stories

Il y a tellement d’articles sur l’UX et l’agile. Beaucoup d’entre eux se plaignent de la façon dont l’Agile est si peu convivial, comment ces deux approches ne peuvent pas fonctionner ensemble, etc. Oui, il est difficile de travailler sur des projets logiciels.

Oui, il est difficile de travailler en collaboration avec d’autres disciplines. Et, pendant que nous y sommes, nous pourrions dire « oui » à tant d’inconvénients, que nous ne les aborderons pas tous dans un seul article.

Aujourd’hui, nous nous concentrons sur cette méthode de design simple et rapide appelée « user stories » qui vous aidera à relever bon nombre de ces défis. Pourquoi ?

  • Un récit d’utilisateur est bref, spécifique et orienté vers un objectif. Il s’agit d’une déclaration d’une phrase qui a généralement la structure suivante : « En tant que , Je voudrais pour que ».
  • Les user stories sont des outils de design collaboratif. Toutes les parties prenantes du projet sont censées participer à la définition et au tri des user stories.
  • Les user stories concentrent le projet sur la perspective de ceux qui l’utiliseront.

Cela ne ressemble-t-il pas à une philosophie et à un processus de développement centrés sur l’utilisateur en son cœur ? Pourtant, c’est un outil issu du développement Agile. Alors, pourquoi ne pas les embrasser tous les deux ?

Les user stories sont – évidemment – centrés sur l’utilisateur

Author/Copyright holder: CannedTuna. Copyright terms and licence: CC BY-NC-ND 2.0.

Bien sûr, il y a des équipes qui ne font aucune recherche sur les utilisateurs et qui ne créent pas des user stories à partir de ce qu’ils pensent. Bien que ce ne soit pas la meilleure option, c’est beaucoup, beaucoup mieux que de penser à « moi ». Un peu d’imagination peut faire des merveilles en gardant à l’esprit que les utilisateurs ne sont pas nous. Juste pour souligner la pertinence de cette façon de penser, parmi toutes les parties prenantes, vous pouvez expliquer un petit scénario comme celui qui suit.

« Par exemple, si vous deviez concevoir un site Web qui s’adresse aux musiciens qui pourraient sélectionner des styles et des effets pour les aider à composer des chansons, vous devriez penser à de nombreux types de musiciens. Le client a demandé un menu avec différents effets. Une chanson vous vient à l’esprit, à partir du CD de votre autoradio. Vite, lâchez cette pensée, parce que vous pensez « moi », là. Pensez plutôt ceci :

  • « Moi » pourrait être n’importe quel musicien spécialisé dans un ou plusieurs instruments. Si vous pensiez que « moi » était un guitariste de heavy-rock, revenez en arrière et considérez les claviéristes, chanteurs, bassistes et batteurs… ou, peut-être qu’un compositeur classique rédige un opéra et veut vérifier quelques idées pour la partition.
  • « Moi » est également un auteur-compositeur de tout genre. Cela pourrait être easy listening, électronique ou, oui, beau rock lourd. Ou, ce pourrait être un classique qui a été chargé d’écrire la bande originale d’un film que vous ne verrez pas avant un an.

Génial ! Maintenant que nous avons réussi à amener l’équipe à penser « large » pour convenir à nos utilisateurs, nous sommes en mesure de créer un récit d’utilisateur.

Pensez aux autres, à l’utilisateur en particulier

Le format d’un récit d’utilisateur nous oblige à penser aux autres et à les garder ainsi que leurs besoins au point, à travailler un peu sur notre empathie et à nous mettre à la place des utilisateurs. Peut-être, parfois, nous ne le faisons pas sur la base de données réelles, mais c’est un début. Peut-être que grâce à ce petit exercice d’empathie, la direction et les membres de l’équipe pourraient comprendre la nécessité de sortir et de découvrir les utilisateurs cibles !

Idéalement, en tant que chercheur utilisateur, vous devriez prendre l’initiative sur la définition des user stories. Vous pouvez apporter vos personas (utilisateurs fictifs que nous créons) et vos scénarios utilisateur à la session des user stories et créer le cadre approprié pour toutes les parties prenantes. S’il n’y a pas eu de phase de recherche d’utilisateurs, assurez-vous simplement de rassembler autant d’informations que possible sur le projet. Cela peut provenir de journaux ou d’analyses, du support client, de la recherche sur ordinateur, de l’analyse concurrentielle, etc. Dans notre scénario de site Web musical interactif, nous avons de la chance que notre client nous ait dit qu’il s’occupe principalement de claviéristes qui composent des instrumentaux pour la musique accessoire dans les programmes télévisés.

En tant que designer d’expérience utilisateur, vous êtes la « voix » de l’utilisateur pendant le développement du projet. Essayez de vous entourer avec autant plus de leur réalité que possible et traduisez cette « voix de l’utilisateur » dans les récits d’utilisateur afin que tout le monde l’ait à l’esprit.

Les user stories sont simples et accessibles

Si vous êtes de la « vieille école », vous vous souvenez peut-être encore de cas d’utilisation. Peut-être que les user stories vous les rappellent. Eh bien, bien qu’il existe des similitudes, les différences améliorent beaucoup les user stories.

Les cas d’utilisation ont une grammaire et une structure spécifiques. Par conséquent, tout le monde ne participe pas à leur définition. Seule l’équipe ou la personne chargée de définir les exigences ou les spécifications fonctionnelles les rédigerait. Les cas d’utilisation sont un pont entre le client et, parfois, l’utilisateur et l’équipe de développement. Ainsi, en facilitant le modèle du « balançoire de pneu », on voit juste ce qui peut arriver…

Author/Copyright holder: Unknown. Copyright terms and licence: Unknown.

Quelque chose a horriblement mal tourné dans la traduction dans ce modèle ! D’un autre côté, les user stories, avec leur simplicité et leur concentration, sont un moyen parfait d’éviter ce type de situation. Toute personne impliquée dans l’équipe peut les essayer. Il / elle a juste besoin de comprendre la pertinence de la grammaire spécifique :

  • En tant qu’un . Le rôle se réfère à celui qui fait l’action et qui en profite.
  • Je voudrais . C’est l’action exécutée.
  • Afin que . C’est la valeur ajoutée que l’utilisateur obtient de l’action.

Avec cette brève déclaration, les user stories font une très courte courbe d’apprentissage ! Si vous venez d’une approche de design participative, vous pouvez également impliquer les utilisateurs dans la rédaction des user stories.

Les user stories sont collaboratifs

Comme nous l’avons dit précédemment, votre objectif en tant que designer d’expérience utilisateur est de promouvoir une vision concrète, réaliste et partagée de l’utilisateur final. Les user stories sont votre meilleur allié. Grâce à leur accessibilité et à leur flexibilité, vous pouvez les utiliser pour construire un langage commun et un modèle mental commun de l’objet du projet. Ainsi, vous pouvez avoir toutes les parties prenantes – client, management, membres de l’équipe – parlant le même langage et se concentrant sur l’utilisateur et ce que le projet essaie d’accomplir.

Les user stories favorisent un changement dans la façon dont un projet est discuté.

  • Nous ne nous concentrons plus sur les solutions et fonctionnalités.
  • Nous nous concentrons sur des objectifs que les « vrais » utilisateurs pourront atteindre dans un but précis.
  • Nous n’avons pas de liste de fonctionnalités abstraites dont l’origine est douteuse.
  • Nous concentrons les objectifs finaux sur des choses concrètes et tangibles que le projet permettra à l’utilisateur d’accomplir.

Les récits d’utilisateur concernent le présent et l’avenir

Les user stories sont généralement écrites sur des Post-its. Au début, le nombre de Post-its peut être écrasant, mais il est beaucoup plus facile à gérer que les documents d’exigences sans fin !

Un récit d’utilisateur a juste le bon niveau de détail. À un niveau plus abstrait, nous avons des épopées. Dans l’Agile, les « épopées » sont utilisées pour un aperçu de haut niveau des fonctionnalités nécessaires. Par conséquent, ils rassemblent un groupe de user stories. Si vous créez un diagramme d’affinité, les épopées seront le nom donné à un ensemble de user stories courants. Les épopées permettent à tout le monde à bord du projet de voir le design du point de vue de nombreux utilisateurs, de manière suffisamment exhaustive pour que des anomalies puissent apparaître, si un utilisateur veut « essayer » quelque chose qui n’avait pas été prévu ou planifié suffisamment.

Les user stories doivent être suffisamment spécifiques pour que l’équipe de projet puisse les sélectionner et travailler dessus pendant un sprint. Avant cela, l’équipe doit explorer les détails et résoudre les problèmes d’utilisation dès le départ. En tant que designer d’interface utilisateur, vous devez faire partie de l’équipe de projet et travailler avec les développeurs pour rendre le récit d’utilisateur réel et utilisable.

Le langage clair des user stories aide tout le monde à comprendre ce qui se construit à chaque sprint, et toutes les parties prenantes peuvent vérifier comment leurs préoccupations et leurs besoins sont pris en compte. Ainsi, les user stories sont parfaits pour préparer le terrain et définir la portée du projet. Ils sont également idéaux pour définir les étapes suivantes. Parce qu’ils sont au niveau de granularité parfait (c’est-à-dire au niveau de détail parfait), il est très clair lorsque le projet souffre d’un fluage de fonctionnalités, par exemple.

Ce qu’il faut retenir

Les user stories sont nés dans le cadre des méthodologies de développement Agile et SCRUM. En tant que designers d’expérience utilisateur, nous devons les adopter et utiliser cette méthode simple pour nos propres « avantages »; c’est-à-dire pour l’utilisateur !

Les user stories nous offrent à nous designers tout ce dont nous avons besoin pour créer une vue réaliste, concrète et partagée de l’utilisateur :

  • Les user stories sont basés sur les objectifs des utilisateurs ; ainsi, ils gardent les produits axés sur l’utilisateur.
  • Les user stories sont accessibles et gérables ; ainsi, ils facilitent la collaboration entre les parties prenantes et les membres de l’équipe.
  • Les récits d’utilisateur aident à créer un « modèle mental de projet » dès le début et au-delà.
  • Avec une structure très simple et concrète, les user stories aident le projet à rester concentré sur de nombreux comptes : centré sur l’utilisateur, axé sur les objectifs et ce qu’il est possible de mettre en œuvre à chaque étape et ce qui devrait être laissé après.

L’Agile est une aide précieuse dans le design centré sur l’utilisateur, notamment parce qu’il nous offre une piste plus rapide pour rechercher et planifier, en particulier en ce que nous pouvons structurer et affiner les épopées pour aider à trouver toutes les dimensions possibles d’un projet. Les user stories ou récits d’utilisateurs nous permettent de bien saisir l’aspect le plus important de l’expérience utilisateur, les utilisateurs et leurs besoins.

Ressources