Existe-t-il un modèle généralement accepté pour les besoins des utilisateurs sur un projet de conception UX?
Dans l'un de mes projets, les enquêtes auprès des utilisateurs sont sur le point de se terminer et mes prochaines tâches consistent à créer les personnages et à générer le document des besoins des utilisateurs. Comme il s'agit de l'un de mes premiers projets UX, ma proposition a adopté une approche très concrète basée principalement sur Un guide de projet pour la conception UX . Ce livre mentionne les besoins des utilisateurs mais ne précise pas vraiment à quoi ils devraient ressembler.
Dans mon ancienne carrière dans le développement de logiciels, j'ai traité des exigences qui ont été formulées très formellement dans le style CMMI ("Le système doit ...") et avec des spécifications techniques fonctionnelles moins formelles de style wiki sur des projets agiles. Je me demande comment aborder les besoins des utilisateurs dans ce projet de refonte UX.
Ce client est un groupe informel, donc je ne veux pas les submerger d'informations au point de ne pas les lire.
Donc, plusieurs questions:
Quelles catégories d'informations dois-je préciser dans un document des exigences utilisateur UX? (Existe-t-il une refonte spécifique?)
Si les enquêtes auprès des utilisateurs demandent une fonctionnalité qui n'a pas été convenue dans la proposition, comment les exigences des utilisateurs devraient-elles y remédier?
Existe-t-il un modèle gratuit pour un document des exigences utilisateur UX en ligne?
Existe-t-il un livre expliquant comment répondre aux besoins des utilisateurs? (Je préférerais de loin un modèle en ligne; il est gratuit et je peux commencer le document plus tôt.)
Mike Cohn a publié dans son blog un bon article, arguant d'utiliser User Stories for Requirements . Parce que
- Les récits d'utilisateurs mettent l'accent sur la communication verbale [entre les développeurs et le client]
- Ils peuvent être utilisés facilement dans la planification de projet. [...] les cas d'utilisation, en revanche, sont généralement trop importants pour donner des estimations utiles.
- Les récits d'utilisateurs encouragent l'équipe à différer la collecte des détails.
- Et ils mettent l'accent sur les humains et leurs besoins et motivations au lieu du "système"
ne User Story est écrite dans ce format (Question 3):
En tant que - type d'utilisateur -, je veux - un objectif - pour que - une raison -.
Dans son article se trouvent deux exemples de cas d'utilisation "traditionnels". Le second décrit une exigence d'interface ou d'interaction. J'ai ainsi appris à rédiger des exigences conformes aux normes ISO. Il mentionne également la spécification IEEE 830 "Le système doit ..." mais montre ses inconvénients.
Ce type de réflexion renforce la conviction que le logiciel est complet lorsqu'il remplit une liste d'exigences, plutôt que lorsqu'il atteint les objectifs de l'utilisateur visé
À la fin de l'article, vous trouverez quelques références pour une lecture plus approfondie. (Question 4)
.
Je pense que vous aurez des exigences non fonctionnelles comme "il devrait être facile à utiliser" ou "l'interface devrait réagir rapidement".
- En tant qu'utilisateur, je souhaite que le site soit disponible 99,999% du temps lorsque j'essaie d'y accéder afin de ne pas être frustré et de trouver un autre site à utiliser.
- En tant que personne parlant une langue latine, je souhaiterais peut-être exécuter votre logiciel un jour.
Mike couvre ce sujet dans un article sur Exigence non fonctionnelle en tant que user stories . Je recommande également de lire les commentaires, car ils expliquent comment l'implémenter correctement dans les projets Agile.
Question 2: Je mettrais les besoins supplémentaires des utilisateurs (vos soi-disant fonctionnalités) dans un chapitre supplémentaire au format User Story. Donnez quelques indices, à quel point ils sont urgents s'ils sont disponibles. Peut-être que vous pouvez aider à la décision pour une re-priorisation de tous les User Stories par pourcentage d'utilisateurs demandés ou score de désir mesuré.