web-dev-qa-db-fra.com

Processus de conception UX - Différences entre les user stories / modèles de tâche / cas d'utilisation, etc.

Je suis vraiment confus avec les différences entre certains de ces processus de conception UX. Il semble y avoir tellement de méthodes qui me semblent très similaires (pour moi) et les descriptions de chaque processus semblent assez vagues.

Quelqu'un peut-il m'aider à comprendre les différences entre ces différents processus:

  • Histoires d'utilisateurs
  • Cas d'utilisation
  • Modèle de tâche
  • Flux utilisateur

Également à quel stade devraient-ils être achevés. Je pense que la confusion vient du jeu en regardant différents guides UX et chacun étant assez différent.

6
Suzi Larsen

Comme vous l'avez déjà mentionné, même si vous pouvez trouver des entrées Wiki, les frontières de ce qui est inclus et de ce qui ne l'est pas sont floues. J'ai réorganisé les articles en raison du contexte - c'est le consensus que j'utilise pour ma vie professionnelle quotidienne:

  • Cas d'utilisation: Un scénario d'utilisation de fonctionnalité ou d'une partie du site. Si vous prenez des cas d'utilisation pour un panier d'achat, ce serait: 1) Enregistrer les articles pour plus tard; 2) Créez une liste d'articles que je veux acheter; 3) Objets que j'aimerais envoyer à un ami | Cela aide à mieux comprendre ce qui doit être dans le concept. Les cas d'utilisation sont souvent placés dans le contexte de la valeur commerciale: un cas d'utilisation est-il pertinent en raison du coût d'investissement? Pour moi, c'est un démarreur et un outil de priorisation
  • ser Stories: Du point de vue d'un utilisateur, le processus est expliqué. Cela peut être utilisé pour créer des scénarios sous différents angles. Reprenant l'exemple du panier: "Moi en tant qu'utilisateur, je voudrais vérifier mes articles et les supprimer si je ne les aime plus." - une autre perspective pourrait être celle du fournisseur: "Moi en tant que fournisseur de produit, je ne veux pas que les articles du panier soient réservés à certains utilisateurs, car je ne peux pas justifier les coûts devant mon intervenant alors." En "mode histoire", cela peut apporter différentes perspectives à un paysage.
  • Flux utilisateur: Si vous en savez un peu sur UML - c'est tout. Un flux utilisateur est une description des différents états qu'un utilisateur peut avoir dans la fonction observée. L'exemple à nouveau: un utilisateur peut entrer le panier à partir du catalogue, de la page de détail du produit et d'un rappel de newsletter. Dans le panier, il peut changer la quantité et la couleur des produits. Les sorties du panier sont les suivantes: navigation principale, paiement, etc. Vous pourriez découvrir que l'utilisateur, provenant de la newsletter, n'a pas toutes les informations dans le panier pour réussir le contrôle, alors qu'une entrée de page de produit l'a.
  • Modèle de tâche: Dans ma vie professionnelle, cela ne s'est pas produit autant sur mon chemin, car imo c'est très similaire aux flux d'utilisateurs. Il se concentre sur les tâches, donc les actions - tandis que le flux utilisateur prend également en charge les ÉTATS et les fonctionnalités de page que l'utilisateur peut avoir et utiliser.

Encore une fois, je ne pense pas que ce soit la définition scientifique. Les "cas d'utilisation" et "user story" sont de toute façon souvent mal utilisés par les parties prenantes qui souhaitent exprimer LEURS besoins et essayer de les projeter sur le client. Il en va de même pour les concepteurs qui souhaitent justifier leur conception en invoquant des cas d'utilisation.

7
Jan