Assistant / stepper progressif: les états ne doivent-ils être contrôlés que par le bouton de retour?
Supposons qu'un stepper comporte 6 étapes. L'utilisateur peut-il passer directement à la 4ème étape ou doit-il suivre le même flux en cliquant sur "enregistrer et continuer" . Même flux pour l'ordre inverse également.
Par exemple:
L'étape 2 ou 3 doit-elle être cliquable par l'utilisateur? Supposons que l'utilisateur est à l'étape 3 et souhaite apporter des modifications à l'étape 1. Si l'utilisateur clique sur l'arrière bouton deux fois pour atteindre l'étape 1 ou l'utilisateur peut-il passer directement à n'importe quelle étape en cliquant sur le numéro ci-dessous?
Quel devrait être le flux idéal pour un assistant ?
Je dirais que si vous empêchez l'utilisateur de revenir à une étape, cela empêcherait la liberté de l'utilisateur. Cependant, vos règles métier peuvent suggérer qu'un utilisateur doit suivre un flux.
Il me semble que cela n'a pas d'importance, donc je donnerais à l'utilisateur la liberté de choisir s'il a besoin de revenir à cette autre section. Si la modification des données dans la précédente affecte les étapes futures, incitez l'utilisateur à parcourir le flux.
MODIFIER:
Si l'utilisateur n'a pas procédé aux étapes futures, je ne l'autoriserais pas. Si l'utilisateur est à l'étape trois et qu'il souhaite passer à l'étape un, autorisez l'utilisateur à cliquer sur cette étape. La raison pour laquelle j'hésite à laisser la liberté de se déplacer entre les étapes au début avant d'atteindre les étapes, c'est parce que nous devons d'abord passer par chaque étape. Ne faites jamais travailler plus dur l'utilisateur pour arriver là où il doit se rendre (en cliquant deux fois sur le bouton de retour).
Donner la possibilité de revenir en arrière prend en charge l'annulation et la restauration même si les utilisateurs n'utilisent pas toujours ces fonctionnalités cachées. Si vous avez une page d'avis, cela pourrait devenir très bénéfique si un utilisateur ne sélectionnait pas correctement ce qu'il voulait.
Et sur un sujet hors sujet. Au lieu de nommer les boutons "Suivant" ou "Précédent", donnez plus de sens à vos boutons tels que "Détails de l'annonce" et "Tailles de l'annonce" ou "Détails" et "Taille". Il est préférable de rester à l'écart des étiquettes de boutons ambiguës telles que "Suivant" ou "Précédent".
Comme tout le monde l'a mentionné, les tests vont très loin, mon ami: D
Comme pour de nombreuses autres questions de conception/convivialité, la réponse dépend du contexte.
Toutes choses étant égales par ailleurs, je dirais que permettre à l'utilisateur de sauter en arrière/en avant est une fonctionnalité utile . Il permet à ce que Nielsen/Norman, dans leur liste d'heuristiques d'utilisation, appellent le contrôle et la liberté des utilisateurs: https://www.nngroup.com/articles/ten-usability-heuristics/
Mais je vous exhorte à tester vos conceptions avant de prendre une décision . Cette fonctionnalité peut être coûteuse à mettre en œuvre et les avantages peuvent être limités.
Par exemple, j'ai créé un prototype de formulaire d'assurance de plusieurs pages. Sur chaque page, j'avais des boutons qui permettaient à l'utilisateur d'avancer/reculer à chaque étape, ainsi qu'un indicateur de progression cliquable, qui permettait aux utilisateurs de passer à n'importe quelle étape.
Lors de mes tests d'utilisabilité, les utilisateurs ont ignoré les boutons de retour et la barre de progression cliquable. Ils voulaient remplir le formulaire de la manière dont il était présenté, un page à la fois. Ils avaient tendance à ne pas vouloir revenir en arrière ou à avancer.
Mais votre propre conception/tests peut révéler quelque chose de différent.
Il existe deux types de steppers:
Steppers modifiables - permet aux utilisateurs de revenir plus tard pour modifier une étape. Celles-ci sont idéales pour les workflows qui impliquent des étapes d'édition dans une session. Dans ce cas, utilisez un stepper non linéaire qui permet à l'utilisateur de parcourir toutes les étapes.
Les pas à pas non modifiables doivent être utilisés lorsque les utilisateurs ne peuvent pas modifier une étape plus tard (dépendances) OR la modification des étapes pose un risque de distraction pour l'achèvement du formulaire. Et dans ce cas, utilisez un pas à pas linéaire qui interdit à l'utilisateur pour parcourir les étapes.
Lorsque vous effectuez ces opérations sous forme d'étapes (assistant), vous utilisez l'approche "tunneling". L'utilisateur doit donc remplir les étapes de un à six et ne doit pas passer à six d'un. L'idée derrière le tunneling est de donner l'emplacement exact de la progression à l'utilisateur. Ces cercles ne sont pas comme des onglets, ils devraient donc fonctionner comme des indicateurs de progrès. L'utilisateur ne peut aller et venir qu'une seule étape.
Vous pouvez fournir ces extensibles plutôt que l'assistant si vous souhaitez donner à l'utilisateur le pouvoir de modifier les sections dans l'ordre.