Comment puis-je indiquer de nouvelles fonctions dans le papier ou les wireframes cliquables?
Lors de la création d'une nouvelle fonction dans un système existant, les utilisateurs avec lesquels je teste mes nouveaux concepts sont familiers avec tout ce qui l'entoure. Donc, mes wireframes contiennent également de nombreux composants anciens (mais non fonctionnels).
Si ma nouvelle fonction nécessite la sélection d'un lien (!) Ou d'un élément déroulant spécifique existant pour démarrer l'action, comment "dire" à l'utilisateur de l'utiliser?
Les flèches et les bulles de dialogue distraient ou guident beaucoup. Seul l'affichage des éléments nécessaires à l'action détruit le "sentiment" d'utilisation du programme et rend l'abstraction difficile. Et pour des raisons documentaires, je ne veux pas avoir à informer chaque utilisateur.
J'ai besoin d'une sorte de solution intermédiaire, qui s'explique d'elle-même. Quelque chose indiquant de façon subliminale: "cliquez sur moi!".
Quelques suggestions:
- Placez un indicateur sur les nouveaux éléments de l'interface utilisateur. Cela pourrait être une petite étoile ou une étiquette disant "nouveau" qui se trouve au-dessus d'un coin de l'élément d'interface concerné, ou une lueur douce autour de l'élément. (Si vous devez cliquer sur trois éléments de l'interface utilisateur pour accéder à la nouvelle fonctionnalité, chacun d'eux pourrait afficher l'indicateur. Mais cela n'est pas nécessaire si les utilisateurs cibles visitent souvent cette partie de l'interface, de sorte que cela dépend vraiment de votre application. )
Bien qu'il soit plus facile d'ajouter cet indicateur au site pendant quelques semaines après l'ajout de la fonctionnalité, une meilleure expérience serait de le montrer aux utilisateurs qui n'ont pas encore remarqué la fonctionnalité. Les indicateurs peuvent disparaître une fois que l'utilisateur sait que la fonctionnalité existe.
Suivez les fonctionnalités qu'un utilisateur a vues et/ou utilisées. Si un utilisateur se connecte à votre application et qu'il existe de nouvelles fonctionnalités depuis sa dernière visite, vous pouvez afficher une notification "Nouvelles fonctionnalités". Cliquer sur cette notification pourrait donner un bref pointeur vers les nouvelles fonctionnalités (qui pourraient être extensibles si une explication détaillée est donnée). Une fois que la notification a été vue, ou ignorée, ou que la fonctionnalité a été utilisée, la notification ne sera plus affichée à l'utilisateur (jusqu'à ce que vous ayez une autre nouvelle fonctionnalité à leur proposer).
Pour optimiser davantage l'expérience, vous pouvez essayer de déterminer quels groupes d'utilisateurs pourraient bénéficier d'une nouvelle fonctionnalité, et quels utilisateurs ne l'utiliseraient jamais, et annoncer ou minimiser la fonctionnalité à ces groupes respectivement.
Au début du test d'utilisabilité, donnez à l'utilisateur une tâche spécifique do TASK qui nécessite l'utilisation de la nouvelle fonction que vous avez ajoutée. N'est-ce pas pourquoi vous avez ajouté la fonction en premier lieu? Vous voudrez peut-être suivre un A3/PDCA pour garder la raison.
Si votre support est des images filaires sur papier ou monochromes, vous pouvez choisir une couleur pour mettre en évidence de nouvelles fonctionnalités/fonctionnalités comme indiqué ci-dessous:
Je suppose que vous construisez ces wireframes pour les tester avec les utilisateurs existants. J'aurai un point de vue différent sur ce sujet de celui mentionné dans les réponses précédentes. Je dis cela à partir de mes expériences personnelles lors de tests d'utilisabilité avec des prototypes en papier et des diapositives. Je me suis rendu compte que l'utilisateur ne se concentre pas sur des composants individuels mais se préoccupe davantage des flux de tâches et des scénarios de bout en bout.
C'est la nature humaine que nous voulons passer à n'importe quel test car c'est une norme socialement acceptée. Les tests d'utilisabilité sont très différents car nous, les designers, recherchons des personnes qui échouent. Indépendamment de la façon dont vous dites aux utilisateurs ce point, ils auront toujours l'impression de tout faire correctement (au moins sur une valeur nominale). Cela s'applique grandement au niveau de détails que vous donnez dans le test. Vous ne voulez pas que le test soit trop compliqué ou trop facile. Vous devez également faire attention à ne pas le laisser ouvert car les points de données que vous collectez seraient ambigus.
Pour en venir à votre question. Je pense qu'il est parfaitement normal de ne pas distinguer les anciennes fonctionnalités des nouvelles. Il suffit d'inclure suffisamment de détails dans les cadres de fil ou les maquettes qui permettront aux utilisateurs de terminer la tâche. Cela vous aidera avec deux scénarios:
- Si les utilisateurs sont complètement nouveaux, ils ne sauraient pas la différence et vous pouvez valider si les nouvelles fonctionnalités se fondent dans l'expérience existante. Ceci est important pour l'outil.
- Si les utilisateurs sont des utilisateurs existants de l'outil, laissez-les demander si la fonctionnalité est nouvelle. Beaucoup d'entre eux soulignent "je n'ai pas vu cette fonctionnalité dans la version précédente" et vous demandez simplement "quelle version êtes-vous ... celle-ci est la nouvelle fonctionnalité que nous proposons !!"
J'espère que cette réponse vous aidera dans votre encadrement filaire!
À la vôtre, Nishant
Pour être aussi proche que possible de la véritable interface utilisateur, je pense que vous devriez avoir un niveau de détail supplémentaire dans la structure filaire: les anciens composants doivent être "fonctionnels" dans le sens où ils peuvent être sélectionnés, et uniquement lors de la sélection, indiquez "vous ne le faites pas" t besoin d'aller ici ". Ce n'est que de cette façon que vous pouvez voir à quel point l'utilisateur de test est perdu lorsqu'il essaie de trouver la nouvelle fonctionnalité.
D'un autre côté, si vous voulez vraiment tester la nouvelle fonctionnalité elle-même, et non pas comment les utilisateurs l'activent ou la trouvent, il suffit d'avoir ces conseils clairs indiquant "vous êtes censé cliquer ici pour accéder à la partie qui est testée" .
La meilleure solution au problème est d'essayer 2 ou 3 solutions de conception, de les montrer à différents utilisateurs (contrebalancer l'utilisation de la conception pour chaque utilisateur) et vous obtenez des données pour savoir quelle conception a le mieux fonctionné.