Navigation dans les applications mobiles: retour ou annulation
Je conçois une application mobile dans laquelle il existe au moins un processus en plusieurs étapes. Tout au long de l'application, je veux que le bouton de retour signifie un pas en arrière, mais pas un niveau supérieur dans la hiérarchie des informations.
Pendant le processus en plusieurs étapes, je veux que l'utilisateur puisse sortir en un seul clic, ce qui signifie un bouton d'annulation avec un bouton de retour.
L'application aura un contenu présenté, un style Pinterest, et l'affichage de chaque élément de contenu n'est pas considéré comme un pas en avant dans un processus, mais un changement dans la hiérarchie des informations - c'est comme ramasser une carte sur la table et la lire - donc je veux donc le bouton qui annule la carte pour être le bouton d'annulation, pas de retour.
Afin de préserver la cohérence, cela signifie que je dois utiliser le bouton Annuler pour terminer le processus en plusieurs étapes (qui peut inclure la création d'un compte ou la création d'un nouvel élément de contenu).
Ma conception préférée est la version 2 où le bouton d'annulation est à gauche, mais lorsque vous êtes à un pas, il devient un bouton de retour et l'annulation le bouton se déplace vers la droite. Je veux savoir si les gens trouveraient ça choquant.
D'un autre côté, je n'aime pas l'idée qu'il n'y ait pas de bouton à gauche à la première étape (comme dans la version 1). Cela signifie également moins de précédents pour l'annulation sur la gauche, car ce serait l'annulation de l'affichage d'un élément de contenu.
Pensées?
Ce qui crée de la confusion i.m.o. est l'arrière et le bouton de fermeture étant au même niveau dans la hiérarchie visuelle où ils agissent à différents niveaux. Ne serait-il pas plus clair lorsque le bouton de fermeture est visuellement plus séparé du bouton de retour?
Je ne recommanderais pas de déplacer le bouton précédent/arrière et de le remplacer par un bouton de fermeture, car maintenant l'utilisateur ne peut plus faire confiance à sa mémoire musculaire. Vous pourriez envisager d'afficher un bouton suivant à côté du bouton précédent en donnant le contexte aux boutons et au processus.
Au lieu de flèches, vous pouvez également utiliser du texte, ce qui rend plus clair ce qui se passera lorsque l'utilisateur cliquera dessus.
Une toute autre idée est d'utiliser le bouton de retour natif sur Android pour que vous n'ayez pas à vous soucier de l'endroit où le placer. Mais maintenant je fais l'hypothèse (basée sur vos croquis) ) votre travail sur une application Android et je ne sais pas si c'est vraiment le cas.
Je vous encourage à vous demander si un bouton d'annulation est vraiment nécessaire dans cette situation.
- Quelle est la probabilité que l'utilisateur souhaite annuler l'intégralité de sa soumission?
- Est-il plus probable que l'utilisateur souhaite modifier des parties de la soumission plus facilement accessibles en utilisant la navigation arrière plutôt que la soumission entière?
- Une autre navigation à l'écran permettra-t-elle à l'utilisateur d'annuler efficacement son travail et de se retrouver dans un emplacement plus utile qu'une page de confirmation d'annulation?
Pour quelques réflexions intéressantes à ce sujet, voir https://www.nngroup.com/articles/reset-and-cancel-buttons/ .
Je trouve la deuxième version déroutante. Je pense que le même bouton doit être placé au même endroit dans les différents écrans.
Mais je dois dire que je trouve également la première option déroutante. Pour moi, le bouton de gauche doit revenir en arrière et le bouton de droite doit avancer. C'est peut-être une bonne idée de nous donner plus d'informations sur le reste des écrans.
Ma réponse ne s'applique qu'à Android, car je n'ai aucune expérience d'utilisation à long terme avec iOS.
Ajoutez des boutons de pas en avant et en arrière en bas (s'il s'agit d'un écran de type assistant), ajoutez également les points "pas" familiers en bas. Offrez des gestes de balayage pour avancer et reculer également.
S'il vous plaît, n'essayez pas de créer une solution générale pour Android et iOS! Cela finira toujours par être déroutant, en particulier le bouton Précédent me déroute toujours lorsque j'utilise un appareil iOS (ils se sont juste avérés qu'il était juste de le placer correctement) au coin où aucun de mes doigts ne peut atteindre facilement).
Je pense que c'est très confus d'avoir le bouton Retour et Annuler dans la même barre.
Je suggérerais d'ajouter une barre inférieure pour naviguer le long du suivant/précédent, afin que vous puissiez avoir un bouton d'annulation en haut de manière cohérente tout au long du processus.
Je vous suggère de conserver la version 1 car elle sera la même pour Android et IOS car comme nous le savons IOS doesn ' ne contient pas de bouton de retour afin que vous n'ayez pas besoin de changer la conception.
Et les gens ont une psychologie telle que le bouton de retour reste toujours dans la partie supérieure gauche car le concepteur majoritaire utilise cette norme.
Gardez donc la version 1. La version 2 prête à confusion.
Une troisième option consiste à utiliser un bouton avec une flèche vers la gauche et vers le haut (⬑) sur la position gauche dans la première étape de la version 1. Cela indique que cliquer sur ce bouton revient à un état précédent et que cet état aussi un pas en arrière dans la hiérarchie des informations.