Quel est le meilleur UX pour éviter 6 boutons et comment le rendre plus convivial?
scénario 1
Je travaille sur une application web financière. Dans l'application, les sections sont au niveau parent et les groupes sont enfants de ces sections. Lorsqu'un utilisateur au niveau parent peut voir tous les groupes. Je souhaite mapper ces groupes avec des catégories.
J'ai une icône après ce nom de groupe pour mapper avec des catégories. Je veux mapper un groupe à plusieurs catégories et plusieurs groupes à plusieurs catégories. Après avoir cliqué sur l'icône, je verrai cet écran (Image 1 et image 2)
scénario 2
Dans cet écran, j'ai "Groupes" et "Catégories" La couleur grise indique ma sélection pour le groupe; cliquer sur suivant sélectionne le groupe 4, cliquer sur précédent sélectionne le groupe 2, etc. Je peux sélectionner des catégories pour chaque groupe, et je peux ajouter une catégorie en cliquant sur le bouton ajouter. J'ai 3 boutons en pied de page:
- Enregistrer et précédent - Enregistrer et passer au groupe précédent
- Enregistrer et exister - Enregistrer et quitter cet écran
- Enregistrer et suivant - Enregistrer et passer au groupe suivant
Pour le scénario 1
- Quelle sera la manière élégante de mapper avec un groupe à une ou plusieurs catégories? Dois-je utiliser un groupe à la fois et mapper puis le groupe suivant? (Comme indiqué dans l'image 2)
Une meilleure suggestion pour ce scénario?
Comment dois-je apparaître sur l'en-tête pour tous les groupes? - Dois-je montrer tout le groupe comme titre ou doit explicitement terminer le flux.
Pour 2 scénarios
Je souhaite éviter un grand nombre de boutons, car les utilisateurs peuvent se sentir confus avec cette disposition.
Existe-t-il un meilleur UX pour cette conception?
Image 1 
J'ai modifié l'écran. Avez-vous une suggestion pour cet écran?
Image 2 
En règle générale, il n'y a rien de mal à beaucoup de "boutons". Un menu est essentiellement un tas de boutons avec une conception graphique différente. Il en va de même pour une banque de liens ou d'onglets. Ils font tous la même chose: naviguer ou exécuter une autre commande sur le contenu. Tant que vos "boutons" sont bien étiquetés, organisés et se distinguent les uns des autres, vous pouvez avoir des centaines sur la même page (si vous incluez des menus déroulants en tant que "boutons temporairement masqués").
Je pense que le problème que vous comprenez dans votre conception est un problème dans la partie "reconnaissable". Dans un souci d'action rapide en un seul clic (un objectif louable), vous offrez à vos utilisateurs plusieurs options avec des nuances subtiles de distinction, et c'est là que cela peut être déroutant. La solution consiste à décomposer vos fonctionnalités en fonctions plus discrètes sans chevauchement tout en minimisant les clics. Dans certains cas, cela signifie hiérarchiser vos fonctions, où de rares scénarios peuvent nécessiter deux clics ou plus.
Par exemple, quand un utilisateur voudrait-il cliquer sur Précédent par rapport à Enregistrer et Précédent? S'il n'y a pas eu de changements, ils sont en fait les mêmes (si l'enregistrement prend beaucoup de temps, donnez à l'application l'intelligence de ne sauvegarder que s'il y a eu des changements dans le groupe). Ainsi, le seul moment où vous pouvez cliquer sur Précédent par rapport à Enregistrer et Précédent est lorsque l'utilisateur souhaite ignorer les modifications apportées au groupe.
C'est un peu problématique, car rien dans "Précédent" ne dit "Ignorer les modifications". Si tel est le cas, certains utilisateurs peuvent supposer que les changements ne sont pas pas rejetés en naviguant simplement - ils peuvent s'attendre à ce que seule la fermeture de la fenêtre sans enregistrer annule les changements.
C’est aussi une fonction rarement nécessaire. Les utilisateurs ne font généralement pas d’erreurs. De plus, dans ce cas, si c'est le cas, il est relativement facile d'y remédier. S'ils cliquent sur une case à cocher et changent d'avis, ils cliquent simplement dessus. Vraisemblablement, il existe un bouton Supprimer pour chaque nouvelle catégorie créée, ce qui permet également d'annuler en un clic. Donc, la seule fois où les utilisateurs ont besoin de Previous est quand ils piquent vraiment les choses et ne se souviennent pas comment les régler correctement. C’est vraiment un cas Edge. Il est donc correct s'il faut plus d'un clic pour annuler les modifications et passer au groupe suivant ou précédent.
Vous pourriez avoir ceci, où enregistrer est implicite: 
Quitter, Précédent et Suivant tous les enregistrer. Si les tests d'utilisabilité suggèrent que les utilisateurs hésitent parce qu'ils pensent qu'Exit ne sauvegarde pas, envisagez d'étiqueter Exit comme "OK" ou peut-être "Soumettre", ce qui implique d'enregistrer et de quitter l'application/la page. Nommez-le uniquement "Enregistrer et Précédent/Suivant" si les tests montrent que les utilisateurs ont peur de perdre leur travail. Ma politique est d'ajouter de l'encombrement uniquement lorsque les tests montrent que c'est nécessaire.
Le bouton Réinitialiser ramène le groupe à ce qu'il était lorsque les utilisateurs sont arrivés au groupe au cas où ils gâcheraient irrémédiablement les choses. Cependant, étant donné la rareté réelle de ce bouton, envisagez de l'omettre. C'est une mine terrestre qui peut gâcher le travail de l'utilisateur en un seul faux clic. Ou mieux, faites-en un bouton Annuler qui annule les modifications du groupe un clic à la fois. Oui, il pourrait y avoir plusieurs clics pour réparer une grosse vis, mais c'est extrêmement rare.
Considérez ensuite vos boutons Précédent et Suivant eux-mêmes. Quel avantage ont-ils sur les utilisateurs qui cliquent sur l'étiquette de groupe eux-mêmes (représentés sous forme de liens ou d'onglets), comme le suggère maxathousand dans un commentaire? Cela donne à l'utilisateur un accès en un clic à n'importe quel groupe, pas seulement au précédent et au suivant. Le seul avantage d'inclure également Précédent et Suivant est que les utilisateurs parcourent souvent rapidement tous les groupes dans l'ordre pour les vérifier. Ensuite, Suivant (et peut-être Précédent) leur permet de le faire sans déplacer la souris. Si ce n'est pas une tâche courante, supprimez ces boutons: 
Cela ne répond pas vraiment à votre question, mais je pense que cela résout votre problème. Je laisse mon autre réponse pour répondre à la question plus générale des boutons dans une fenêtre multipage pour un utilitaire. Cependant, dans votre cas, vous ne voulez probablement pas du tout une fenêtre étant donné votre explication supplémentaire que:
L'utilisateur voit la liste du groupe puis après [chaque] nom de groupe, il y a une icône pour la catégorie de mappage. Lorsque je clique sur cette icône, cette fenêtre s'ouvrira.
Vous avez déjà une liste des groupes dans la fenêtre principale (parent). Il est probablement inutile de créer une boîte de dialogue qui reproduit la liste des groupes. Au lieu de cela, sélectionnez les catégories pour chaque groupe dans la liste que vous avez déjà dans la fenêtre principale. Si les utilisateurs souhaitent modifier les catégories de deux groupes différents, ils accèdent à des groupes différents dans le principal.
Deux modèles possibles:
Liste des cases à cocher des catégories avec chaque groupe dans la fenêtre principale
Si vous avez beaucoup d'espace dans la fenêtre principale, incluez les cases à cocher de catégorie pour chaque groupe dans la fenêtre principale. Désormais, l'utilisateur peut voir et modifier les catégories de tous les groupes en une seule fois sans boutons ni liens pour naviguer. Vous n'avez même pas besoin de l'icône.
Utilisez un bouton de menu avec basculement des éléments de menu
Cliquer sur l'icône n'ouvre pas une boîte de dialogue, mais affiche plutôt un menu déroulant avec des éléments de menu à bascule:
L'élément de menu "Ajouter une nouvelle catégorie…" ouvre une boîte de dialogue simple permettant à l'utilisateur de spécifier la nouvelle catégorie - et rien d'autre.
Cette conception permet à l'utilisateur de modifier une catégorie en seulement deux clics, car un menu se ferme lors de la sélection de l'élément de menu. Une boîte de dialogue prendrait trois clics pour ce faire car l'utilisateur doit fermer explicitement la boîte de dialogue. La modification de deux catégories pour un groupe avec un bouton de menu équivaut à quatre clics, ce qui correspond au même nombre de clics que la modification de deux catégories avec une boîte de dialogue. Une boîte de dialogue n'a d'avantage que si l'utilisateur doit changer trois catégories ou plus à la fois. Par exemple, changer trois catégories est 6 pour le bouton de menu et 5 pour la boîte de dialogue.
Mathématiquement, la conception des boutons de menu est en moyenne plus efficace que la conception des boîtes de dialogue si les utilisateurs sont beaucoup plus susceptibles de vouloir changer une catégorie à la fois pour un groupe, puis trois catégories ou plus à la fois pour un groupe. La recherche d'utilisateurs vous dira la réponse, mais je soupçonne que c'est le cas (par exemple, les utilisateurs changent 1 catégorie 50% du temps, deux catégories 25% du temps, trois 12,5%, etc.).
Je suppose que dans un sens, cela répond à votre question: pour avoir moins de boutons, pas de boîte de dialogue pour les mettre.
Que diriez-vous de faire une sauvegarde en arrière-plan après chaque vérification d'une case à cocher/ajout d'une catégorie.
Ensuite, il n'y a plus de concept de "sauvegarde", juste précédent, suivant et proche.
Vous pouvez même avoir une petite notification textuelle disant "modifications enregistrées" si les utilisateurs ne sont pas certains que les choses sont enregistrées.
Par exemple, avec Google Docs, vous n'avez jamais à enregistrer et il y a une notification par SMS.
Il y a pas mal de réponses similaires, par exemple regardez ceci excellente réponse d'une autre question UX.SE , ou celle-ci sur la sauvegarde automatique .