Standardisation des boutons Précédent / Suivant / Annuler / Réserver à différentes étapes sur un formulaire de type assistant
J'ai un petit dilemme ici.
Alors que l'utilisateur parcourt les différents écrans de mon assistant de réservation ci-dessous, je m'inquiète un peu des boutons en bas de l'écran, comment puis-je standardiser ou ajouter une certaine cohérence aux boutons de chaque écran.
Par exemple, l'utilisateur devrait pouvoir annuler la réservation à tout moment, mais au moment où il ne peut annuler la réservation qu'à la troisième étape.
Pouvez-vous suggérer des améliorations que je peux apporter?
Notez qu'à la 3ème étape - appuyer sur l'icône crayon permet à l'utilisateur de passer à l'une ou l'autre étape 1/2 pour effectuer les changements nécessaires.
En outre, vous remarquerez peut-être que j'ai gardé la barre d'onglets en bas, un autre problème qui m'inquiète est qu'un utilisateur puisse appuyer par inadvertance sur une icône et abandonner involontairement son processus de réservation. En général, les formulaires de paiement/réservation peuvent être des expériences ciblées, dois-je donc supprimer la barre d'onglets de l'application en bas? Comment cela changerait-il le formulaire de style de l'assistant?
Mon conseil simple serait de déplacer ou même de supprimer le bouton d'annulation.
Dans son état actuel, l'utilisateur cliquera sur annuler au lieu de précédent dans certains cas et on ne peut pas se fier aux différences de couleur pour résoudre ce problème.
Vous pouvez placer le lien d'annulation à un endroit cohérent sur tous les écrans et le rendre cohérent avec les autres opérations de canel d'application. Vous pouvez également enregistrer une réservation comme `` non confirmée '' et la considérer comme annulée si l'utilisateur s'éloigne (y compris accidentellement ~), mais laissez-le recharger et le confirmer, puis fournissez une opération `` d'annulation '' distincte uniquement pour les réservations confirmées.
Il y a un certain mérite à faire en sorte que les étapes d'interaction de l'opération d'annulation diffèrent des étapes d'interaction générales si l'opération est critique et nécessite une réflexion à chaque fois. Regarder comment les iphones gèrent la suppression de choses pourrait vous aider avec des idées.
~ ajouté en réponse à la modification de la question
OMI, un flux d'assistant devrait faire apparaître une nouvelle tâche modale. La tâche peut être terminée ou annulée. La "barre d'onglets" en bas est une distraction pour la tâche de réservation et doit être supprimée.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Personnellement, j'aime la barre d'onglets de l'application en bas, alors voici comment je changerais les choses tout en la gardant toujours visible.
Tout d'abord, lors du démarrage d'une opération de réservation, j'obscurcirais entièrement la rangée du bas, puis mettrais légèrement en surbrillance la réservation. Cela fournit un petit retour supplémentaire sur le fait qu'ils sont en train de réserver, tout en faisant savoir à l'utilisateur que les trois autres options ne sont pas des actions qu'il peut actuellement entreprendre. J'envisagerais également de faire une deuxième pression sur la réservation comme une opération d'annulation. Vous devrez peser les compromis entre l'annulation accidentelle d'une tentative de réservation légitime et un moyen rapide d'annuler la réservation s'ils ont accidentellement commencé cette opération.
Deuxièmement, je n'aime pas la façon dont Annuler et Précédent apparaissent et disparaissent en fonction de la partie de l'opération dans laquelle vous vous trouvez. Les crayons sont un excellent raccourci, mais quelqu'un qui vient de cliquer sur Suivant et s'est immédiatement rendu compte qu'il fallait apporter une modification est va cliquer où le bouton précédent était juste et être confus. Ma suggestion serait de toujours afficher Précédent et Suivant (le cas échéant!), Puis de placer un bouton d'annulation de style rouge-X dans le coin supérieur droit de l'application dans la même zone où le livre apparaît.