Quels boutons pour un formulaire / assistant ?

Je travaille en ce moment sur un projet de guide ergonomique dans lequel des recommandations doivent êtres faites quand à la présentation et mise en page des formulaires en ligne. Etant dans l’incapacité de me décider pour une solution ou une autre, je me permet de vous solliciter sur un problème bien précis :

Nous sommes dans le cas de figure où les utilisateurs doivent remplir un formulaire en ligne découpé en plusieurs étapes, une sorte d’assistant (wizard comme disent les anglo-saxons). A votre avis, laquelle de ces 4 propositions vous semble la plus claire, intuitive et posant le moins de problèmes d’interprétations :

Solution A :

Assistant-A

Solution B :

Assistant-B

Solution C :

Assistant-C

Solution D :

Assistant-D

Alors ? Votre avis ?

Un commentaire sur “Quels boutons pour un formulaire / assistant ?

  1. L’ennui avec la solution A, c’est la proximité du lien « annuler tout » et « retour en arrière ». L’erreur de clique coute cher en temps et patience.

  2. Bonjour, en tant qu’utilisatrice de base, je préfère les textes bien explicites, donc je suis pour un mixte des solutions A et B : à gauche la grosse flèche bleue avec « retour à l’étape précédente » à droite la grosse flèche bleue avec « valider et continuer » en dessous le lien « abandonner tout » tout seul pour qu’il soit bien visible

  3. Hummm… j’aime bien le défi. Je dois dire, avant tout, que je trouve très originales les solutions C et D avec des boutons de taille plus imposante. Efficace? difficile à dire comme ça, mais l’idée est vachement intéressante… je vais y penser… Pour ce qui est de la solution que je privilégie… j’hésite. Parfois la A, d’autres fois la B et, pourquoi pas, la d? ça dépend vraiment du contexte. Si c’est vraiment un Wizard, la version A me plait, mais j’y ajouterais un indicateur d’étapes. Cet indicateur pourra alors servir deux fonctions: le retour en arrière et le suivi du processus. Un bouton annuler devrait être présent en tout temps. Si on parle d’une application avec de grands formulaires, un bouton «enregistrer» peut être nécessaire pour permettre de conserver les données partiellement en cours de travail. M’enfin… peut-être que je me casse la tête…

  4. Avant et après lecture des commentaires, c’est B ! :) Avec peu être, comme c’est évoqué dans un des commentaires, la liste des étapes (passées, présente et à venir).

  5. Quelques remarques en vrac: Comme l’indique gou, un « indicateur d’étapes » est essentiel. L’utilisateur entre dans un tunnel (le remplissage du formulaire), il doit pouvoir se situer dans le processus. Une indication du genre « étape 1/6 » me parait importante. On fait face aux mêmes problématiques qu’en accessibilité, quand on n’a qu’une vue partielle du document, il est capital d’avoir des éléments de répérages auxquels s’accrocher. Ici il faut savoir à quelle distance on se trouve du bout du tunnel, et savoir si on peut faire demi-tour. Dans les solutions A, B et C, le fait que des liens soient une ligne en dessous pourrait sous-entendre qu’il s’agit d’opérations d’un autre registre (est-ce en rapport avec le formulaire ?). Par ailleurs on comprend la fonction du lien, mais on ne connait pas sa destination. Dans la même veine, s’agit-il de boutons ou de liens ? A priori (à prendre avec des pincettes) dans un formulaire, une action devrait être accessible par un bouton, du moins du point de vue de l’accessibilité. Solution D: on ne sait pas si le bouton « Annuler » annule l’opération courante ou tout le processus. Peut-être que le terme « abanbonner » serait plus explicite (abandonner me semble plus fort que annuler, donc annule plus fort :) ). Enfin, voici mes impressions au « premier coup d’oeil » (comprendre à l’instinct): solution A: « comment je reviens en arrière ». Je n’ai pas vu/lu les liens écrits en-dessous en petit solution B: « compris » solution C: « Ah, ils ont inversé l’ordre des boutons Valider et Annuler ». C’est très personnel, mais c’est le but du test que de recueillir ces infos ! solution D: « compris. Ah en plus je peux annuler » Je n’avais pas vu/lu les petites lignes de la solution B. Voilà, en espérant que cela te soit utile :)

  6. B? (héhé) avec peut-être une distinction de format entre étape suivante et précédente (en plus de la situation, du sens de la flèche et du texte), par exemple une couleur ou une différence de taille indication de l’étape courante (exemple 2/4), et selon le contexte du thème de l’étape suivant (exemple paiement) idem emeric pour « abandonner tout »: contextualiser le terme, et éventuellement utiliser annuler au lieu d’abandonner

  7. Salut, Personnellement, je partage l’un des derniers commentaires: un indicateur d’étapes situé en haut de page indiquant l’étape en cours, les étapes passées et ce qui suit me paraît nécessaire. A toi de voir son look et ensuite, si tu te sers de cet indicateur comme un simple outil de repérage ou comme un outil de repérage et de navigation (ça complique les choses ;les utilisateurs ne le comprennent pas forcément et ne l’utilisent pas toujours ! vu en test !) En ce qui concerne les boutons, la solution D correspond en partie à ce que j’ai déjà préconisé dans le passé pour les écrans (étapes) de saisie. Toutefois, je garderais les mêmes dimensions de boutons et remplacerais > par … derrière Continuer. Je dis en partie, car évidemment sur la 1ère étape de saisie, je ne mettrais pas de « Précédent » ou « Retour » mais simplement un « Annuler », et sur un écran récap., je remplacerais « Continuer » par « Envoyer » (ou un équivalent « Valider »). Comme tu peux le constater, l’ensemble va varier selon moi en fonction du nombre d’étapes de saisie, du nombre d’écran, du fait que tu proposes ou non un récap et du type de feedback système. Sans parler du contexte de l’application, des tâches utilisateur et des transactions en jeu … car le modèle B par sa simplicité est trés « utilisable » dans certains contextes. A bientôt, JC

  8. et oui fred tu as le réponse depuis le début,solution a pour du e-commerce et solution b pour une application plus administrative, pour moi il faut eviter le terme abandonner, reprendre depuis le début me parait mieux ou un truc du style. solution d et c definitivement non ( et oui je suis assez classique)

  9. Comme Martine je propose un mixte des solutions A et B : – à gauche la grosse flèche bleue avec « retour à l’étape précédente » – à droite la grosse flèche bleue avec « valider et continuer » – en dessous le lien « abandonner tout » tout seul pour qu’il soit bien visible Des choses simples et limpides

  10. Je vote B. Les deux flèches indiquent clairement, même sans lire son intitulé ce que je peux faire: aller en avant et en arrière. Contrairement à Laurent, je dirais que la flèche retour rassure le visiteur qui sait qu’à tout moment il peut revenir en arrière. Ce procédé est utilisé également pour l’installation de logiciel. Par contre le mot « abandonner » est trop péjoratif. Il s’assimile à « baisser les bras » qui pourrait signifier « être incapable de ».

  11. Bonjour, Comme quoi une question a priori anodine peut provoquer des réflexions intéressantes.
    Personnellement je suivrai l’avis général et, dans le contexte d’une application, je choisirai l’option B en reprenant les propositions d’adaptations suivantes : flêche « étape suivante » plus grosse indicateur d’étape Pöur aller un peu plus loin, et au risque de peut-être rendre l’interface un peu moins claire, je propose également de : distinguer le souhait de l’utilisateur d’abandonner complètement le formulaire (« Abandonner formulaire » ou « Détruire le formulaire et quitter ») et celui de recommencer au début en réinitialisant (« Recommencer à zéro » ou « Tout effacer et recommencer ») proposer à l’utilisateur de revenir sur n’importe quelle étape (« 1 – 2 – … »)? Bien à vous.

  12. Oui Bred, ton intention est louable, mais est-ce que cela ne fait pas un peu trop de boutons ? Rappelons que nous sommes en train de parler des boutons qui viennent en plus des éléments du formulaires (champs, cases à cocher, boutons radios…).
    N’y a-t-il pas dans tes propositions un risque de surcharge cognitive (trop de choix) ? Encore une fois, je ne connais pas de solution miracle (sinon je n’aurais pas demandé l’avis des lecteurs), mais je préférerais privilégier la solution où les utilisateurs sont sur des rails : ils se concentrent sur les questions du formulaire.
    /Fred

  13. Salut Fred, De mon coté, je préfère la D : la disposition des boutons me semble bonne et logique (progression vers la droite dans le sens de l’écriture et qui est conforme à l’usage sur la majorité des sites donc pas de confli avec l’expérience utilisateur actuelle). La taille donnée aux différents boutons également (continuer est mis en valeur). -JF-

Laisser un commentaire