Modification des données sur la page de confirmation du formulaire en plusieurs étapes
Je conçois un formulaire très complexe pour un processus d'inscription pour un nouveau produit Web. Nous n'avons pas encore décidé si le formulaire sera un formulaire Wizard ou Intelligent (une page); nous testons A/B les deux options avec des clients bêta.
Si nous suivons l'itinéraire d'un Wizard et que l'utilisateur accède à la page de confirmation (dernière étape), quelle est la meilleure pratique pour éditer les données (en particulier les données qui dépendent des réponses précédentes dans le multi en deux étapes)? En supposant que l'utilisateur voit quelque chose qui doit être changé, est-il préférable de:
- Fournir une modification en ligne dans la page de confirmation elle-même et mettre à jour toutes les données modifiées dans cette page
- Renvoyez l'utilisateur à l'étape particulière pour terminer la modification et demandez-lui (potentiellement) de recommencer tout le processus pour apporter les modifications qui en résultent.
Je suggérerais de renvoyer l'utilisateur à l'écran où il a initialement rempli les données. À ce stade, l'interface doit être quelque peu familière à l'utilisateur. À l'achèvement dudit écran; si aucun autre écran ne doit être revu en fonction des modifications apportées par les utilisateurs, renvoyez-les à l'écran de confirmation afin qu'ils consultent à nouveau toutes les données.
Je préfère éviter l'édition en ligne. Je n'ai encore vu cela être utilisé nulle part. Les écrans de confirmation sont la dernière étape avant que l'utilisateur ne reçoive son "reçu" pour avoir terminé un processus en ligne. Cet écran doit rester en lecture seule car les utilisateurs s'attendent actuellement à ce que le prochain écran corresponde s'ils doivent atteindre un écran d'impression ou s'attendent à ce que les mêmes informations/mise en page dans un e-mail de réception.
Je conçois un formulaire très complexe
Ce sont à peu près comme des jurons ici. Mais en ce qui concerne la question, je recommanderais de renvoyer l'utilisateur à la section qu'il souhaite modifier. Mais je n'obligerais pas l'utilisateur à refaire tout le processus. Je ferais en sorte que l'utilisateur puisse revenir à l'écran de confirmation. De cette façon, l'utilisateur pourra éviter le spam suivant, suivant, suivant juste pour revenir à l'écran de confirmation.
Le problème que je vois avec un processus d'édition en ligne est que vous avez déjà mentionné que votre formulaire sera "complexe", ce qui signifie que l'écran de confirmation pourrait être un peu plus complexe. Il n'est donc pas nécessaire de le compliquer plus qu'il ne l'est déjà.
J'étais sur le point de poster cette même question, et je me penchais vers l'implémentation de l'édition en ligne. Mes pensées pour ceci étaient:
- Les utilisateurs peuvent être enclins à réagir négativement au renvoi. Dites qu'il s'agit d'un formulaire multi + pages, et qu'ils doivent corriger quelque chose sur la première page. La dernière chose que je veux faire est d'inciter à des sentiments négatifs JUSTE alors que nous sommes sur le point de leur faire remplir le formulaire.
- Les utilisateurs peuvent également réagir au renvoi de quelques pages en cliquant sur les boutons du navigateur qui (en fonction de votre configuration) pourraient affecter négativement les variables POST/GET transmises d'une page à la suivante. Bien que nous puissions faire beaucoup pour éviter tout effet négatif, nous ne pouvons pas prévoir et tenir compte de chaque option, surtout s'il s'agit d'un formulaire Web (par opposition à une application).
Quelque chose à considérer.