“Make everything as simple as possible, but not simpler.”—Albert Einstein

Your smart phone would be simpler if it didn’t have a camera. But it would also be a lot less useful. A paint can is a sublimely simple way to store paint. But it’s a dreadful way to interact with paint: It’s hard to open, hard to close, and guaranteed to make a mess every time you pour it.

Simplicity is an obvious virtue, but it is not the ultimate virtue. Sure, the fewer clicks, taps, steps, hurdles, fields, distractions, and doodads in a UI, the better. We UX designers have a whole bag of tricks for simplifying things—consolidating here, eliminating there, shrinking this, submerging that—and 19 times out of 20, the simpler approach is the better approach.

But, ahhh, that twentieth time. In our enthusiasm for making elements, widgets, and products simple, we need to avoid overshooting the target, making them too simple to serve their purpose well. For example:

  • An icon without any words attached to it is nice, simple, and clean. It avoids translation problems, but simultaneously runs a high risk of being incomprehensible in many languages.
  • The ubiquitous USB plug fits into a port only if you have the top on top. But since both plug and port are simple rectangles, most people can’t tell top from bottom. You have to examine both closely and compare them carefully to get the top on top. Most people don’t, so we routinely need two or more tries to get the damn thing plugged in. If the mating parts were just slightly more complex—say, shaped like a D or an obtuse isosceles triangle, or with a conspicuous dot always marking the top of both plug and port—we would struggle with USB plugs much less.
  • A mobile app that depends on users somehow knowing specialized gestures to navigate has the luxury of presenting a wonderfully simple interface, but a high percentage of users will give up on it before ever stumbling upon those secret handshakes.
  • There was an early mobile app that consisted simply of the complete text of the King James Bible—all 750,000+ words of it—with no pesky navigation or search functionality to clutter up the UI (uhhh, I mean, to enable you to find anything). You were left to just scroll and scroll and scroll and …
  • There is a service (which shall remain nameless) that syncs up your files on multiple devices. It's designed to automatically and instantly delete a file everywhere if you delete it anywhere. Nice and simple: everything always in sync. And to keep things really simple, there is no warning, no “Are you sure?” and no undo. But 20% of its users view the service as a means of backing up their files. They are in for a nasty surprise when they discover later that their “backup” copy in the cloud has vanished just as soon as any instance of it anywhere else gets deleted, even if that deletion was an accident.
  • Many country selector dropdowns consist of a simple list of the world’s 190+ countries in alphabetical order. But such a simple widget will inconvenience every user except those in countries at the top of the alpha list. And chances are most of your users are not in Afghanistan, Albania, or Algeria.

So, yeah, making something too simple can be as problematic as making it too complex, just as making a room too cold can be as uncomfortable as making it too hot.

Scratching the Itch

Simplicity is a one-to-one match between an itch and a scratch. Fine-turning the scratch to the itch usually does mean subtracting, but not always. Sometimes it means a small addition, such as asking users whether they want that file deleted everywhere. To hit the appropriate level of simplicity, we need clarity about exactly what itch we’re trying to scratch.

The goal is not simplicity for its own sake. Simplicity is only a means to an end. The goal is ease. We can admire simplicity as a characteristic, but ease is what we want users to experience.

The goal is not simplicity for its own sake. Simplicity is only a means to an end. The goal is ease.

“Keep it simple” is a great rule of thumb but a poor reflex ideology, because of all the times it shames us into putting simplicity ahead of ease. Naturally, we want both, and they do tend to go together. But we sometimes have to lessen one to achieve the other. When we do, ease should win. As long as the result is to make the thing easier to use and to satisfy users’ actual needs, mission accomplished.

When Brevity Attacks

A prime way we simplify is to reduce verbiage. And sure, all things being equal, the fewer words or elements it takes to communicate something, the better. But all things are not always equal. Like making a room too cold, we sometimes overdo brevity, creating more problems than we solve. Better to use a little more verbiage to communicate clearly than to puzzle users with something concise but cryptic. Consider:

More consice vs. More clear table

Concise action button verbiage is a particularly sacred cow. You can’t get much more concise than the standard “OK” and “Cancel.” The word “OK” itself is pristinely simple, but that simplicity comes at a price: additional effort and occasional grief. To know what you are consenting to in a dialog box, for example, you have to go to the trouble of reading the rest of the dialog. Users often don’t, so they sometimes suffer by clicking “OK” with regards to things they did not intend to. To spare them a bit of effort and grief, a self-explanatory button is more helpful than a concise button. That tends to mean a tad more verbiage.

Here’s an example of how our well-meaning insistence on bare-minimum button wording can sometimes do more harm than good:

Leave Meeting button

Making the buttons self-explanatory (though less concise) can actually streamline the whole dialogue:

Leave Meeting button

Is this not simpler than the original?

Bottom line: Simplicity is good. Ease is better. Brevity is good. Clarity is better. What are some of your favorite examples of clarity and ease in design? Share your examples in the comments below.


Image of single cell organisms courtesy Shutterstock.

Article No. 970 | March 5, 2013
Article No. 991 | April 2, 2013
Article No. 1 193 | February 24, 2014

Add new comment


This article is very interesting.  Nevertheless I think to have the best label for the best user response and to use affirmative sentence I would rather use : 

Do you want to leave the meeting ? For title and 

"Stay" and "Leave" button.

