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

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

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

  5. 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…

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

  7. 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é :

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

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

  10. 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 ?

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

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

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

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

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

Laisser un commentaire