Comment gérer les éléments non fonctionnels dans le prototype?
Dans un prototype interactif, il y a souvent des éléments affichés qui ne fonctionnent pas comme ils le feront finalement, en raison de contraintes de temps, ne faisant pas partie de ce test utilisateur particulier, etc. Mais les éléments (boutons, liens, tout ce qui pourrait potentiellement interagir avec) apparaissent toujours pour l'utilisateur. Et parce qu'ils sont là, certains utilisateurs vont à un moment donné cliquer sur un, même lorsqu'ils sont dirigés vers des tâches qui ne correspondent pas du tout à cet élément.
Quelle est la meilleure façon de gérer lorsque les utilisateurs tentent d'interagir avec éléments non fonctionnels?
J'ai pensé à quelques possibilités, mais je ne sais pas si certaines d'entre elles sont viables ou s'il existe une meilleure solution que je ne connais pas du tout.
Par exemple, l'élément (par exemple, un bouton) peut être visible, mais ne pas réagir du tout lorsqu'un utilisateur clique dessus. L'utilisateur prendrait rapidement conscience qu'il ne fait rien pour le moment.
Le bouton peut afficher une info-bulle ou un indicateur visuel indiquant que cette fonction spécifique n'est pas disponible à ce stade.
Nous pourrions également nous assurer que chaque élément interactif qui fonctionne fonctionne inclut un état de survol, où ceux qui ne fonctionnent pas ne pas ont un état de survol, indiquant avant un cliquez qu'ils ne répondront pas.
Mais pour réitérer, quelle est la meilleure façon de gérer l'interaction involontaire de l'utilisateur avec des éléments non fonctionnels dans un prototype interactif?
J'aime l'élégance de l'utilisation des effets de survol (tels que décrits dans la réponse de Konturs), mais ceux-ci vont confondre les résultats de l'étude car cela guidera l'utilisateur à savoir dans quels domaines ne pas cliquer et au fil du temps, cela augmentera en fait leurs taux de réussite.
En fait, j'essaie généralement de m'assurer qu'aucune différenciation du curseur ne se produit, ce qui fait que le curseur est toujours un pointeur ou toujours un curseur de lien. Peu importe qui tant qu'ils sont cohérents dans l'étude. Cela aide à égaliser les règles du jeu lorsque l'utilisateur essaie de comprendre sur quoi cliquer ensuite.
De plus, les effets de survol ne fonctionneront pas pour le toucher. Ainsi, tout test sur mobile/tablette ne pourrait pas l'utiliser, à moins que l'info-bulle n'apparaisse qu'au toucher de la cible incorrecte - cela peut être la réponse à toutes les solutions: affichez un widget contextuel et non intrusif de type info-bulle qui apparaît sur la cible incorrecte, uniquement sur sélection intentionnelle de cette cible. Vous pouvez même utiliser cette solution pour les gestes lors des tests tactiles. En cas de geste infructueux, faites pour prototyper la fidélité, montrez le widget d'explication où le geste a été effectué ...
Je pourrais imaginer un curseur comme l'un des ci-dessous pour être une bonne indication visuelle que l'élément survolé n'est pas encore utilisable.
ou peut-être 
Les deux sont des styles de navigateur standard, donc leur implémentation dans un prototype basé sur HTML ne devrait nécessiter que peu d'efforts. Une info-bulle supplémentaire comme "fonctionnalité non disponible" pourrait également être utile.
Je pense que ces informations doivent être aussi discrètes que possible afin qu'elles n'attirent pas l'attention et n'interfèrent pas avec la session ou la présentation de test, sauf si cela est nécessaire, mais lorsqu'elles sont rencontrées, elles doivent être explicites en expliquant pourquoi la fonctionnalité ne peut pas être utilisée.
Quelle que soit la manière dont vous fournissez les informations, le plus important est de préciser clairement pourquoi l'élément ne peut pas être utilisé. L'utilisateur doit comprendre que l'élément n'est pas disponible non pas à cause de quelque chose qu'il a fait (ou n'a pas fait) et non pas à cause d'un comportement intégré au produit lui-même, mais plutôt parce qu'il n'est pas disponible dans le prototype.
Désactivez les éléments non fonctionnels: http://www.w3schools.com/tags/att_input_disabled.asp
De plus, cela aiderait à fournir une indication de couleur que l'élément n'est pas en jeu pour le distinguer de quelque chose qui est en jeu mais dans un cas désactivé selon le cas d'utilisation normal, mais parfois les styles CSS de couleur n'ont aucun effet sur certains éléments de certains navigateurs. Peut-être qu'une bordure en pointillés de couleur apparaîtrait, mais cela pourrait gâcher la disposition.
Dans tous les cas, les éléments hors jeu pourraient être gérés par un script à partir du balisage.
Vous ne devez pas indiquer visuellement qu'une fonctionnalité n'est pas implémentée dans votre prototype. Au lieu de cela, le modérateur de test utilisateur doit définir à l'avance l'attente selon laquelle le participant utilise un prototype et n'est pas un code de travail réel, et donc tout ne fonctionne pas si vous essayez d'interagir avec lui. C'est également un bon moment pour rappeler au participant que, puisqu'il ne s'agit pas d'un code de travail réel, ses commentaires sont particulièrement précieux pour vous, car vous avez une meilleure opportunité d'apporter des modifications en fonction de ses commentaires.
Si vous deviez utiliser un prototype où ils ont une indication visuelle de ce qui fonctionne et de ce qui ne fonctionne pas, vos participants scanneront le prototype avec leur souris ainsi qu'avec leurs yeux, en cherchant le curseur à changer pour qu'ils sachent quoi cliquez sur pour avancer. Non seulement vous augmenterez artificiellement leur taux de réussite (et aurez potentiellement un impact sur leur temps de tâche, si c'est quelque chose que vous mesurez), vous n'apprendrez pas non plus où ils pensent qu'ils devraient cliquer pour terminer leur tâche . Lorsque vous testez avec un prototype comme celui-ci, vous avez la possibilité de demander "pourquoi vouliez-vous cliquer ici?" ou "cela ne fonctionne pas, que pensez-vous qu'il se passerait si vous cliquiez dessus?". Sinon, vous pouvez simplement dire "cela ne fonctionne pas, pouvez-vous trouver un autre moyen?" Si vous constatez qu'une partie importante de vos utilisateurs dans l'étude essaient une manière particulière d'accomplir une tâche qui n'est pas ce que vous essayiez de tester, cela signifie que vous voudrez peut-être reconsidérer votre conception pour mieux l'adapter à leur modèle mental.