web-dev-qa-db-fra.com

Quelle est la meilleure façon d'écrire des scénarios utilisateur pour que les développeurs suppriment l'ambiguïté?

Dans l'entreprise pour laquelle je travaille, j'ai implémenté le format suivant parce que la plupart du temps, les scénarios utilisateur étaient tout simplement trop ambigus et les développeurs avaient souvent besoin de contacter l'équipe produit pour clarifier comment les choses devraient fonctionner ou pire encore, ils décider eux-mêmes comment cela devrait fonctionner.

ser Story

En tant que utilisateur de l'archive
je veux pouvoir envoyer un e-mail archivé à ma boîte aux lettres personnelle
pour que Je peux prendre des mesures sur un e-mail qui pourrait ne plus exister dans ma boîte aux lettres personnelle

Exemple de scénario

  1. L'utilisateur clique sur avant (ancre 1) dans panneau de résultats de recherche 1
  2. Le système renvoie Confirmation Modal 1 contenant Formulaire 2
  3. L'utilisateur remplit Formulaire 2 avec sa propre adresse e-mail et clique "Envoyer" (bouton Soumettre 2)
  4. Le système renvoie Success Modal 1 qui disparaît (Voir animation 1)
  5. Le système renvoie Page de recherche d'archives contenant Boîte de réception des résultats de recherche avec Panneau de résultats de recherche 1

Chacun de ces scénarios est accompagné de procédures pas à pas d'Invision, d'animations, etc.

Ensuite, tous les éléments détaillés ci-dessus sont référencés dans les catégories ci-dessous accompagnés d'images statiques individuelles décrivant les mesures et les informations de spécification pour tout nouvel élément HTML.

Les catégories sont les suivantes:

  • Pages
  • Panneaux
  • Les tables
  • Formes
  • Modals
  • Alertes

Ma question est la suivante: est-ce la meilleure façon de procéder ou quelqu'un peut-il recommander une meilleure façon de fournir de la documentation aux développeurs?

scenarios
3
David Saunders

Les User Stories doivent être écrites comme ça - elles sont courtes et très concentrées sur l'essence de la fonctionnalité. Je préfère l'approche de Jeff Patton dans son livre User Story Mapping.

Cependant, les praticiens Agiles ont tendance à ne pas aimer la documentation, mais il y a tellement de détails dans une interface utilisateur et l'interaction entre l'utilisateur et l'interface utilisateur, parfois un certain niveau de `` documentation '' peut toujours être utile.

Les outils de conception tels qu'Axure ou Balsamiq, etc. peuvent désormais démontrer rapidement un comportement interactif, ce qui peut réduire la quantité d'explications à fournir sous d'autres formes. Axure vous permet de produire des organigrammes et d'ajouter des notes aux éléments de l'interface utilisateur, et il peut également générer de la documentation à partir de votre conception si vous en avez vraiment besoin.

En fin de compte, ce n'est rien de plus qu'un problème de communication, par exemple comment communiquer vos intentions de conception, et cela variera d'une entreprise à l'autre.

Idéalement, vous serez colocalisé avec les développeurs, il devrait donc être assez facile de choisir la bonne façon de travailler en étroite collaboration avec votre équipe de développement.

Souvenez-vous également que le design n'est pas quelque chose que vous faites vous-même - c'est une collaboration entre vous et les développeurs.

1
SteveD

Avez-vous pensé à utiliser le langage BDD (Given, When, Then ... et ses variantes Cucumber et Gherkin) pour spécifier vos scénarios?

Scenario: Eric wants to withdraw money from his bank account at an ATM

Given Eric has a valid Credit or Debit card
And his account balance is $100
When he inserts his card
And withdraws $45
Then the ATM should return $45
And his account balance is $55

Cela est parfaitement compatible avec les cadres de test automatisés si votre équipe est également intéressée par cela.

https://en.wikipedia.org/wiki/Behavior-driven_developmenthttps://en.wikipedia.org/wiki/Cucumber_ (logiciel)

1
kerr

Je voudrais souligner un aspect qui a été mentionné à plusieurs reprises - Le design est une tâche de communication. C'est d'abord la communication avec les utilisateurs, puis la communication avec les développeurs (et entre les deux, c'est la communication avec le chef de projet :-).

Ce que je veux dire par là, c'est qu'aucune forme de documentation ne supprimera toute ambiguïté. Les concepteurs doivent parler aux développeurs non seulement de la conception, mais aussi de leurs intentions. Idéalement, les développeurs participent déjà à la recherche d'utilisateurs.

Votre phrase "les développeurs devraient souvent entrer en contact avec l'équipe produit pour clarifier" sonne un peu comme si c'était la tâche du développeur de découvrir ce que les concepteurs voulaient. Ce n'est pas une méthodologie centrée sur l'utilisateur, bien au contraire. À mon avis, le concepteur ne devrait pas seulement penser aux utilisateurs du produit lors de la création de la conception, mais aussi aux utilisateurs des spécifications de conception (c'est-à-dire les développeurs) lors de la communication de la conception.

Je trouve intéressant que les concepteurs appliquent parfois des méthodes centrées sur l'utilisateur uniquement pour la conception du produit. Pourquoi ne pas utiliser le même état d'esprit lors de la communication interne? Rendez votre conception aussi accessible que possible pour les développeurs, et vous obtiendrez plus d'utilisation (c'est la même chose que de garantir que toutes les fonctionnalités du produit sont accessibles à l'utilisateur).

Pour en revenir à votre question, je pense qu'il n'y a aucun moyen de parler régulièrement (appelez-le itératif) à vos développeurs - de la recherche d'utilisateurs au lancement du produit.

0
virtualnobi