Emplacement du bouton de la case à cocher "Terminé"
Mon équipe a du mal à décider où placer une case à cocher terminée.
Nous avons un site Web contenant une collection de pages consécutives de la première page à la dernière page. Chaque page peut être un texte ou une affectation. La case à cocher est utilisée par les utilisateurs pour marquer une page comme "terminée". Les utilisateurs ont également la possibilité de naviguer vers la page suivante ou précédente en cliquant sur les boutons Next et Previous. Les utilisateurs peuvent cliquer sur Next ou Previous indépendamment du marquage de la page comme terminée.
Workflow typique: l'utilisateur lit la page, clique sur Done, puis sur Next. Parfois, l'utilisateur cliquera sur Done sans cliquer sur Next ou Previous, s'il ne souhaite pas continuer à ce stade. Nous n'attendons pas des utilisateurs qu'ils cliquent sur Previous très souvent.
Voici quelques suggestions concernant le placement:
Un menu montrera quels textes/devoirs sont effectués: 
Qu'est-ce que tu penses?
Pourquoi ne pas fusionner les boutons terminé et suivant? Cette mise en page permet toujours à un utilisateur de continuer sans en finir avec la page, mais nécessite moins de clics.
Idéalement, d'un point de vue UX pur, il ne devrait pas y avoir du tout une telle case à cocher. Il s'agit d'un clic supplémentaire inutile. Les utilisateurs devraient pouvoir simplement cliquer sur Suivant et il est naturellement supposé qu'ils ont terminé.
Cependant, je suppose que c'est une boîte qui existe pour une sorte de raison de conformité? C'est l'une de ces cases "Oui, j'ai tout lu ici et je suis entièrement d'accord avec lui, signez donc ce document".
Dans ce cas...
1: Non. Pas bon. Il met la case à cocher avec les commandes. C'est confus.
Terminé ressemble également un peu trop aux boutons suivant et précédent. Ce n'est pas un bouton non? C'est juste une étiquette.
2: Emplacement optimal pour un flux utilisateur rapide à partir du document qu'ils lisent. Ils arrivent à la dernière ligne puis passent à la ligne suivante - oh regardez, c'est le bouton terminé.
3: Groupes effectués avec les contrôles, ce qui n'est pas idéal, cependant, si vous déplacez la ligne de frontière entre les contrôles et le contenu en dessous du bouton terminé, c'est l'endroit optimal pour un flux utilisateur rapide vers le bouton suivant. - Ils voient et cliquent sur terminé et il faut un coup d'œil et un mouvement en microsecondes pour cliquer ensuite.
Je dirais aller avec 2. C'est le texte qui est la partie importante, pas le bouton suivant. Vous voulez vous assurer qu'ils ont lu le texte. Il pourrait même être considéré comme souhaitable d'empêcher un peu l'utilisateur de taper sur le bouton suivant - de tels accords grisant souvent les boutons suivant/accepter jusqu'à ce qu'une action cohérente avec tout lire (ou prétendre l'avoir fait) soit effectuée.
Cependant le point le plus important est de changer le libellé fait. Terminé sonne comme une action. Que ce soit dans cette boîte le rend doublement. Un texte plus standard sur la lecture de tout et son acceptation doit être utilisé. Fait devrait également ressembler beaucoup plus à une étiquette qu'à un bouton.
Pour les logiciels d'entreprise, la conception du flux de travail d'abord, la beauté ensuite
Observations de conception:
Les utilisateurs ont tendance à traiter les pages de texte en utilisant le motif F , où l'œil a tendance à utiliser la marge gauche pour ancrer le flux visuel en bas de la page.
Votre flux de travail est grosso modo:
- Lire le texte
- Frappé Done
- Frappé Next
Parfois, l'utilisateur peut frapper Previous au lieu. Parfois aussi, l'utilisateur peut vouloir frapper Done sans frapper Next ou Previous.
Loi de Fitt suggère qu'il vaut mieux ne pas placer les boutons trop éloignés s'ils sont souvent utilisés. Autrement dit, ne rend pas difficile pour l'utilisateur de frapper Done puis doivent voyager loin pour frapper Next
Le placement des boutons doit communiquer le flux de travail . Autrement dit, si vous voulez que l'utilisateur frappe Done puis Next, puis placez les boutons exactement dans cet ordre à l'intérieur du flux visuel principal.
Maintenant, concevez autour du workflow:
Étant donné le motif F, la loi de Fitt et la séquence de votre flux de travail, le meilleur emplacement pour les boutons est en bas de la page après le texte, car il suit le flux de travail de manière séquentielle.
Placez un séparateur visuel (comme une ligne horizontale) au-dessus des boutons pour indiquer à l'utilisateur qu'il entre dans la prochaine étape du flux de travail après avoir examiné le texte.
Placez les boutons les plus couramment utilisés dans la même séquence que le flux de travail (c.-à-d. Done puis Next).
Souligner la Previous car il est moins utilisé. En le désaccentuant, vous rendez le flux de travail normal plus clair .
- Bien que vous puissiez être tenté de Previous bouton symétrique avec le Next , n'oubliez pas que pour les applications d'entreprise, un flux de travail efficace passe en premier. Ce n'est pas un concours de beauté, l'efficacité est généralement beaucoup plus importante que la beauté pour les applications professionnelles.
Une conception résultante:
Cette disposition respecte le motif F aligné à gauche, présente le flux de travail dans le bon ordre de haut en bas et de gauche à droite, remplace la case à cocher par un bouton (zone cible plus grande et plus simple = plus facile à utiliser), présente le Done et Next boutons dans l'ordre correct et intuitif du flux de travail, et met en surbrillance la Previous afin qu'il soit toujours là lorsque l'utilisateur en a besoin, mais qu'il soit correctement placé en dehors du workflow principal.
BTW, je pense Accept ou Approve est plus typique pour les documents d'une page que Done (ce qui implique que vous avez terminé avec l'ensemble du flux de travail), mais ce choix de mots ne fait pas partie de votre question, j'ai donc utilisé les termes que vous avez donnés.
Si une majorité importante des utilisateurs cliquent sur Next après avoir sélectionné Done, vous pouvez concevoir principalement pour ce flux de travail. Github fait cela avec un bouton combiné pour commenter un bug logiciel avec/sans marquer le bug comme corrigé:
Sans connaître vos exigences, il suffit de marquer une page en utilisant Archive and next, suivi de Previous ou en s'éloignant.
Cette réponse est basée sur ces deux commentaires de l'affiche originale ...
Ils peuvent le voir dans un menu à gauche où ils peuvent également naviguer entre les pages. Il est certainement là pour aider l'utilisateur à se souvenir de ce qu'il a fini/n'a pas fini.
Cela pourrait être une sorte de cession. Passer à une autre étape ne signifie pas que vous avez terminé le devoir.
Permettre aux utilisateurs de marquer ce qui est Done ou Not Done dans la liste des affectations à gauche aidera à fournir le contexte sans perturber le flux. Ce n'est pas une très bonne expérience utilisateur si je dois d'abord sélectionner une affectation dans la liste, puis trouver où la marquer comme terminée ailleurs.
Considérez plutôt une interaction similaire à celle-ci ...
Suivez automatiquement la progression de l'utilisateur via une affectation
S'il y a 4 questions dans le devoir et que l'utilisateur répond à l'une d'elles, marquez automatiquement la section comme terminée à 25%. De même, s'il y a 4 pages de texte et que l'utilisateur fait défiler 3 des pages mais ne voit jamais la 4e page, il la marque automatiquement comme terminée à 75%.
Autoriser l'utilisateur à marquer/décocher manuellement les sections
Dans la liste des sections à gauche, vous pouvez afficher le pourcentage achevé ainsi qu'un moyen de marquer les choses comme terminées ou annulées.
Notant que la coche est un élément important mais simplement visuel, je peux suggérer qu'elle n'apparaît que lorsque le bouton de déclenchement Terminé est cliqué.
Étendre une théorie forte ...
Je voulais vous montrer cette solution d'interface utilisateur simple et élégante (inspirée du Kindle et de la tablette.)
Cliquer sur la coche fantôme fait basculer la coche pleine!
Dans les deux cas, l'état des choses est instantanément visualisé par l'utilisateur.
Je pense que c'est mort. Sinon, je conviens que le bouton Terminé devrait être plus proche du bouton Suivant. Cela semble logiquement orienté. Et l'espace dans lequel les éléments utilisés doivent être compressés, comme dans votre exemple 1, Mattias.
J'irais pour la troisième option, car le bouton Done reste proche du bouton Next et, pour autant que je puisse voir, il semble logique que le flux normal pour l'utilisateur soit vérifier la Done puis cliquez sur le bouton Next.
Pourquoi pas la première option alors?
À mon humble avis, lorsque vous avez une ligne pour les boutons de navigation, vous ne devez pas mettre des boutons avec d'autres fonctionnalités dans la même ligne.
Les utilisateurs ont l'habitude de voir le nombre de pages et d'autres actions de pagination entre les boutons Back et Next, et vous les confondrez en y plaçant le bouton Done.
De plus, vous pourriez avoir une autre action à l'avenir (comme marque comme favori, etc.), et vous aurez besoin d'un endroit pour y mettre le bouton. Si vous avez tous vos boutons dans la ligne de navigation, le nouveau ne rentrera pas avec les autres boutons et vous devrez changer le flux que l'utilisateur connaît déjà, ce qui est mauvais.
À moins qu'il n'y ait une raison réglementaire d'avoir un bouton terminé, n'en avez pas du tout, la prochaine devrait définir votre état fini. Vous pouvez compléter cela avec sauter avant et/ou marquer l'endroit où sauter les fonctions comme suivant sans définir terminé et marquer l'endroit peut ou non marquer comme terminé mais permet à vos utilisateurs de ramasser plus tard (comme après le déjeuner)
Je pense que ce bouton d'action devrait être placé dans sa propre ligne, afin de ne pas confondre l'utilisateur avec les éléments de navigation et d'éviter davantage la confusion, faites-le ressortir comme l'activité secondaire confirmation (le principal étant la lecture du texte , tertiaire allant à la page suivante).
Pour ce faire, peut-être offrir une couleur positive (vert) avec une grande coche sur confirmer l'acceptation, pas seulement une case à cocher générique qui suggère presque d'activer ou de désactiver une option.
En ajoutant la case à cocher votre bâtiment dans une contrainte avant de sélectionner le bouton suivant. Vous voulez aller avec l'option 2 car elle découpe la case à cocher avec le contenu. Idéalement, vous devez "désactiver" le bouton "Suivant" jusqu'à ce que l'utilisateur sélectionne la coche. Modifiez également votre étiquette de "Terminé" à "D'accord" s'il s'agit d'une règle commerciale de conformité et évitez de faire ressembler à un bouton. L'action doit être dirigée vers la coche.
Étant donné que cela semble être plus pour l'e-Learning que de simplement cocher des cases dans un formulaire Web séquentiel, il est important de donner aux apprenants un degré approprié de contrôle sur leur rythme d'achèvement . Les apprenants doivent être libres de se déplacer d'avant en arrière dans le contenu (au moins dans le contenu sur lequel ils travaillent immédiatement ou ont déjà terminé). Il est donc logique de séparer "J'ai terminé cette tâche" de la navigation simple entre les tâches connexes.
Comme d'autres l'ont suggéré, votre 2e option gère ce mieux en plaçant le contrôle "achèvement" directement avec le contenu associé. Cela laisse la navigation intra-étape séparée et sans encombre. J'opterais également pour cette solution et soutiendrais également les suggestions d'utilisation d'un verbe et de le rendre réversible (ce qui est généralement une case à cocher par nature). "Mark Complete" ou quelque chose à cet effet.
Enfin, l'approche "table des matières" de la barre latérale avec une option pour marquer des éléments individuels (ou même "Marquer tout comme terminé") est bonne, mais pourrait être meilleure si elle est effectuée conjointement avec l'approche page par page afin les gens peuvent voir exactement quel contenu ils marquent. Utilisez-le comme une option secondaire pour un marquage rapide, mais ne leur faites pas essayer de se rappeler quel titre de leçon était lequel.
Je pense que l'option 3 est la meilleure parce que la souris de l'utilisateur est plus susceptible d'être sur le côté droit de l'écran en se déplaçant vers le bas en raison du positionnement de la barre de défilement horizontale.
De plus, les théories du mouvement de Guttenberg et du modèle Z du mouvement des yeux suggèrent que le côté inférieur droit de la page est le dernier point atteint par votre utilisateur sur la page (le dernier indiquant que l'utilisateur a terminé et est prêt à passer au suivant), et donc les boutons fait/suivant devraient logiquement apparaître ici.
Enfin, s'ils se dirigent vers la prochaine pression, il va de soi que le bouton fait doit être trouvé à proximité. Vous pouvez le positionner à gauche de suivant comme dans l'option 1, mais cela nécessiterait que l'utilisateur déplace sa souris vers la gauche et vers l'arrière, ce qui est une action inutile comme le montre l'option 3.