Prioriser les problèmes de convivialité
Il existe une variété de références et d'approches pour hiérarchiser les problèmes d'utilisabilité, mais je n'ai identifié aucune approche unique qui capture tous les facteurs que je pense qu'il est nécessaire d'inclure dans l'évaluation de la gravité.
Selon Jakob Nielsen, une cote de gravité devrait être déterminée en tenant compte des éléments suivants:
- Fréquence - Est-ce courant ou rare? Cela se produit-il sur une route rouge?
- Impact - Sera-t-il facile ou difficile à surmonter pour les utilisateurs?
- Persistance - Problème ponctuel qu'un utilisateur peut surmonter une fois qu'il en a connaissance ou les utilisateurs seront-ils gênés à plusieurs reprises par le problème?
D'autres sources abordent la gravité en mesurant les trois facteurs définis par la définition ISO de l'utilisabilité, notamment:
- Efficacité - Les utilisateurs peuvent-ils encore accomplir des tâches, des objectifs? Peuvent-ils faire ce qu'ils veulent faire? Les ressources consacrées à l'exactitude et à l'exhaustivité des objectifs atteints.
- Efficacité - Combien d'efforts sont ajoutés par problème? La précision et l'exhaustivité avec lesquelles les utilisations spécifiées peuvent atteindre les objectifs spécifiés.
- Satisfaction - Que pensent les utilisateurs de la facilité d'utilisation des produits? Le confort et l'acceptabilité du système.
De plus, aucun des facteurs de score de gravité énumérés ci-dessus ne tient compte de l'impact du problème sur l'entreprise, par exemple, impact direct sur les revenus, le capital marque, les bénéfices, la valeur perçue, etc.
Enfin, je n'ai vu aucun facteur inclure l'économie, c'est-à-dire combien d'efforts (coûts) cela prendra-t-il pour résoudre le problème. Résoudre un problème de gravité moyenne avec un effort marginal par rapport à un problème de serveur extrêmement coûteux peut être judicieux.
Je suis donc curieux, quelqu'un a-t-il mis en place un processus pour évaluer et hiérarchiser les problèmes d'utilisabilité qui incluent tous les facteurs ci-dessus (ou peut-être ceux auxquels je ne pense pas) et si oui, voudriez-vous partager votre histoire?
Facteurs à inclure;
- La fréquence
- Impact
- Persistance
- Efficacité
- Efficacité
- La satisfaction
- Bénéfice/revenu d'entreprise
- Capital marque
- Coût à réparer
Au sein de notre équipe, nous évaluons les facteurs basés sur les utilisateurs, réfléchissons à quelques solutions possibles, estimons le coût via un processus de développement Agile (réunions de revue et d'estimation techniques), puis présentons les solutions viables et leur coût aux décideurs.
Je sais que cela fera grincer des dents à certaines personnes, mais je pense qu'il est possible de sur-analyser ces choses. Je trouve que plus de granularité dans l'analyse ne signifie pas nécessairement une meilleure analyse. Étant donné que l'analyse elle-même coûte de l'argent, les rendements diminuent à un moment donné.
En général, je pense que c'est deux questions fondamentales par rapport à d'autres tickets/problèmes: à quel point cela affecte-t-il les utilisateurs et à quel point cela affectera-t-il la budgétisation (à la fois en temps et en argent)? Les détails de ce que vous utilisez exactement pour analyser chacun d'entre eux varie d'un projet à l'autre. (C'est probablement pourquoi vous obtenez tant d'opinions différentes à ce sujet.)
Je trouve parfois utile de placer des problèmes contre ces axes:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Ce qui conduit généralement à hiérarchiser les correctifs de haut en bas à bas à droite.