Imaginez une application qui présente un certain nombre de questions et réponses à un utilisateur. Après chaque question, l'utilisateur peut évaluer la réponse (facile/moyen/difficile).
Sur la base de la note, la question est soit:
Je suis en train de débattre si la formulation pour demander à l'utilisateur une évaluation devrait impliquer ce que cette évaluation implique.
Exemple A, simple:
Rate this answer:
() Easy
() Not sure
() Hard
Exemple B, impliquant une action supplémentaire:
Rate this answer:
() Easy
() Repeat in a while
() Repeat soon
Il existe un composant d'interface utilisateur supplémentaire qui indique l'état de chaque question, de sorte qu'au bout d'un certain temps, l'utilisateur peut découvrir que les questions "dures" sont répétées plus souvent.
J'aime la simplicité de la version A, mais indiquer le résultat de l'action (c'est-à-dire la note) aurait également du sens. Existe-t-il des directives pour ce genre de choses?
Note: J'ai pensé à combiner les deux ("Pas sûr, répétez dans un moment"), mais c'est trop de texte.
En supposant que cette application est une sorte d'outil d'apprentissage par carte flash, j'hésiterais à rendre la connexion explicite entre la note et à revoir la question. J'y pense comme ceci: l'utilisateur vient de poser une question vraiment difficile et ne l'a pas appréciée. Puis, tout de suite, vous leur donnez l'occasion de ne plus revoir cette question. Même pour un utilisateur qui a délibérément choisi d'apprendre ce matériel, c'est une opportunité de sortir, juste au moment où il est le plus susceptible de le faire. Et vous leur donneriez cette opportunité de sortir après chaque question. Je suis peut-être pessimiste quant à l'esprit humain et à la volonté d'apprendre, mais il semble que vous empiliez les chances de votre utilisateur.
Je pense qu'une option qui empile les chances dans l'autre sens serait bonne: quelque chose comme ça.
Comment avez-vous trouvé la question?
- Trop facile pour moi
- Juste à droite
- Difficile
Si "Comment avez-vous trouvé" est trop idiomatique pour votre public, "La question était ..." serait un remplacement décent. Si vous êtes toujours intéressé à l'idée de montrer le résultat de chaque option, je pense encore une fois qu'il est important d'aller pour quelque chose qui le pondère vers la bonne réponse:
Que pensez-vous de cette question?
- Trop facile: ne me le redemande pas.
- Je pense que je l'ai, mais testez-le à nouveau plus tard.
- J'ai besoin de plus d'entrainement.
Maintenant, étouffer une question difficile nécessite de mentir activement, et l'option "c'était dur" est plus une identification avec la façon dont l'utilisateur se sent. Dans l'une de mes applications, je serais très satisfait du passage d'une question à la deuxième personne à une réponse à la première personne, mais si vous n'aimez pas cela, il est assez facile de garder l'idée tout en reformulant les réponses.
Que pensez-vous de cette question?
- Trop facile (je ne le redemanderai pas)
- Parfait (mais je vous testerai à nouveau plus tard)
- Difficile (je vous donnerai l'occasion de pratiquer bientôt)
Et en guise de note finale, je vais juste implanter l'idée que vous pourriez peut-être éviter complètement la question, en jugeant la difficulté en fonction du temps qu'il faut à l'utilisateur pour répondre et de la fréquence à laquelle il réussit.
L'exemple A est une note et n'indique pas le résultat. Le résultat doit donc être expliqué quelque part dans une section de règles distincte, peut-être plus en détail. Ainsi, vous aurez une note et une référence aux descriptions de résultats.
L'exemple B n'est pas une note, son titre prête à confusion, il doit donc être modifié, par exemple:
Repeat this answer?
() Never
() In a while
() Soon
Le choix entre l'évaluation et les actions dépend des autres fonctionnalités de l'application.