So I will be concise and explicit and my wording has different shape that will help the user to answer.

As a User Research Associate, I give a hearty "hear, hear!" to this article. Users do not typically read dialogue boxes. Short descriptive button text contained within a dialogue box is more effective than the entire dialogue text. 

I disagree with the comment where the Yes or No is yet simpler.  You neglect to realize the author's intent on indicating the action must be associated to some context -- regardless of how simple the context is.  You have to read the dialog to know what you are clicking "Yes" to.  You don't have to read the dialog when clicking the "Leave Meeting" button and as a consquence the ease is improved by the later.

If you don't need to read the dialog, and only the buttons, then what is the point of the dialog in the first place?

The dialog is the context for your next action, which, in my example that improves the authors, is “Leave the Meeting?” Yes | No. The text of the dialog explains why it’s interrupting you, and then it gives you the natural answers to choose from.

The dialog text is important. It’s a question - “are you sure you want to do this?”

The dialog text is the first thing people would read, because it’s the reason for this interruption. And a simple Yes or No are the natural answers.

The author, John Boykin, and you presuppose that the answer to the question ’Leave the Meeting?’ are ‘Don’t Leave’ or ’Leave Meeting’. Now that is just not a natural dialog, it’s very machine-like, and shows a lack of understanding of people - which is the core of UX.

The process here is that you click a button in the main UI because you want to leave a meeting, so a message pops up to ask you if you really want to the Leave the Meeting in case it was an accident. Your answer would naturally be ‘Yes’ or ‘No’, not ‘Don’t Leave’ or ‘Leave Meeting’ as the author proposes. Also, it’s NOT a case of the text on the buttons being sufficient enough as the dialog text doesn’t need to be read - the user will read the dialog text first and foremost because this is a dialog with the user, the reason for the interruption. You will always read the dialog reason first, and I challenge you to tell me why any regualr person would simply ignore the dialog and head straight for the buttons and click one (and therefore not know the context of their actions).

Leave the Meeting? Yes or No. That is the most natural and simplest dialog. Not ‘Leave the Meeting?’ Leave Meeting. How robotic is that? And who only reads the buttons and not the dialog first?

Let me better describe my remark and hopefully provide a more convincing explanation.

There is more ease of use when the description of the action is attached to the object of interaction rather than an interaction being simply an affirmation or declination of an action described elsewhere.

The example provided by the author works, but I agree with you the description and action are so simple the repeated action description on the button lean slightly on the redundant side as you noted. Let me provide better examples:

"Do you accept the terms and conditions of this site?" I accept / Cancel

"Do you want to install this unsecure software? Installing insecure software potentially may have malware harming your computer and is not recommended."

Install / Don't Install

Using Yes and No for each, while they work, there is a slight effort on the user to double check what he's saying yes to or not. While this check may seem automatic it's still a check which occurs. In the case it's not automatic, the reader may have to go back and check. Did the message asking me to install or not install?

Why does effort occur? The more descriptive or lengthy the dialog the more blurred is the line connectiing a "Yes or No" action to the actual description the "Yes or No" is being applied to and hence the less ease a user has in selecting either. There is a subtle pause the user must make to re verify what the yes or no means. This pause, even milliseconds, is avoided by simply attaching the description of the action onto the object of interaction.

If you are still unconvinced then compare these tree options to the install question:

(A) Yes / No

(B) Yes, Install / No, Cancel

(C) Install / Cancel

Clearly B sounds better than A wouldn't you say? The removal of yes and no from B is just a simplification as it's optional in the presence of the action description Leaving you with (C)

Yes | No is an answer to certain questions, and obviously not to all questions. Bringing up examples where Yes | No is not applicable does not apply to the particular example that we are discussing.

Does 'Leave the Meeting?' require a 'Leave Meeting' 'Don't Leave' answer, or a more natural Yes or No.

You should understand people first, rather than textbooks. I can tell that you're one of those UX guys that follows rules rather than understand people

The last paragraph here is the key to success.  I would say many very valuable guidelines, as opposed to rules have been discussed here, but we must apply a level of common sense and that human factor to the problem.  That is the whole point in my opinion.  Rules will lead you to a design that is not user friendly.  Applying the human touch, that cannot always be clearly defined, not least because it is heavily dependent on context, will take you to your goal. As an aside, I found it interesting/ironic, that there is a lack of simplictity, brevity and clarity in some of the comments here - my own included!

Hi John,

Sounds like you are ofended.  I'm not sure if you realized but I actually agreed with you in my last remark.  I do not believe I made the statement Yes | No should never be used nor did I imply avoiding them by providing alternative examples geared towards conveying the author's intent.  I'm at ease your remarks awknowledge obviousness there are questions where this technique is applicable as that was the intent.

Agree absolutely. One thought that comes to mind is browser scroll bars. Way back when, the scroll bar was always visible so you could quickly gage the amount of content on a page. To simplify/beautify the browser UI the scroll bar is only visible when activated, meaning that some users are not aware that there is content below the fold. Or how lenghty a page is at a glance.

Interesting article, but both the options you give in Leave the Meeting box are unnecessarily complicated, a third, and the most clear option would be:

Leave the Meeting?
No | Yes

No extra dialogue and no lengthy button text

Can the downvoters explain their position? Also, how about a reply from the author? It seems you're complicating simplicity there mate