Saving Button Clicks
I’m totally willing to admit it: Google is the king of saving button clicks.
Sure, clicking a mouse button is a pretty simple act so it’s not like you are saving the rain forest by designing something that doesn’t require a button click, but there is something special about preventing unnecessary effort in running an application. So if it is such a small thing, why bother with it? It shows that a little bit more thought went into the design. It makes it just that much better.
Let’s take a look at one of the most frequently used and streamlined user interfaces out there:
What is it? A text box and two buttons. What makes it so special? Well, it’s what you don’t see: as soon as you start typing something in, it makes a suggestion. You don’t even have to click anything to start searching. Now you’ve potentially saved the user a button click. The flow would go something like this:
- User opens up browser, goes to http://www.google.com.
- User clicks into the text box, begins typing.
- As the user types, the page actually switches to the search results. No need to click on the search button.
This workflow saves not only a button click, but saves a user from having to switch his or her hands from the keyboard to the mouse, and a click. Let’s look at a not-so-great example:
(This comes from a fairly large application, and is only part of a given screen).
On the top is a series of buttons in a menu bar that allow a user to display a list of users who’s last name start with that letter. In the middle is the list of matching users, and in the bottom is a search box. Now there are several things that aren’t clear here. For one, you have to know how a menu bar works in order to find any users who’s last name ends in anything after the letter P. Then you also have the issue of finding a particular user within that list. If there are 30 different users with the last name of “Smith”, you will have to do some digging. And then there is the stray search bar at the bottom of the list. It isn’t particularly clear – is the search box only searching the current list or is it searching all the users? Why isn’t the search bar at the top? I don’t know. Luckily, I wasn’t the one responsible for this abomination of a dialog. Let’s look at the work flow for a user who is searching for the user “John Smith”:
User opens the dialog. User does one of the two following things:
- Clicks the down arrow on the end of the menu bar, then clicks the letter S. The user then scrolls to the correct part of the list, and selects the item in the list.
- Clicks into the search box, and starts typing “smith”. When all the “smith” users are shown, the user scrolls through the list to find “John”, and selects him.
Both of these work flows are horribly inefficient. Either you have to click, click, scroll, click or click, type, scroll, click. Why was it done this way? I suspect the developer who wrote it either had the search box as an afterthought or wasn’t quite sure how to write a proper search function.
Saving button clicks doesn’t apply to just searching – it applies everywhere. There is a huge amount of effort (or at least there ought to be!) that goes into making user interfaces that require as little work as possible to navigate. Once again, I have to hand it to Google – they really do know how to save button clicks.
If you are in charge of designing a user interface, please do me (and the poor folks using it) a favor – design it to take as little input from the user as possible.