Si et comment diviser un long assistant en principales étapes et sous-étapes?
On me donne la tâche de concevoir un long formulaire Web qui demande à un utilisateur de saisir beaucoup d'informations sur une installation technique qu'il a planifiée/construite. Compte tenu de la nature des données requises (il existe différents blocs, presque tous les champs sont obligatoires et certaines dépendances suggèrent un certain ordre), je me suis organisé en assistant. Cependant, après avoir divisé le processus en étapes principales claires (la partie facile), il me restait suffisamment de champs de saisie pour justifier un regroupement supplémentaire.
Dans ce "deuxième niveau" de saisie de données, cependant, les morceaux ne sont pas nécessairement ordonnés ou dépendants et je m'attends à ce qu'il y ait plus de va-et-vient (bien que la plupart des utilisateurs iront de groupe en groupe). En conséquence, j'ai considéré
a) une structure à onglets qui permet des sauts "libres", tout en faisant allusion à une approche de haut en bas comme procédure standard et
b) un assistant-machinerie secondaire avec un autre ensemble de "sous-étapes", qui est plus rigide
EDIT: c) une autre possibilité serait de créer un niveau secondaire directement dans l'assistant pour illustrer les sous-étapes. Cela fonctionnerait comme b), mais communiquez cela avec différents visuels.
C'est une question similaire à celle-ci , et essentiellement ma suggestion est une combinaison des deux approches dans la réponse acceptée, cependant, elles sont présentées ici comme des alternatives, pas en combinaison. C'est aussi une approche pour répondre cette question sur les longs sorciers , mais qui n'a pas été discutée ici.
Mes questions sont:
- Quelqu'un a-t-il de l'expérience avec ce type d'approche à deux niveaux? Y a-t-il des pièges possibles dont je dois être conscient ou y a-t-il quelque chose de complètement déconseillé à ce sujet? (certaines lectures suggèrent de ne pas mélanger les onglets et les assistants, mais cela se réfère principalement à "ne pas utiliser les onglets lorsque la fonctionnalité est un assistant")
- Au lieu des onglets, j'ai également considéré un style d'accordéon pour le niveau secondaire (un peu comme cet exemple jQuery ou cette réponse ici ). Cependant, d'autres commentaires que j'ai lus ici indiquent que les accordéons sont "boiteux" ou "old school" ou "uniquement pour mobile" sans beaucoup de détails au-delà. Quels seraient donc les inconvénients réels dans cette situation donnée?
- Je me penche actuellement vers l'assistant à deux niveaux plutôt rigide. Comme je l'ai dit, la plupart des domaines sont obligatoires et importants et je n'ai pas encore trouvé le besoin d'aller de l'avant. Dans ce cas, je me demande comment concevoir la navigation avant/arrière. Le bouton Suivant en cours est censé passer à la sous-étape suivante, tandis que la dernière étape contient le bouton "vers la prochaine étape principale". Cependant, je ne suis pas encore tout à fait satisfait de cela car cela peut dérouter les utilisateurs. Des idées, des expériences?
Si je devais choisir, je voterais pour le troisième des options présentées. Il a un indicateur de progression plus intuitif qui semble le plus naturel (dans l'ensemble des propositions que vous avez présentées).
Si je devais suggérer une approche à un long problème d'assistant, je proposerais de inverser la relation: ne pas les forcer à remplir toutes les informations requises, juste permettre d'ajouter une entrée d'informations d'installation et marquez-la comme non terminée (" vos informations d'installation sont complètes à 10% "). Cela permet à un utilisateur d'entrer les informations pièce par pièce pendant qu'il est tiré vers la fin des informations, plutôt que de forcer à remplir toutes les informations à la fois. Il simplifie également la conception de la page "profil" d'installation.
Qui a dit que l'accordéon était à l'ancienne? Je suis très en faveur des assistants de style accordéon qui révèlent progressivement les questions et fournissent également des commentaires sur les réponses déjà données.
J'ai fait une de ces questions pour un questionnaire financier pour un client: 
Ils sont également utilisés dans de nombreuses caisses bien conçues comme celle de harrods et John Lewis .
Les avantages sont:
- Vous pouvez progressivement divulguer des questions en fonction des réponses (vous pouvez donc modifier la progression via l'assistant.
- Les utilisateurs savent à tout moment où ils se trouvent.
- Les utilisateurs ont un aperçu des réponses déjà données et peuvent facilement y revenir. Je pense que cela couvre votre problème de navigation avant/arrière.
- Cela raccourcit la durée de l'assistant, car les questions sont toutes présentées sur une seule page.
Sur la base de vos images filaires ci-dessus, je pense que vous êtes déjà sur la bonne voie. Je suggérerais cependant de créer un sous-assistant similaire plus petit sous la barre principale de l'assistant pour conserver la cohérence de la page. Avec quelques légers ajustements qui peuvent être vus ci-dessous, vous pouvez fournir une clarté supplémentaire de l'endroit où un utilisateur est actuellement dans le processus avec une simple flèche. Pour permettre la navigation entre les différentes étapes, il suffit de transformer le titre de chaque étape en lien.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
