Archive for the ‘UI design’ Category

Icon design for non-designers

Quick question: what’s a good icon for fidelity? For intelligence? Taxes? Change?

My quick answer: There isn’t one…so you shouldn’t try too hard to make one.

A picture is worth a thousand words…unless it’s an icon

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.

Take the icon challenge

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.

Recognition vs. comprehension

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.

Icon design types

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 symbols.
  • Preview of results.
  • Simple nouns.
  • Simple nouns doing simple verbs.
  • Simple nouns showing simple adjectives.
  • Well known logos.
  • All of the above with a single standard overlay (error, warning, disabled, blocked).

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:

  • Metaphors When an object with similar behaviors or properties  is used as a substitute.
  • Metonyms When a completely different but related object is used as a substitute.
  • Synecdoche When a part represents the whole.

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:

  • Unfamiliar nouns.
  • Complex, detailed icons.
  • Abstract concepts.
  • Multiple overlays.
  • Puns.

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.

Everett’s Laws of Icon Design

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.

What to do if your icons aren’t good

Consider the following, in priority order:

  • Reconsider the need. Simply put, icons are overrated and are rarely required. Text labels work just fine when there are only a few commands, and icons help recognition when there are many. But when they aren’t really needed, icons just add visual clutter. You can design a great experience without them. Check out modern web-based apps like FreshBooks and Wufoo, which use few icons and aren’t missing anything.
  • Reconsider consistency. Using icons somewhere doesn’t mean that you have to use them everywhere. Note how Outlook only uses the well known standard icons in the File menu.

    Not only does that eliminate the need for icons with low comprehension, it makes the frequently used icons stand out.
  • Hire an icon design specialist. Icon design is a specialized talent, so you’ll need to hire a specialist to design professional, comprehensible icons. Keep in mind that creating custom icons is very time intensive, so don’t expect to get off cheap. (And whatever you do, don’t attempt to design them yourself.)

Use preexisting icons consistently with their meaning

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.

Are you sure? How to write effective confirmations

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.

UI is communication

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.

What do confirmations communicate?

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:

  • Risky actions The user is about to take an action that has significant consequences that cannot be easily undone.
  • Unintended consequence The action itself might not be risky, but there is a significant side effect of the action that the user needs to be aware of.
  • Clarification There is more than one way to perform the action, so the user needs to confirm the desired outcome. These are usually presented as a choice dialog, but they have the effect of being a confirmation as well, particularly if the user doesn’t desire any of the offered outcomes.

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.

Are you sure?

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:

  • Prevent the error You don’t need to confirm if you can prevent a mistake from happening in the first place. For example, if you design your system architecture to avoid unintended consequences, there’s no need for its confirmation. Another approach is to design direct manipulations to avoid accidental manipulation.
  • Provide feedback Good feedback is a good way to prevent errors, especially with direct manipulation. Users shouldn’t be able to make significant mistakes without knowing it. For example, you don’t need to confirm direct manipulations if their effect is extremely clear.
  • Provide undo Provide the ability to easily revert unintended actions. For example, having a trash can, recycle bin, or deleted items folder is a standard way to restored accidentally deleted objects. User-created objects should be restorable from their deleted state for an extended period of time—modern UXs shouldn’t delete them until necessary.
  • Make the results easy to change Suppose you have a situation where there might be two intended outcomes, but one outcome is 98% likely and the other is just 2%. You can eliminate the Clarification confirmation by doing the 98% choice automatically, especially if you make it easy for users to chose the 2% option later.
  • Just don’t ask If the confirmation isn’t necessary and none of the above alternatives work, usually the best solution is to just not ask.

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?”

Main instructions

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.

Provide all the information

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.

Design responses to create a mental speed bump

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:

  • We can’t force users to read the main instruction.
  • Users do read button labels before they click them.

Given these facts, there are three ways we can write the response button labels to create a mental speed bump:

  • Choose specific responses so that the reason to not proceed is obvious even without reading the main instruction.

The Save vs. Don’t save labels tell you everything you need to know.

  • Use Yes/No responses (with the safe response the default). While there’s no guarantee, users generally read what they are responding Yes or No to before clicking.
  • Add “anyway” to the label, as in “Proceed anyway.” Anyway is a very provocative word that gets users to stop and think. “You mean there’s a reason to not proceed? Better find out what it is first.”

