Comment communiquez-vous la gravité des bogues de conception? Avez-vous des moyens normalisés de le faire?
Lors de la résolution et du tri des bogues liés à l'utilisabilité, je constate fréquemment que je dois recourir à la création d'une émission ou à la description détaillée et dramatique de la douleur de l'utilisateur autour d'un problème. Bien que je sois sûr que je devrai toujours faire une partie de cela, j'aimerais qu'il y ait une façon plus standardisée de communiquer la gravité/la sensation d'un problème. J'ai lu sur les gens de Mozilla qui marquent les bogues avec lesquels ils heurtent les heuristiques, ce qui, je pense, est une excellente idée, mais cela n'aide pas vraiment avec la gravité. Quelqu'un a-t-il de bonnes idées ou processus?
Un exemple pourrait être, un bug peut se sentir pour un concepteur, oh mon dieu, nous ne devrions jamais le publier dans cet état, mais pour un développeur qui l'a programmé, le comportement peut sembler évident, donc il ne semble pas très grave du tout.
User Focus a un bon article sur le sujet prioriser les problèmes d'utilisabilité .
Je suis d'accord avec le sentiment du message d'ouverture. Si vous travaillez dans un environnement d'ingénierie ou avec un grand système complexe, il est essentiel d'avoir une méthodologie et un processus de reporting cohérents et compréhensibles. Une partie de la raison pour laquelle il est important est d'être prise au sérieux, et l'autre partie est de pratiquer une bonne communication et de s'intégrer de manière significative avec les autres équipes et processus avec lesquels vous travaillez.
Pour vraiment ramener à la maison que quelque chose est vraiment vraiment vraiment un problème et est une énorme douleur pour les utilisateurs, puis compléter vos rapports avec des clips vidéo de l'interaction peut faire des merveilles pour changer d'opinion.
Après avoir lutté avec ce problème pendant quelques années et avoir fini par créer un produit avec une facilité d'utilisation relativement faible, j'ai résolu ce problème d'une manière différente.
Il y a deux sources (au moins là où je travaille) au problème: 1) "The Business" ne planifiera/ne priorisera jamais les problèmes d'utilisabilité car a) ils préfèrent avoir de nouvelles fonctionnalités/corrections de bugs et b) ils n'ont aucun moyen réel de concevoir ou quantifier le coût d'une mauvaise utilisation (ce sont des experts du domaine après tout, pas des experts en logiciels).
2) Les développeurs (traditionnels) ne planifieront/hiérarchiseront jamais les problèmes d'utilisabilité car ils a) ne peuvent souvent pas voir l'étendue/le coût du problème et b) sont souvent moins confiants dans le développement frontal et c) leur concentration est constamment volée par des problèmes qui sont plus au cœur du travail d'un développeur.
Par conséquent, l'utilisabilité en souffre.
En tant que tel, OMI, vous avez essentiellement besoin d'un canal de développement distinct pour gérer la convivialité. C'est à peu près la même chose que la dette technique (dont je préconiserais également qu'elle soit "résolue" de cette façon). Créez un nouveau canal de développement, que ce soit aussi petit que de dédier quelques points agiles par itération (ou quelques jours par version de deux semaines, peu importe) pour, dans un monde idéal, embaucher un ingénieur front-end avec sa propre priorité -liste. Ce nouveau canal de développement résout constamment et systématiquement les problèmes de convivialité, et les problèmes de convivialité ne sont plus priorisés par rapport aux problèmes de non-utilisation, mais plutôt les uns par rapport aux autres.
Maintenant, pour les deux publics de mon premier paragraphe, si vous partez et passez quelques jours à collecter des résumés de recherche, des résultats d'études de cas, des citations des gourous reconnus, etc., vous devriez être en mesure de construire un argument qui convaincra les gens . Mais qui a le temps de consacrer 4 heures de recherche et de développement d'arguments pour hiérarchiser suffisamment un travail d'une heure? Mais si vous obtenez un argument (citant quelques exemples de mauvaise utilisation dans votre application) non pas pour justifier la priorisation d'un seul problème, mais plutôt pour justifier un canal de développement séparé, le gain en vaut la peine.
Je suis un développeur C # .Net ordinaire, avec un intérêt croissant pour la convivialité. Ce que j'ai fait, c'est formuler un argument pour l'importance d'examiner les problèmes d'utilisabilité, je suis allé à mon directeur technique avec une proposition, et maintenant je consacre un pourcentage de mon temps aux problèmes d'utilisabilité. Mon équipe a perdu certaines ressources de développement de base (nous embauchions donc c'était un argument plus facile à faire de toute façon) mais maintenant, une certaine convivialité sera enfin examinée.
À long terme, je pense qu'une partie de mon nouveau travail consiste à éduquer les autres développeurs de manière à ne pas publier de fonctionnalités qui présentent une mauvaise convivialité. Amplifiez les effets, pour ainsi dire.
Bonne chance!
Les visuels, en particulier les démonstrations, sont ce que j'ai vu avoir le plus d'impact.
C'était dans un environnement Agile où l'équipe UX soumettait des histoires au backlog de produit et les faisait voter lors des réunions d'estimation.
Les visuels ont toujours fonctionné en termes de référencement de captures d'écran, mais le mieux était de montrer réellement le problème en action et de décrire pourquoi c'était un problème.
Si vous n'êtes pas dans un environnement Agile, vous devez toujours avoir des réunions de développement au cours desquelles des problèmes peuvent être soulevés - soyez prêt à montrer ce qui est cassé et à discuter pourquoi vous le considérez comme "cassé".
(BTW, pour ceux qui ne connaissent pas Agile, quand vous voulez que quelque chose travaille, vous l'écrivez et le soumettez à la grande liste de "ce sur quoi nous devons travailler." La liste est revue chaque semaine et discutée par le développement, UX, QA , gestion des produits et principales parties prenantes).
Les jauges standard viennent à l'esprit, éventuellement combinées avec un dégradé de couleurs allant du jaune à l'orange en passant par le rouge.
D'autres analogies pourraient être utilisées: icône d'une coccinelle, d'un pot à vaisselle, d'un verre à boire, d'une personne, à différents stades de "cassure". C'est-à-dire: un plâtre sur une partie, une fissure (ou un "sourire" plissé), un morceau cassé, ... complètement brisé/écrasé
Faites juste attention lorsque vous utilisez des analogies animal/humain pour que cela ne devienne pas trop graphique.
L'utilisabilité n'est pas de la programmation.
Il serait trompeur de créer un système aussi progressif.
Si vous pensez vraiment que quelque chose est si défectueux qu'il brise le système (comme un bouton manquant pour passer à l'étape suivante), corrigez-le.
Sinon, c'est juste un problème de convivialité et peu importe l'importance que nous, en tant que praticiens, pourrions les trouver, ils ne sont pas proches de quand le code ne fonctionne pas.
En programmation, quand pense ne fonctionne pas, ils ne travaillent pas période. Pour le faire fonctionner, vous devrez le réparer.
En termes de convivialité, vous pouvez vous en sortir avec bien plus avant la panne du système.