I'm working with a user who wants to have everything at a push of the button. When viewing a record, he wants big buttons across the top of the screen to return to the search, return to the search with filters, jump to a related record, return to the main screen, etc.

I try explaining that sometimes more buttons, especially wordy buttons, do not make things easier, but actually clutter the interface and makes things more difficult. That point doesn't seem to make sense to him, and working with a tablet-size web browser, I've reached my limit for buttons I can display in a single row. I really don't want to create two rows of buttons.

What's another way to present lots of options, but still keep everything "at the fingertips"? He didn't seem too receptive of a drop down menu, but perhaps a combination of buttons and menus, or another method would work better.

  • 5
    There's a big difference between making your site usable to new users and making it usable to expert users. If it's an administrative app that will be used very heavily (i.e., users will use the application for several hours every day), your client's preference may legitimately be more efficient than a dropdown, once the learning curve is surmounted. I recall reading a study several years ago where a phone system was replaced with a more usable system, only for the veteran users to have reduced performance that was irrecoverable due to extra clicks from the reduced clutter.
    – Brian
    Commented Aug 9, 2012 at 20:40

3 Answers 3


Adding to Brian's comment, if the site is available for new users, you should definitely try to tell your client that if he is giving you the job he should trust your criteria. But it's better if you use information and examples to support your choice.

I can think of three ways to deal with lots of navigation options that are immediately accessible (sort of).

Navigation bars with text instead of buttons:

enter image description here

enter image description here

Hover to show more options (if you are designing for iPad / iPhone you will have to think of an alternative, maybe always show them for mobile and hide them for desktop, using media queries):

enter image description here

Two levels of navigation, one for main (structural) buttons and one for quick links or something like that. Maybe clicking (or touching) on the main could show you the second level:

enter image description here

enter image description here

These last two would be my proposed option (specially the blue one). If you have all buttons looking the same, none of them will grab the user's attention. I'm sure there is a hierarchy (if not it's something you could talk to your client about) and that it can be expressed more easily. Hope it helps.

  • I like the last two options as well. Thanks for all the screenshots. Great answer!
    – dangowans
    Commented Aug 10, 2012 at 0:50
  • I'm working towards a navigation bar that will hopefully impress the user. We shall see.
    – dangowans
    Commented Aug 10, 2012 at 15:25

If it is unlikely that every single button is going to be used frequently, it may be possible to run a "frequent" button row and then a separate menu for other buttons which may be used less frequently.

You mentioned that you are working on a tablet-size web browser so you might be able to take some inspiration from the new Windows 8 start menu or also Facebook's mobile/touch site with a menu of links which slide from the side using a swipe gesture.

Drop down lists can sometimes be awkward to use with touchscreens and if a user wants to access information quickly, larger sized buttons may be to their advantage. However, for desktop sites, dropdown lists may be more appropriate.

  • Larger buttons are definitely being kept in mind. Thanks for the suggestions.
    – dangowans
    Commented Aug 10, 2012 at 0:52

All features more or less need a place to click to be launched. But restricting that clickable area to be toolbar buttons only, when there are so many great things to work with (using menus, dropdowns, split-buttons, checkboxes, navigation, pages, dialogs, context-menus, keyboard shortcuts, ...), would inevitably create a cluttered toolbar.

Exactly which buttons that will be used and which that should go away or become something else is indeed a difficult task to sort out to start with. And after a couple of releases with functionality added, I promise the toolbar can become a Frankenstien's Monster of functionality. You are doing yourself and your clients a favor never letting it. :)

You can never make a toolbar from where all tasks are done. Structure and navigation is key to not only keep "everything at your fingertips", but also keeping the UI "clear" (a thought on that on Google IO 10).

The toolbar in the top of a window/page is typically for actions that are frequent or applies to the state of the entire window/page. Other actions are more conveniently placed next to what they affect, and some do not fit on that page at all, but should be found when navigating away to another page/dialog/window, typically viewing a record or returning to the results, which have its own actions and toolbar.

It is hard to say what you could do without more information about your context and design so far, but based on the examples you provided about [return to search], a button on one page should inmho simply not manipulate the content on another. For minimum confusion, the action that applies to a content should visually be placed next to that content, so that the user can see what the button does when clicking it.

One of them must be the typical thing to do considering the work flow, and I guess that it is returning to the search results the way they were when we left them. The other option should be a click away from the search result list, not from the viewed record itself.

There is just so much a user can focus on, at a time, anyway.

  • Thanks for all the great interface suggestions. Hopefully I can use some of those to wrangle "Frankenstein's Monster". :)
    – dangowans
    Commented Aug 10, 2012 at 0:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.