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 :Première solution de mise en page des boutons sur un formulaire en ligne

Solution B :Deuxième solution de mise en page des boutons sur un formulaire en ligne

Solution C :Troisième solution de mise en page des boutons sur un formulaire en ligne

Solution D :Quatrième solution de mise en page des boutons sur un formulaire en ligne

Alors ? Votre avis ?

43 commentaires pour “Quels boutons pour un formulaire / assistant ?”

  1. le 12 janvier 2005 à 14:08
    sebastien billard a dit :

    Personnellement je préfére la solution B, qui est très proche des interfaces d’installation de logiciels par exemple (enfin sur windows).

    Mon second choix est la A. C et D sont très peu intuitifs AMHA

    HTH ;)

  2. le 12 janvier 2005 à 14:17
    Sebou San a dit :

    hello pour moi la solution B est la plus clair: - étape précédente et suivante ont la meme taille - abandonnez reste discret mais visible

    seb :)

  3. le 12 janvier 2005 à 14:31
    François Palaci a dit :

    Je trouve également que la proposition B est la plus claire. Elle présente l’avantage par rapport aux trois autres propositions de bien mettre en évidence le fait que le formulaire comprend plusieurs étapes. Ca devrait aider l’utilisateur à se repérer plus facilement.

  4. le 12 janvier 2005 à 14:35
    solo a dit :

    La B :)

  5. le 12 janvier 2005 à 14:37
    arnauld mascret a dit :

    Je préfère également la solution B qui me semble plus agréable que la D grâce aux flêches et au texte inscrit ( de plus la notion de validation n’apparait pas ce qui conforte dans la possibilité de revenir en arrière). Sur la solution D je préfère le bouton annuler au lien “abandonner tout” des autres qui correspond mieux aux IHM habituelles.

  6. le 12 janvier 2005 à 14:42
    kangoo a dit :

    “B” comme tout le monde, mais je n’aime pas la notion d’abandon. Je trouve cela traumatisant pour l’utilisateur.
    Pourquoi pas “tout recommencer“ ? (la perspective d’un nouveau départ est plus enthousiasmante que celle du renoncement par l’abandon)

  7. le 12 janvier 2005 à 14:43
    kangoo a dit :

    ou “revenir à…“, mais pas “tout abandonner” svp. :]

  8. le 12 janvier 2005 à 14:46
    LapinLove404 a dit :

    La B aussi…

    Le terme “étape” me semble meilleur que la notion de “validation” (qui, comme ca a été déjà dit, donne une impression de non-retour)

    Tout abandonner me semble aussi un mauvais terme. “Annuler” a l’avantage d’être moins négatif et d’être déjà utilisé à beaucoup d’autres endroits…

  9. le 12 janvier 2005 à 14:59
    vincent a dit :

    Ravi (pour une fois) d’aller à contre courant en proposant plutôt la A. La B revient à mettre sur un pied d’égalité le fait d’aller à la suite ou de revenir. Selon moi 90% des utilisateurs vont aller à l’étape suivante, donc pourquoi ne pas mettre le suivant en valeur tout en laissant quand même la possibilité de revenir en arrière. Application dans Internet Explorer (heureusement que je l’ai encore au boulot pour vérifier ça) : le bouton précédent est plus gros que le bouton suivant (moins utilisé). Néanmoins en choisissant la B on se rassure l’utilisateur en lui proposant un standard plus répandu (Cf commentaire de Sebastien).

  10. le 12 janvier 2005 à 15:40
    Emeric a dit :

    Bonjour,

    Fred, as-tu regardé comment font les gros acteurs du marché, en matière de commande en ligne ? Amazon, la Fnac, cdiscount, pixmania ?

    Je pense qu’il serait bon de s’inspirer de leurs modèles, d’abord parce qu’ils reflètent une expérience et une recherche déjà effectuée, mais aussi parce qu’il font office de standards et que les utilisateurs sont plus susceptibles d’être habitués à leurs procédés.

    Sinon, si je devais choisir parmi les propositions ce serait la B, mais je lui trouve quand même quelques défauts :
    1°) le terme “Abandonner tout” n’est pas clair. S’il s’agit d’une commande, par exemple, je mettrai “annuler la commande”. Il faudrait éclaircir le “tout”.

    2°) L’accès à l’étape précédente est clair, mais peut-être qu’il serait plus confortable pour l’utilisateur d’avoir une sorte de rappel des étapes effectuées et une possibilité de les modifier directement. Ex : Modifier les infos de l’étape 2 sans passer par la 3 quand on est à la 4.

    Je crois que le calcul des APL sur le site de la CAF offre cette possibilité :

  11. le 12 janvier 2005 à 15:58
    un autre Vincent a dit :

    Bonjour,

    Pour être franc, rien ne me convient… Peut-être qu’un mélange de la solution A et de la D serait pratique :

    • en gardant les boutons de validation du schémas D parce que, pour moi, la fonction Annuler ou Abandonner fait partie intégrante du formulaire et est une validation ;
    • et les flèches de B ainsi que les termes Étape précédente, Étape suivante avec, tout de fois, la même remarque que Vincent pour la grandeur de celles-ci.

    Bon, cela reste un avis et les Conseilleurs ne sont pas les payeurs….

    (Pour titiller inutilement ; la belle barre d’outil WYSIWYG n’est pas trop une barre d’outil WYSIWYG justement ;p)

  12. le 12 janvier 2005 à 16:03
    Fred a dit :

    En fait Emeric, les poids lourds du commerce en ligne utilisent une solution que je juge trop radicale : un seul bouton “Continuer” avec la possibilité de modifier sur la page finale de récapitulation avant confirmation définitive.

    /Fred

  13. le 12 janvier 2005 à 16:10
    vincent a dit :

    Encore peu répandus, les formulaires en flash qui dialoguent avec une base de données (cf le vu et revu exemple de reservation de chambre d’hotel, dont j’ai plus l’adresse sous la main). L’avantage est qu’on est pas obligé de recharger la page, de changer de page, etc… Peut être en 2007 ?

  14. le 12 janvier 2005 à 16:19
    Laurent Denis a dit :

    Instinctivement :

    Solution A de préférence (a priori, c’est le lien “valider et continuer” que je vais chercher à atteindre le plus souvent. En cas d’erreur, il me faudra un peu plus d’attention pour trouve le lien de retour en arrière, mais c’est un effort qui sera tout à fait de circonstances). Sinon B.

    Dans C, je vais confondre “Annuler” avec “Abandonner” et je ne vais pas y voir un moye de revenir en arrière.

    D me semble visuellement confus.

  15. le 12 janvier 2005 à 16:27
    Patrice a dit :

    Tout pareil. B aussi en premier choix et D sinon. D est assez “exotique”, il risque de faire peur à M. Tout-le-monde…

    
    			
  16. le 12 janvier 2005 à 16:30
    Julien a dit :

    Personellement, je suis plutôt la réponse A mais tout est question d’avis et d’habitude.

  17. le 12 janvier 2005 à 16:59
    Philippe a dit :

    Ma solution préférée serait de copier les interfaces d’installation des applications windows auxquelles les utilisateurs sont habitués :

    <Retour Continuer> Annuler

    Cela se rapproche de la solution D. Je crois aussi me souvenir avoir lu le même conseil dans un article qui parlait des normes d’IHM (malheureusement, je ne le retrouve pas).

  18. le 12 janvier 2005 à 17:07
    Frédéric a dit :

    Bonjour,

    Je me permets une petite remarque. (J’utilise SPIP pour mon blog et il me permet de répondre à une réponse de message, ce qui est très pratique pour savoir qui répond à qui). Dommage j’avais une très bonne opinion de dotclear jusqu’à présent … Aie, en plus le saut de ligne dans SPIP est géré automatiquement !

    Réponse à Vincent : Il est tout à fait possible de construire grâce au javascript et CSS, un formulaire “tout compris” style flash. Ce n’est pas une question de technologie.

    Réponse à Fred Cavazza : Pourquoi s’embêter à choisir ? En matière de web, le nombre fait le standard. Il suffit de voir ce que font les autres.

  19. le 12 janvier 2005 à 17:26
    Fred a dit :

    Il suffit de voir ce que font les autres, certes mais cela est à relativiser en fonction du contexte :

    • pour du commerce en ligne, solution A (l’utilisateur est sur des rails, il ne peut que progresser vers l’étape suivante)
    • pour une application en ligne, solution D - en fait celle de Philippe pour être plus exacte (l’utilisateur garde un certain contrôle sur ce qui est en train de se passer)

    Reste à savoir si le formulaire en question correspond plus à un contexte de commerce en ligne ou d’application en ligne. Je n’ai toujours pas la réponse…

    /Fred

  20. le 12 janvier 2005 à 17:45
    laure a dit :

    solution A : chacune des étapes va être validée individuellement (”valider”.. pas de possibilité de modifier)

    solution B : on remplit chaque page, et on valide / termine le tt à la fin… un peu comme amazon, mais avec une possibilité de revenir en arrière pdt la transaction.

    Pour un wizard, je pencherais moi aussi pour le B (suivant, suivant, suivant, terminer de windows).

  21. le 12 janvier 2005 à 18:01
    Emeric a dit :

    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.

  22. le 12 janvier 2005 à 19:46
    Martine a dit :

    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

  23. le 12 janvier 2005 à 20:14
    gou a dit :

    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…

  24. le 12 janvier 2005 à 21:05
    fablog a dit :

    Tout simplement la B.

  25. le 12 janvier 2005 à 21:26
    ^fabrice^^ a dit :

    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).

  26. le 12 janvier 2005 à 23:35
    lotof a dit :

    Tout simplement la B ;-)

  27. le 12 janvier 2005 à 23:57
    Patrick a dit :

    B c’est bien…

    (explosion de commentaires ;-)

  28. le 13 janvier 2005 à 10:54
    Matthieu FAURE a dit :

    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 :)

  29. le 13 janvier 2005 à 11:57
    stephane a dit :

    Je vote A.

  30. le 13 janvier 2005 à 12:09
    Amélie a dit :

    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

  31. le 13 janvier 2005 à 12:30
    JCG a dit :

    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

  32. le 13 janvier 2005 à 14:19
    frederic a dit :

    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)

  33. le 14 janvier 2005 à 14:46
    Natacha a dit :

    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

  34. le 15 janvier 2005 à 10:37
    SoWhat a dit :

    Quel plaisir de voir tant d’interet pour une ergonomie de dialogue….oui oui GOU ça vaut la peine de se casser la tête. Pour votre plaisir regardez ce qu fait M. David Lynch…http://patricklynch.net/

  35. le 15 janvier 2005 à 21:40
    Denis a dit :

    Tous les éléments pertinents ont été apportés il me semble. J’opte aussi pour la proposition B.

  36. le 18 janvier 2005 à 15:42
    katsoura a dit :

    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”.

  37. le 24 janvier 2005 à 11:19
    Bed a dit :

    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.

  38. le 24 janvier 2005 à 12:52
    Fred a dit :

    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

  39. le 25 janvier 2005 à 10:31
    Jean-François Paquerot a dit :

    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-

  40. le 25 janvier 2005 à 12:29
    Fred a dit :

    Merci JF pour ce choix, c’était ma proposition à la base ;-)

    /Fred

  41. le 1 février 2005 à 17:06
    Wolf a dit :

    La D car elle suit les process d’install des applications windows

    De plus des elements de même niveaux doivent etre representé de la même maniere

    Donc adios les liens de A B C

    -Ces liens ont ils un rapport avec mon action en court ???

    -Pourquoi sont ils representés differements ??

  42. le 2 février 2005 à 11:08
    herve a dit :

    et pourquoi pas un formulaire en une seule page ! avec boutons de deplacement dans les pages et ascenceurs faute de quoi : solution B

  43. le 18 mai 2005 à 13:57
    pom a dit :

    J’aime bien cette problématique d’un processus par étape.

    Je pense que la solution D est claire. On pourrait cependant y ajouter un nouveau bouton, qui serait “Finish”, qui permettrait éventuellement de finir tous le processus sans forcément passer par des étapes postérieures.

    Cette possibilité est par exemple offerte dans Eclipse, quand vous voulez créez un projet. Ce bouton est “grisé” tant qu’il n’a pas assez d’informations pour créer un projet, mais dès lors qu’il a les infos minimales, on peut finir le processus (et éventuellement le reprendre plus tard).

    Une idée qui est bonne, si vous voulez tenir compte de l’élément “vitesse” de remplissage de formulaire chez un utilisateur.

Laisser un commentaire