UX Management: Best Practice for Wireframe / Prototype Deliverable Evaluation
Du côté de la gestion de l'expérience utilisateur, comment évaluez-vous les wireframes/prototypes d'un concepteur d'expérience utilisateur en ce qui concerne la progression des compétences? Quels paramètres ou critères devraient être utilisés pour évaluer si quelqu'un stagne ou progresse?
Dans mon esprit, je pense que les critères pourraient être une évaluation périodique des éléments suivants -
- Faible nombre de révisions (bien que les révisions puissent dépendre des commentaires du gestionnaire et des exigences supplémentaires)
- Faible nombre d'erreurs ou d'exigences manquées
Quelles mesures sont considérées comme les meilleures pratiques dans l'industrie?
Cela n'a aucun sens de mesurer les progrès d'un concepteur UX dans la création de wireframes.
Les wireframes ne sont qu'un moyen de communiquer avec d'autres personnes et peuvent prendre de nombreuses formes, des croquis aux maquettes en passant par les wireframes "interactifs" produits avec des logiciels comme Axure. Leur objectif est de représenter les idées sous une forme qui peut être discutée avec les parties prenantes, les membres de l'équipe et les développeurs. Ne les utilisez pas comme spécification.
Ce que vous devez plutôt mesurer, c'est le produit. Si je crée des wireframes incroyables mais des logiciels terribles, je ne suis pas un très bon concepteur d'expérience utilisateur.
Une autre chose que vous pouvez mesurer est le processus. Comment le concepteur communique-t-il, prépare-t-il et progresse-t-il vers les livrables finaux? Si elle aspire à communiquer, ses filaires ne seront probablement pas très bons non plus. Corrigez la communication plutôt que de regarder à quel point ses filaires sont jolis.
La chose importante à comprendre à propos des wireframes et des prototypes est que ils sont censés échouer. La seule raison pour laquelle vous les faites est de sortir les choses de votre tête et sur papier/écran pour la communication et les tests. Si vous vous attendez à ce que vos concepteurs UX exécutent ces étapes dans le processus, vous ne comprenez pas très bien le processus de conception; sans le processus cyclique d'apprentissage des tests d'utilisabilité et d'amélioration en fonction de leurs résultats, il n'y a littéralement aucun moyen d'affiner le travail de conception initial. Le cas échéant, le nombre d'itérations doit être aussi élevé que possible parce qu'un bon concepteur recherchera des commentaires et révisera fréquemment, en particulier dans un cadre agile.
Si vos concepteurs UX sont censés produire des wireframes en tant que livrables, vous faites quelque chose de mal. Prenez du recul et discutez avec vos concepteurs UX pour déterminer quels devraient être les bons livrables et quelles mesures vous devriez utiliser pour les évaluer.
Comme d'habitude, la réponse de Rahul est pleine de bons conseils. Je n'ai pas, n'évalue pas et n'évaluerai jamais un concepteur UX (ou un concepteur graphique ou un programmeur) basé sur des mesures quantitatives de choses comme des révisions (ou des validations de code). Maintenant, si quelqu'un ne révise jamais son travail , c'est un problème, car ne répond pas aux exigences de la tâche assignée , évidemment.
Si vous mesurez ou évaluez la progression des compétences, je suppose que cela va de pair avec la collaboration avec l'employé dès le départ pour déterminer une ligne de base, certains objectifs et des voies spécifiques pour atteindre ces objectifs. Vous pouvez mesurer s'ils ont réussi à faire le travail que vous avez demandé et à satisfaire les parties prenantes du projet grâce à leur travail, mais pouvez-vous quantifier que le travail d'un concepteur est 17% meilleur que l'an dernier? Non, surtout lorsque le travail n'est qu'une partie du gâteau du projet.
Il y a un excellent article sur la gestion de projet SE: Mesurer la performance des membres de l'équipe qui aborde certains des avantages et des inconvénients de l'application de mesures dans ces situations précisément.
Je ne mesurerais pas les révisions, car c'est un fait bien connu en génie logiciel que les exigences changent et en plus, les produits sont améliorés progressivement jusqu'à (et après) la sortie.
Je mesurerais l'utilisabilité des fonctionnalités requises en utilisant des techniques comme celles mentionnées dans le livre Rocket Surgery Made Easy .