Archive for the ‘UX design’ Category

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.

Accidental manipulation and intentional affordance

In my post Getting started in interaction design, I recommend that you pay attention to design and learn to appreciate good design. I had a chance to do both last weekend. I was at Stowe Mountain Lodge, my favorite resort in Vermont, and noticed that the controls on their Technogym exercise equipment were particularly well designed. To appreciate why, I’d like to start by explaining a significant problem with direct manipulation, and give a couple examples of direct manipulations that aren’t so well designed.

Direct manipulation

Direct manipulation is a crucial ingredient of a modern UX. Direct manipulation is the ability for users to perform a task on an object instead of indirectly through some intermediary. For example, moving a window using a Move Window menu command is indirect manipulation, whereas dragging a window into position is direct. Traditionally we have used a mouse to perform manipulation, but touch-based interfaces feel more direct because there’s nothing between users and the object being manipulated.

Accidental manipulation

But there’s a problem: where there is direct manipulation, there is accidental manipulation. There’s always a chance that the user performed an action either entirely by accident, or performed the wrong operation or acted on the wrong object.  The potential for accidental manipulation is large enough that critical operations shouldn’t be performed without confirmation. (Hmm…did I just drag the North American domain to Fiji?) But note that generally, combining direct manipulations with confirmations is a poor idea because confirmations destroy the very directness you are after.

Touch-based UIs are especially prone to accidental manipulation. This is why a swipe motion (with very little margin for error) is used to initiate interaction with an iPhone—a correctly performed swipe indicates with high probability that the input is intentional.

Well designed direct manipulation must minimize the likelihood of accidental manipulation. Failing to do so will make the design annoying at best and disaster prone at worst.

Bad example: My Miele vacuum

My Miele vacuum is an example of a design that fails to consider accidental manipulation.

Take a look at the handle, and notice the bypass device at the top. Not obvious from the photo is that the bypass device slides open with minimal resistance. Where do you think your thumb will naturally go? When vacuuming, what motion will you naturally make? Guess what happens—constantly—when you naturally use the device as intended.

This vacuum is frustrating to use because I’m constantly opening the bypass without realizing it. The feedback isn’t as obvious as you might think—the vacuum doesn’t work well and sounds louder and eventually you realize that you’ve opened the bypass and wonder how you managed to open it yet again.

Talk about not getting the proper amount of suction.

Another example: Windows 7 Aero Snap

To take a software example, this extremely heavily promoted feature allows you to quickly view two windows side by side by dragging them to their respective sides of the screen. (Snarky comment: from the advertising, you’d swear that this was the most useful thing you could do with a computer.)

Unfortunately, this feature wasn’t designed to prevent accidental manipulation. If you don’t want a window to snap, it’s very difficult to persuade Windows otherwise once you get in Snap’s gravitational field. (“Aero Shake” cancels a snap, but shaking isn’t easy to do and it’s difficult to discover.)

Aero Snap works extremely well better with high resolution, wide-screen monitors, but I find that it’s way too easy to trigger by accident with lower res monitors (like 1024×768). In this case, the accidental snaps happen far more frequently than intentional ones, making the feature a net negative.

This part of Windows 7 wasn’t my idea.

Update (5/11/2011): I finally got fed up and turned off Aero Snap. I find that even on high res monitors, it’s wrong far more often than it’s right. The novelty has long worn off, so it’s just not worth the trouble anymore.

Great example: Technogym

I found that the Technogym level controls are brilliantly designed to prevent accidental manipulation. Here is what the control looks like:

Note how recessed the button is. Here’s how the handle looks when you grab it naturally:

Note how the control lies in the gap between the thumb and the fingers, and how the thumb is naturally away from the control. However, even if you were to slide your thumb around in a variety of positions, you won’t trigger the control accidentally because it is recessed:

But if you do want to change the level, doing so is simple and easy.

The goal is to make it difficult to press the button through casual contact. If you press the button, you almost certainly did so deliberately.

Intentional affordance

I use “intentional affordance” to describe direct manipulation that ensures the interaction is intentional. The challenge is to design simple, natural interactions that are constrained just enough to signal clear intent. The Technogym controls and the iPhone swipe are excellent examples.

If you do only one thing:
Design manipulations that are likely to be performed accidentally to have affordances that require clear, deliberate intent.

The tragedy of great design

The tragedy of great design is that if it is particularly well done, most people won’t even notice it. Their reaction will be “Of course! How could you design it any other way?” I bet most people who used the Technogym controls never gave them a second thought. But the bad examples show that great interaction design happens only when someone designs something carefully and well.

Fixing Aero Snap

As a challenge, design Aero Snap to have intentional affordance. When done, compare your answer to mine.

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