My quick answer: There isn’t one…so you shouldn’t try too hard to make one.
If it’s an icon, then it’s worth up to three words—at best! The oft-cited cliché is very misleading because icons are a very poor way to communicate. With the exception of well known standard icons, people understand text labels much faster than icons.
The ribbon UI, introduced by Microsoft Office 12, is much easier to understand and use than traditional toolbars primarily because it takes extra space to give nearly every command an explicit label. (The exceptions in Word: Fonts, Paragraph, Quick launch are unlabeled.) Office also uses many preview-based graphics (such as Styles that preview the effect of the style), but those are really thumbnails not icons.
Don’t believe that icons are a poor way to communicate? Take the “icon challenge” by removing all command labels and seeing if you can correctly determine what the commands do based on the icon alone. For example, try to figure out the labels for the Insert tab in Word:
When I tried this, I scored only 10 out of 24 for this ribbon tab. Keep in mind that Word is a familiar program and Office uses excellent iconography, so I would expect the typical score to be even lower.
BTW: I recommended using this approach to evaluate your product’s icons.
If icons are so poor at communicating, why bother with them? First, I should reiterate that well known standard icons communicate their 1 – 3 words quite effectively. It’s the not well known, non-standard icons—the ones that require time and thought to figure out—that are the ones in question.
Such icons have value not because they communicate their purpose well, but because they help users recognize and distinguish commands visually. It’s all about efficient visual recognition. So while users understand text labels quickly, they can recognize and distinguish between icons faster still. For example, users might remember that the command they are looking for has a globe on it and locate it immediately, even though they might not know what the globe means. When there are many commands (as on a typical ribbon), the icon + label combination works well because the icon enables quick visual recognition and the text label enables quick comprehension.
Efficient recognition is extremely valuable—just keep in mind that it’s no substitute for comprehension. If your target user’s comprehension of your icons is low, it’s likely that you need to reconsider your labeling strategy more than the icon design itself.
The user’s ability to understand an icon is primarily determined by the icon type. The follow icon types are usually easy to understand:
Standard and simple works well. This list reveals an interesting challenge to icon design: Icons are pictures, and pictures show nouns. Yet, icons are used to represent commands, and commands are usually verbs. Consequently, most icons boil down to a noun representing or doing the verb.
The following icon types are moderately difficult to understand:
Metonyms and synecdoche are related to metaphors, but I listed them explicitly because, contrary to popular belief, metaphors aren’t the only game in town. Using a fork on a map to represent a restaurant is a synecdoche, not a metaphor. Again, simplicity and familiarity is the key to success here. For example, a star is a successful metonym for “favorite” because people often rate things they like using stars.
The following icon types are difficult to understand:
Going back to my original question, “fidelity” is an abstract concept, so it’s very difficult (I would argue, impossible) to create an understandable icon to represent it. One could try: Dogs are known for having fidelity to their masters, but a dog icon is far more likely to be interpreted literally.
In addition to type, context plays an important role by allowing users to easily deduce meaning. For example, a zebra icon (an unfamiliar noun, icon-wise) is meaningless out of context, but in the context of monkey, turtle, bird, and snake icons, a zebra most likely represents savanna animals.
I have a couple laws for icon design:
The longer it takes to come up with an idea for an icon, the less comprehensible the icon is going to be.
If an icon requires a tooltip to understand, it’s not comprehensible. At best, using it helps recognition.
If you’re wracking your brain trying to come up with an idea for a good icon, most likely it’s because there isn’t one. Once you’ve made this realization (and you really must have an icon), better to focus on the recognition consolation prize.
Consider the following, in priority order:
Given the challenge and expense of creating meaningful icons, it’s important to reuse icons whenever appropriate (as opposed to creating new ones). To reinforce their meaning (instead of diluting it), choose preexisting icons based on their meaning, not their appearance. If a design detail has a different meaning, use another design. So, use scissors to mean Cut, not Office supplies; use binoculars to mean Find, not Zoom; use a gleam overlay to mean New, not Glossy.
To show how inconsistent reuse can dilute meaning, consider the ‘x’ overlay. Currently, there’s no consistency at all, either in terms of meaning (does it mean delete, error, cancel, close, exit, stop, clear, disconnected, or not available?) or presentation (red, black, or while; normal vs. script; alone vs. within a circle). Consequently, you can’t be sure of its meaning based on the design alone—all you know is that the overlay indicates a state that isn’t positive. (BTW: The design community should fix this: Delete should always be a black, script x (never red!); Error should always be a red, normal x; etc.)
Bottom line: To preserve meaning, these design details aren’t arbitrary choices.
If you do only one thing:
Reconsider the need for icons. While icons are helpful for comprehension and recognition, users’ ability to comprehend icons is vastly overrated. Consequently, prefer icons that are standard, simple, and familiar. With the exception of well-known, standard icons, label all icons either in-place or with a tooltip. If you really need custom icons, use an icon design specialist.
I stumbled upon Never Use a Warning When you Mean Undo by Aza Raskin the other day (and to clarify, what Aza calls a warning, I call a confirmation where users are explicitly asked to proceed with a task they initiated.) Aza’s basic point is that confirmations are often used when an undo feature would be more appropriate. While true, this isn’t always the best solution (even if Undo were always possible), and what’s more, this is only part of the story. In this post, I’ll tell the whole story.
When making a design decision, it’s good to think about alternative designs as Aza suggests here. However, a more fundamental design principle to consider first is the need for effective communication. A user interface is a conversation between the user and your product’s underlying technology. A UI is good only if that communication feels natural, friendly, and efficient. Effective communication is the universal design principle that spans the popular UI design books, from Don Norman’s The Design of Everyday Things, to Steve Krug’s Don’t Make Me Think, to Edward Tufte’s books on visual communication. Effective communication is essential to the design of all UI elements, including task flow, text, use of controls, layout, animation, color—even icons and graphics.
Imagine a situation where everything you did was confirmed based on the possibility—however small—that you might not intend to proceed with what you were doing. Some UIs feel like this, so you don’t have to imagine too hard. In this situation, you quickly become habituated to the extra step and proceed without giving the confirmation any thought. Not only would such confirmations not achieve their intended goal of reducing error, but they actually increase error because any necessary confirmations would no longer stand out. Confirming would be a pointless ritual, much like the “Final answer” routine in Who Wants to Be a Millionaire.
So what makes a confirmation necessary? The mere possibility of making a mistake isn’t sufficient. There are three basic patterns where confirmations are warranted:
Given these basic patterns, a confirmation is necessary when there is a strong reason not to proceed. An effective confirmation is essentially trying to talk the user out of proceeding and there is a significant chance that the user might decide not to. Another important implication: confirmations should be rarely needed—a well designed system shouldn’t have many actions that are risky or have unintended consequences.
Confirmations tend to be abused because they are easy to implement. They also provide an element of safety—for the designer—because they transfer the liability of a mistake from the software to the user (the logic: we asked you and you said “yes,” so if you aren’t happy it’s your fault.)
But neither of these are a good reason to use a confirmation and often there is a better alternative:
The answer is never No, so don’t bother asking.
I could give many more examples for each of these alternatives, but the bottom line is that it should be difficult to lose work or make significant mistakes in a well designed product. When evaluating a task flow, at each step ask yourself “What mistakes might the user make and how does the design prevent them or reduce their impact?”
A good confirmation main instruction must require thought. Remember, the entire point of an effective confirmation is to give the user a reason not to proceed, so that reason should be clear. (Making the generic “Are you sure?” confirmation clearly pointless.) The risk of the action or the unintended consequence should be extremely clear.
A general rule: whenever you ask the user a question, you provide all the information required to provide an informed answer. Be sure to give specific risks, object names, contexts, etc. required to respond in the confirmation itself.
Ordinarily, a good dialog box is designed for efficient decision making, where users can often respond without reading anything but the response buttons.
While this works well in general, the entire point of a confirmation is to get the user to stop and think about whether or not to proceed. (If proceeding requires no thought, don’t confirm!) There are two facts about user behavior that we need to work with here:
Given these facts, there are three ways we can write the response button labels to create a mental speed bump:
The Save vs. Don’t save labels tell you everything you need to know.
I forgot to mention the top problem with unnecessary confirmations—they’re annoying! When users are frustrated by unnecessary confirmations, all too often the “solution” is to add a “Don’t show this message again” option. Adding this option is a clear sign that the confirmation is unnecessary, because it makes no sense to add this option for a necessary confirmation.
While this is better than always confirming, it’s worse than never asking or asking just once. So while many people like this option, I don’t. All it does is show me that the designer tried to weasel out of making the hard design decision. (To be clear: sometimes using this option is a good idea, but those situations are fairly rare.)
If you do only one thing:
Present a confirmation only if there is a solid reason to not proceed. If there is a reason to not proceed, make that reason obvious, provide all the information required to make a good decision, and design the response buttons to encourage users to read the main instruction. If a confirmation isn’t necessary, do the right thing and remove it.
“For every complex problem, there is a solution that is simple, neat, and wrong” —HL Mencken
At the typical design review, there will be a variety of feedback. Some of it will be obviously brilliant and right on target. Some of it will be OK and require some mulling over. Then there will be some that is just plain bizarre. You are amazed that this otherwise intelligent person is giving you this feedback, and you’re even more amazed at how adamant they are in presenting it.
Over the years, I’ve found that all feedback is ultimately good, but some is just poorly presented. Even the poorly presented feedback is good because you will eventually discover that there is a valid problem behind it. Chances are, the reason the feedback is poorly presented is that the person is identifying a solution—often a really poor solution—to an unstated problem instead of giving you the problem directly.
I like to call this situation UX Design Jeopardy! because it resembles the TV game show. Just as in Jeopardy! you have to respond in the form of a question, in UX Design Jeopardy! you are given a design problem in the form of a poor solution.
This problem happens because sometimes people find it easier to articulate ideas in terms of solutions instead of problems. This is especially true for non-designers. It might be because they don’t even know the problem or even realize the problem—rather they’re just thinking in terms of the solution that is simple, neat, and wrong. “Make the logo bigger” may be a poor solution, where “this design doesn’t reflect our brand” may be a valid problem.
People tend to fall in love with the first idea that comes into their heads. While this problem is well known during the design phase, it happens during feedback and other phases as well. And it’s way to easy to focus on how the solution solves the problem without thinking through the larger consequences.
Adding to the problem is that culturally, we tend to believe that people who offer solutions are more sophisticated than those who identify problems. Anybody can find problems, right? And finally, people who give feedback in terms of solutions might be showing off a little—they want everyone know that they too know how to design stuff.
The problem is that any debate over an obviously bad solution is a waste of time. Worse, such debates can get rather emotional. The person giving the feedback is thinking “Why doesn’t this person get it? Why can’t they just accept my feedback and move on?” But the person receiving this feedback is thinking “Why are they so focused on this idiotic idea? Why can’t they just let it go?” Once you get past this, the emotional charge may make the rest of the feedback process less productive.
The solution is to recognize when you are in this situation as quickly as possible. Instead of debating the merits of a bad solution, get right to the problem by asking:
“What specific problem are you trying to solve?”
That usually that does the trick. Now you can understand the real problem, document it, and move on.
However, this question might not help if the person just can’t articulate the problem. In this case, a good approach is to ask the person provide examples:
“I’d like to understand your feedback better. Can you give me specific examples of where the product would benefit from this solution?”
“Can you give me examples of other good experiences that benefit from this solution?”
This helps because people can often express their ideas easier using examples. Hopefully, you can then use those examples to determine the real problem and get back on track.
Asking the magic question helps only after the fact. A better approach is to establish design review ground rules. I’ve found ground rules for effective design reviews to be extremely helpful and they do not go without saying. Here are some relevant ground rules I like to use.
Determine goals. The first step is to determine your goals. What help do you need? What would you like to get out of the meeting? Do you want high-level feedback or low-level feedback? The clearer your goals are, the more likely you will achieve them. Without clear goals, you will get random feedback.
Respect the presenter’s goals If they ask for high-level feedback, don’t critique the layout, fonts, or colors. If they ask for detailed feedback, don’t critique their scenarios or value propositions. If you have feedback that you believe is helpful but outside their goals, consider tactfully sending it via email after the meeting.
Don’t redesign Your goal is to help the presenters, not do their design work for them. These are design reviews, not design sessions. This is not a design committee. Assume that the presenters are fully capable of incorporating your feedback. Please do not offer your version of the design unless the presenters ask you to. Doing so otherwise is rude.
If you do only one thing:
Remember that there is no bad feedback only poorly presented feedback, which is often presented in the form of a solution. To win UX Design Jeopardy!, get the discussion back on track quickly by recognizing the situation and asking the magic question.
Once you learn how to play UX Design Jeopardy!, you’ll quickly learn that feedback you would have dismissed in the past has some hidden insight waiting to be revealed. The result of winning this game is more effective design reviews and, ultimately, better user experiences.
For any UX project, it’s almost a sure thing that a top goal is to have an “intuitive UI.” To users, describing a UI as intuitive is among the highest praise they can bestow. Given this, it’s reasonable to ask what it means for a UI to be intuitive. Surprisingly, nobody really knows. Ironically, people’s definition of intuitive is, well, intuitive, as they struggle to define the term in a specific, meaningful way. (Other popular UI goals share this problem, “simple,” “easy to use,” and “clean” being runners up.)
A practical question: How can you achieve a project goal if you don’t even know what it is?
My practical answer: You can’t. The term “intuitive” is meaningless as a UI characteristic, so—with the exception of casual conversation—we should avoid using it, at least without prior definition.
I used to work at Microsoft and as a Microsoft employee, it wasn’t uncommon for people to tell me (with a certain glee) that, they, unfortunately, prefer using a Mac. While I primarily use PCs, I too have a Mac and have had a current model for decades. I like the Mac and appreciate its advantages (along with its disadvantages), but knowing that my lack of disapproval would be disappointing, I always keep that detail to myself. Everyone assumes Microsoft employees hate Macs.
From this point, the conversations have been remarkably consistent. My response: “Really, why is that?” To this their response is consistent and immediate: “I find the Mac much more intuitive.” My response: “Interesting—could you give me some specific examples of how it is more intuitive?” With this question, their glee turns to shock and horror as if to say “Of course, the Mac is more intuitive—how dare you question that!” From this point, they would struggle to come up with some sort of answer, ranging from “it just is” to “it just works” to “it’s simpler” to “Mac apps have a more consistent look and feel.”
Sure, there’s an element of “intuitiveness” in those responses, but there is no clear, consistent definition. Sans the reality distortion field, in practice intuitive just means better. But going back to our UX project, imagine a project goal being a “better UI.” An equally useless as a goal, just more obviously so.
Starting with the definition of intuition from Wikipedia, I’ll say that the “dictionary definition” of intuitive is:
A UI is intuitive when users understand its behavior and effect without use of reason, experimentation, assistance, or special training.
For such intuition to be possible requires prior knowledge, either from experience in the real world or with other software. So, for example, if something looks like a push button, we know from the real world that we can click on it to make something happen. Alternatively, if something looks like a link, we know we click on it from experience with other software.
We can boil this definition down to two requirements: affordance and consistency, where affordance allows us to predict what is going to happen based on appearance, and consistency to make that prediction correct. Labeling and context are also factors in making the prediction.
So is intuitive just a fancy word for affordance, consistency, and predictability? It could be, but when people use the term, I think they have more in mind.
I like to define things, so I’ll take a crack at it. A UI is intuitive when it has an appropriate combination of:
Of these elements, the first two reflect the dictionary definition, and the others are those extra attributes that go beyond the literal definition.
If your goal is an “intuitive” UI, I think it’s best to explicitly spell out exactly what you want using the above attributes. Don’t use the term in specs, proposals, or plans unless you define the term in detail beforehand. When evaluating a UI, always do it in terms of the specifics. Otherwise, intuitive will end up being a vague synonym for good instead. That’s at best. The world’s most confusing UI could be credibly described by its creators as intuitive as long as the term isn’t defined specifically.
If you do only one thing:
Don’t use the term intuitive to describe a UI without a definition because nobody understands what it means. Instead, define the term specifically in your documents or describe your goals using more specific terms.
I’ve got 80+ UI books in my library, but only two bothered to define the term. In The Humane Interface, Jef Raskin defines intuitive as familiar. I prefer consistent though because it is more specific and actionable. In Software for Use, Larry Constantine and Lucy Lockwood define it as guessable and behaving as expected.
“Everything is best for something and worst for something else. The trick is knowing for what, when, for whom, and why.”—Bill Buxton
The ribbon UI, introduced by Microsoft Office 12, is a great interaction innovation. Many teams are starting to adapt ribbons in their apps. This is good when it’s appropriate, but unfortunately that isn’t always the case. Doing the right thing can be especially challenging when politics enter the picture.
Historically, GUIs started with menu bars, which do a great job of hierarchically presenting the complete set of commands that apply in a context. A major problem with menu bars is that they take a lot of work to navigate, so a typical command takes at least three clicks to execute. Toolbars solve this efficiency problem by displaying iconic commands directly on the surface—requiring only a single click to execute. Their problem is that they don’t scale well, so toolbars usually display only the most commonly used commands. Happily, menu bars and toolbars are very complimentary, so using them together can give both comprehensiveness and efficiency.
The classic menu bar/toolbar combo worked well for Office for many releases, but at some point Office apps had so much functionality that this solution started to break down. Jensen Harris does a great job of explaining the problem with The Story of the Ribbon. The Office ribbon scales much better, is much more flexible, has much better labeling, and requires users to look for commands in a single, consistent place. Throw in advanced features like galleries, live preview, dynamic sizing, and enhanced tooltips, and you’ve got the potential for a great user experience.
So with all this great innovation, what’s not to like? The ribbon has one significant strike against it: it is the heaviest commanding solution there is. A good UX design principle is to use the simplest, lightest weight solution that does the job well, so applying this principle suggests that—given its weight—a ribbon should be among last commanding choices, not the first.
Another challenge is that we have a natural tendency to abuse new UI. The “new UI abuse cycle” goes something like this:
There are many examples of such abuse, tooltips being my favorite. Given all the useless, annoying, unnecessary tooltips out there, you’d swear the guideline was “always provide a tooltip, no matter how useless or annoying.”
Redundant, annoying tooltips are “the worst for something else.”
Fearing this sort of abuse for ribbons, I came up with this example when I wrote the ribbon guidelines when I was at Microsoft.
This is obviously crazy, right?
This example makes a compelling case that not every app should have a ribbon.
The Windows ribbon guidelines have a useful checklist of factors to consider when deciding to use a ribbon. If your app can really benefit from a ribbon, go for it! The challenge is the marginal situations, where you could use a ribbon but possibly shouldn’t. If a ribbon isn’t appropriate for your app, most likely it’s because it’s solving problems your app doesn’t have—adding unnecessary complexity along the way.
While at Microsoft, I observed that teams would make a sincere effort to do the right thing. They would apply the ribbon guidelines, consider alternative solutions, and choose the best approach for their customers.
That is, until they had an executive review, which would tend to go something like this:
VP: So, we’re using a ribbon for the next release, right?
Team: Umm…we looked into this carefully, applied the ribbon guidelines, considered the alternatives, and decided a ribbon really not a good choice because…
VP: We’re using a ribbon.
Team: But using a ribbon would cause problems with…
VP: We’re using a ribbon. Make it work.
Executives believe that ribbons have strong customer support and will make even the most dated app feel modern. Furthermore, Office is using it and no executive ever lost his or her job by copying Office. Ship the next release without a ribbon and there’ll be some ‘splainin’ to do. Execs don’t like having to do any ‘splainin’.
I’m a strong believer in user-centered design—executive-centered design, not so much. The problem with this approach, of course, is that such executive mandates completely ignore the nature of your application, its commanding needs, your target users, their goals, etc. This is now purely a political decision. Still, this type of decision making happens all the time, so you have to deal with it.
Don’t be stupid over this—if your VP insists on using a ribbon regardless of its appropriateness, it’s not worth falling on your sword over. If you work hard enough, you can make it work. But if you are fortunate enough to have an executive that listens to reason, here are four solid arguments you can make for proceeding with caution:
If you do only one thing:
If your app can really benefit from a ribbon, go for it! But if not, be fully aware of the challenges and proceed with caution. Either way, adapting an effective ribbon is going to take a lot more work than you expect.
Consider using our Ribbon Design consulting service if you are having trouble deciding if you should use a ribbon or need help designing it.