Don’t annoy me again

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.

How to win UX Design Jeopardy!

“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.

Why do we do this?

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.

So what’s the problem?

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: don’t debate—ask the magic question instead

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.

Establish design review rules

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.

For presenters:

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.

For reviewers:

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.

Intuitive UI: What the heck is it?

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.

Struggling for a 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.

A dictionary definition

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.

Everett’s definition

I like to define things, so I’ll take a crack at it. A UI is intuitive when it has an appropriate combination of:

  • Affordance Visually, the UI has clues that indicate what it is going to do. Users don’t have to experiment or deduce the interaction. The affordances are based on real-world experiences or standard UI conventions.
  • Expectation Functionally, the UI delivers the expected, predictable results, with no surprises. Users don’t have to experiment or deduce the effect. The expectations are based on labels, real-world experiences, or standard UI conventions.
  • Efficiency The UI enables users to perform an action with a minimum amount of effort. If the intention is clear, the UI delivers the expected results the first time so that users don’t have to repeat the action (perhaps with variations) to get what they want.
  • Responsiveness The UI gives clear, immediate feedback to indicate that the action is happening, and was either successful or unsuccessful.
  • Forgiveness If users make a mistake, either the right thing happens anyway or they can fix or undo the action with ease.
  • Explorability Users can navigate throughout the UI without fear of penalty or unintended consequences, or of getting lost.
  • No frustration Emotionally, users are satisfied with the interaction.

Of these elements, the first two reflect the dictionary definition, and the others are those extra attributes that go beyond the literal definition.

Achieving your goals

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.

A footnote

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.

The politics of ribbons

“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.

A brief history of application commanding

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.

To love a new UI is to abuse it

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:

  • We discover a new UI
  • We apply the new UI sensibly and strategically
  • We fall in love with the new UI, and start to apply it foolishly
  • Given all the abuse, we fall out of love with the new UI
  • We abandon the UI, perhaps for the next new thing

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.

So, should your app use 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.

A better question: does your VP think your app should use a ribbon?

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.

Four reasons to proceed with caution

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:

  • Designing a useful ribbon takes lot of work. The Windows ribbon guidelines stress that a successful ribbon will most likely require a complete redesign of your application. Great ribbon-based apps add value through surfacing buried commands, making commands easier to find, and advanced features like results-oriented commanding and live preview. Most apps can’t support these without a significant redesign. (If adding a ribbon to your app was really easy to do, that should tell you something about the value of the ribbon.)
  • Change is bad unless it is great. A not-so-great ribbon is just a fat toolbar that fails to improve the UX significantly. Such ribbons are more likely to upset experienced users than impress them. Even if you are aiming for a lower bar, it’s worth noting that even a “just OK” ribbon is much harder to design than an acceptable menu bar/toolbar combo. It’s going to require a lot of design work, user testing, and iteration to just get to OK.
  • Ribbons aren’t really modern UI. Yes, ribbons are more modern than menu bars and toolbars, but that’s not saying much. Make a list of all the apps and web sites that you think have modern user experiences. How many of them have ribbons or anything even similar? None, I bet. When was the last time you used something like an iPhone app and thought “I wish this app had a ribbon”? Modern UIs are characterized by simple, lightweight, contextual, direct/touchable, dynamic experiences—pretty much the opposite of ribbons. Complex, heavy, out-of-context, indirect commanding is old school.
  • Ribbons have a significant opportunity cost. Rearchitecting your app to create a great ribbon UX means that you aren’t using your limited resources to be great at something else. If you are in a competitive market, doing so could put at a significant disadvantage.
    Consider Office itself. If you’ve used Office extensively over the years, you know that there are literally hundreds of small, annoying problems that have largely gone unfixed for the last decade. (There are too many to list, but here’s one example: try creating a Word doc by copying and pasting bits from other Office docs without any tweaking—the results will look like a ransom note. Paste is the top command in Office, yet it continues to do the wrong thing by default.) As much as I like the Office ribbon, I’d prefer a product that has nailed basic functionality even more.

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.

We’re here to help

Consider using our Ribbon Design consulting service if you are having trouble deciding if you should use a ribbon or need help designing it.

For more information, please contact

All Content Copyright © UX Design Edge