What is best UX to avoid 6 buttons and how to make it more user friendly?

Question

scenario 1

• I am working on a Financial web application. In application, Sections are parent level and groups are child of those sections. When user at parent level user can see all groups. I want to map those group(s) with category(s).

  I have icon after that group name to map with categories. I want to map one group to many categories and many groups to many categories. After clicking on the icon, I will see this screen(Image 1 and image 2)

scenario 2

• In this screen I have "Groups" and "Categories" Grey color indicates my selection for the group; clicking next selects Group 4, clicking previous selects Group 2, etc. I can select categories for each group, and I can a add category by clicking on the add button. I have 3 buttons at the footer:

  • Save and Previous - Save and go to previous group
  • Save and Exist - Save and exit from this screen
  • Save and Next - Save and go to next group

For scenario 1

• What will be elegant way to map with group to category(s)? Should i use one group at time and mapping then next group?(as shown in the image 2)

Any better suggestion for this scenario ?

How should i show on header for all groups ? - Should i show all group as title or explicitly has to completed flow.

For 2 scenario

• I want to avoid a large number of buttons, as users may feel confused with this layout.

• Is there a better UX for this design?

Image 1

I have modified screen. Do you have any suggestion for that screen ?

Image 2

Answer 1

As a general principle, there’s nothing wrong with a lot of “buttons.” A menu is basically a whole lot of buttons with different graphic design. So is a bank of links or tabs. They all do the same things –navigate or do some other command on the content. As long as your “buttons” are well labeled, organized, and distinguishable from each other, you can have 100s on the same page (if you include pulldown menus as just “temporarily hidden buttons”).

I think the issue you’re intuiting in your design is a problem in the “distinguishable” part. For the sake of speedy one-click action (a laudable goal), you’re giving your users multiple options with subtle shades of distinction, and that’s where it can get confusing. The solution is to break down your functionality into more discrete non-overlapping functions while still minimizing clicks. In some cases, it means prioritizing your functions, where rare scenarios may need a two or more clicks.

For example, when would a user want to click Previous vs. Save and Previous? If there were no changes, they are effectively the same (if saving takes a long time, then give the app the intelligence to only save if there were changes to the group). So the only time to click Previous versus Save and Previous is when the user wants to discard changes to the group.

That’s a bit problematic, because there is nothing about “Previous” that says “Discard Changes.” If fact, some users may assume changes are not discarded by merely navigating –they may expect that only closing the window without saving would discard changes.

It’s also a rarely needed function. Users usually don’t make mistakes. Furthermore, in this case, if they do, it’s relatively easy to remedy. If they click a check box and change their minds, they just click it back. Presumably there is a Delete button for every new category created, so that also has one-click undo. So the only time the users need Previous is when they really louse things up and can’t remember how to set it right. That’s really an edge case. So it’s okay if it takes more than a click to discard changes and move to the next or previous group.

You could have this, where save is implicit:

Exit, Previous and Next all save. If usability testing suggest users hesitate because they think Exit doesn't save, then consider labeling Exit as "OK" or maybe "Submit," which imply saving and leaving the app/page. Only label it "Save and Previous/Next" if testing shows users are afraid of losing work. My policy is add clutter only when testing shows it's necessary.

The Reset button reverts the group to what it was when the users arrived at the group in case they irreparably mess things up. However, given how rarely they’ll actually need this button, consider omitting it. It’s a land mine that can throw away the user’s work with one false click. Or better, make it an Undo button that reverts changes to the group one click at a time. Yes, it could be many clicks to fix a big screw up, but that’s exceedingly rare.

Next consider your Previous and Next buttons themselves. What advantage do they have over the users clicking the group label themselves (represented as links or tabs), as maxathousand suggests in a comment? That gives the user one-click access to any group, not just the previous and next one. The only advantage to also including Previous and Next is if users often page quickly through all groups in sequence to check them. Then Next (and maybe Previous) allows them to do so without moving the mouse. If that isn’t a common task, delete those buttons:

Answer 2

How about doing a background save after each check of a checkbox / adding a category.

Then there is no concept of 'save' anymore, just previous, next and close.

You can even have a small text notification saying 'changes saved' if users aren't certain that things are being saved.

For example with Google Docs you never have to save and there is a text notification.

There's quite a few similar answers, e.g. look at this excellent answer from another UX.SE question, or this one on auto-saving.

Answer 3

This doesn’t really answer your question, but I think it solves your problem. I’ll leave my other answer up to address the more general question of buttons in a multipage window for a utility. However, in your case, you probably don’t want a window at all given your added explanation that:

User see list of group then after [each] group name, there is icon for mapping category. When I click on that icon then this pop up will open.

You already have a list of the groups on primary (parent) window. It’s likely unnecessary complexity to make a dialog that reproduces the group list. Instead, select the categories for each group from the list you already have in the primary window. If users want to change the categories for two different groups, they go to different groups in the primary.

Two possible designs:

List categories check boxes with each group in the primary window

If you have plenty of space in the primary window then include the category check boxes for each group in the primary window. Now the user can see and change the categories for any groups all at once with no buttons or links to navigate. You don’t even need the icon.

Use a menu button with toggling menu items

Clicking the icon doesn’t open a dialog, but instead shows a pulldown menu with toggling menu items:

The “Add New Category…” menu item opens a simple dialog for the user to specify the new category –and nothing else.

This design allows the user to change a category with just two clicks since a menu closes on selection of the menu item. A dialog would take three clicks to do this because the user has to explicitly close the dialog. Changing two categories for a group with a menu button is four clicks, which is the same number of clicks as changing two categories with a dialog. A dialog only has an advantage if the user needs to change three or more categories at once. For example, changing three categories is 6 for the menu button, and 5 for the dialog.

Mathematically, then, the menu button design is on average more efficient than the dialog design if users are substantially more likely to want to change one category at a time for a group then three or more categories at a time for a group. User research will tell you the answer, but I suspect that is the case (e.g., users change 1 category 50% of the time, two categories 25% of the time, three 12.5%, and so on).

I guess in a sense this does answer your question: to have fewer buttons, don’t have a dialog to put them on.