Archive for the ‘UX 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.

And

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

Or:

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



For more information, please contact info@uxdesignedge.com

All Content Copyright © UX Design Edge