Est-il intuitif qu'un bouton "oui" ou "non" passe automatiquement à l'étape suivante dans un assistant?
Je conçois un assistant avec 4 étapes. Pour rendre les écrans plus attrayants et faciles à cliquer, j'ai converti les boutons radio en gros boutons, mais ils fonctionnent toujours comme des boutons radio en ce sens que lorsque vous cliquez sur un bouton "non", le bouton "oui" est désélectionné (et visa vice versa).
Serait-il intuitif de passer automatiquement à l'étape suivante lorsqu'un utilisateur clique sur "oui" ou "non"?
La complexité vient sur certaines des autres étapes où il y a jusqu'à trois questions avec trois ensembles de boutons "oui" et "non". Ainsi, dans ce contexte, l'utilisateur ne passera pas automatiquement à l'étape suivante en cliquant sur un bouton, sauf s'il ne procède qu'une fois qu'il a répondu (cliqué) sur tous les boutons requis.
Mon instinct dit que les "boutons radio" devraient fonctionner de manière cohérente tout au long du processus, mais il semble qu'un effort sera mis sur les utilisateurs pour les faire cliquer sur un bouton oui ou non, puis sur le bouton suivant pour passer à l'étape suivante lorsqu'il n'y a qu'une seule question avec un ensemble de boutons "oui" et "non".
Je pense également à ce qui se passerait si l'utilisateur voulait changer d'avis sur une réponse après avoir procédé, c'est pourquoi il y a un bouton de retour.
Voici un exemple de ce dont je parle:
Vous voulez que ce soit aussi simple que possible. La façon dont vous l'avez avec les boutons "Précédent" et "Suivant" nécessite une réflexion supplémentaire de la part de l'utilisateur comme vous l'avez compris ("pourquoi dois-je appuyer sur deux boutons pour chaque question - oui et suivant?")
Une solution possible à cela est de leur permettre de revenir directement aux questions précédentes s'ils veulent apporter un changement. De plus, comme ce ne sont que des questions O/N, vous pouvez afficher un résumé et la réponse aux questions précédentes sur le même écran, avec une option pour `` changer '' les réponses dans cette section s'ils le souhaitent. De cette façon, ils obtiennent une image complète de toutes les questions auxquelles ils ont répondu jusqu'à présent. Une fois qu'ils ont répondu à chaque question dans une section, vous pouvez ouvrir la section suivante pour l'action.
Le seul problème que vous pourriez avoir est de savoir si les autres questions dépendent des réponses que vous avez données aux questions précédentes - auquel cas le fait de sauter deux questions pourrait invalider la dernière question à laquelle vous avez répondu. De plus, si l'assistant est particulièrement long, cette approche pourrait être désordonnée (mais j'ai basé mon filaire sur l'hypothèse qu'il n'est pas si occupé en fonction de votre propre conception)
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Chaque fois que vous en tant que concepteur devez posez la question "Est-ce intuitif" ... ce n'est pas le cas. Restez intuitif, simple, utilisez les conventions existantes en votre faveur. Les utilisateurs connaissent la fonction des boutons radio. Ils sont une convention intuitive. Utilise les. N'ajoutez pas de confusion aux utilisateurs en réinventant la roue.
Je dirais non. Je m'attendrais à ce que le bouton "oui" apparaisse sur un formulaire demandant des détails par e-mail et, une fois cela fait, le bouton "suivant" passerait à l'étape suivante.
Cela dit, si vous devez demander des détails par e-mail dans un assistant, pourquoi ne pas simplement mettre le formulaire sur la page à l'avance avec une étiquette opt-in et juste avoir le bouton 'suivant' pour terminer la fonction?
Il pourrait lire "Veuillez m'envoyer des détails par e-mail, etc. etc ...." en dessous serait une zone de saisie de texte intitulée "Entrez l'adresse e-mail"
Cliquer sur suivant termine le processus, et s'ils ne le remplissent pas, c'est une demande tacite de "saut". Pas parfait mais beaucoup plus simple.
Je crains que la progression automatique de la réponse puisse causer plus de problèmes que non.
L'utilisateur a besoin d'une confirmation ferme de la réponse qu'il a sélectionnée. Il vous faudrait un délai entre le choix d'une réponse et l'affichage du Q. suivant pour garantir à l'utilisateur qu'il a fait une sélection. Le timing est crucial. Trop longtemps et ils commenceront à cliquer!
Les gens changent d'avis, discutent et font des erreurs. Les formulaires permettent généralement cela en permettant à l'utilisateur de choisir quand progresser. Est-ce que le fait d'être obligé de progresser dès qu'il répond répond à un jeu télévisé?
Vous ne pouvez pas vous tromper avec NEXT et PREV. C'est normal, existant et confirmant.
Vous pouvez enregistrer un clic, mais vous supposez légèrement que les utilisateurs sont très sûrs d'eux-mêmes et sont désespérés de passer au travers.
Je dirais non. Je pense qu'une case à cocher conviendrait parfaitement. Ce serait mieux, à mon avis, pour deux raisons:
- Il répond aux attentes des utilisateurs. Le fait que vous ayez posé cette question signifie que vous n'êtes pas sûr de savoir s'il est approprié de passer à l'écran suivant lorsque vous cliquez sur "Oui". Et je pense que votre intuition avait raison.
- Il vous permet d'offrir une valeur par défaut (par exemple, faites-la d'abord vérifier)
- Il est plus extensible. Si vous souhaitez ajouter plus d'options à l'avenir, vous pouvez les mettre sur le même écran.