Intuitive Design Eight Steps to an Intuitive UI

Highlights

first met Everett McKay in the early 2000s when we worked together on a version of Microsoft Windows. At a time when the software industry was fascinated with tricking out user interfaces with spectacular visual effects, Everett was drawn to the humbler task of studying software that could be explained to the user—or, ideally, which explained itself to the user. The world has moved on from the visual effects in fashion at that time, but the need for intuitive, self-explanatory software is as durable as ever.

▶ 0:06

The fundamental challenge in software design is how to simultaneously conceive of a novel, complex system while seeing clearly how that system might be perceived by an uninitiated user. In the very act of conception, you move yourself towards a deeper understanding but away from the novice’s perspective. This makes it harder and harder for you to imagine how a new user might experience your design.

▶ 0:38

We can find the problems, but we lack confidence in our solutions and have a very difficult time convincing others. Aside from usability testing, we lack a framework for analyzing designs and an objective, actionable vocabulary for convincing others.

▶ 1:02

The word intuitive is vague and abstract, but the Eight Attributes of Intuitive UI (defined in Chapter 3) are specific, concrete, and measurable. You and your team will have much more productive conversations by using these attributes. If you tell me my design is unintuitive, we can argue about it. But if you say that a feature in my design isn’t discoverable in a particular context or that its affordance is misleading, I know exactly what you’re saying and what to do about it. We are no longer having a subjective conversation about abstract concepts—we’re discussing specific, concrete design problems!

▶ 1:18

I went through my tall stack of UI design books and looked up “intuitive” in each index. You would think such an obvious topic would be addressed in every design book, but, surprisingly, only Jef Raskin’s The Humane Interface had a definition. Raskin defines intuitive to mean familiar : One of the most laudatory terms used to describe an interface is to say that it is “intuitive.” When examined closely, this concept turns out to vanish like a pea in a shell game and be replaced with the more ordinary but accurate term “familiar.” Familiar ? We have replaced one abstract term with another. What exactly does familiar mean? How can we use familiar to evaluate a design? I’m not convinced that Raskin’s alternative definition is a step up in accuracy or practicality.

▶ 1:58

Intuitive Design explains this intuitive UI framework in detail and applies it to many practical examples, ranging from mobile and desktop apps to everyday things. At the time of this writing, I have been using this framework for over eight years and the results have been excellent. No, an intuitive UI isn’t personal and subjective—we just need to use a framework that establishes a shared understanding and that makes our assessments of UIs objective and effective.

▶ 2:45

UI design is an objective, principled form of human communication, not a subjective art!

▶ 3:16

I vividly remember my struggle to learn WordPerfect 5.1 back in the day. (And I’m sure older readers remember this as well—it’s hard to forget. Younger readers: Substitute here any app that required watching several YouTube videos to learn.) And “struggle to learn” is the right phrase—learning how to use the app required a significant amount of time and even more motivation. You couldn’t just install the software and use it. You had to read the user manual or take a training course. WordPerfect was not designed to be intuitive—it was designed to be learned.

▶ 3:23

Not long ago, it was acceptable to solve significant usability problems through documentation alone. Why bother fixing the underlying design when you can just document the workaround!

▶ 3:57

By the way, this RTFM thinking doesn’t just lead to user manuals. Manual-dependent UI design also leads to training, technical support, online Help (and associated internet research), poor productivity, and, on occasion, very costly mistakes. (And yes, watching YouTube videos counts as training.) It leads to poor customer reviews spiced with words like frustrating, confusing, bewildering, clumsy, awkward, and annoying. The need for a user manual is merely the most visible manifestation of a much larger problem.

▶ 4:09

We have a new generation of users, many who have never read a user manual in their life. They grew up without expecting the need for documentation and training. They are your next generation of users. And don’t expect their documentation reading habits to change.

▶ 4:43

Many managers want their UX teams to demonstrate the ROI (return on investment) of UX design to justify any investment. I understand the need to demonstrate value and effectiveness, but this demand represents old-school thinking because it implies that investing in UX design is optional. In the new school, excellent UX design is mandatory even to be a player!

▶ 4:59

I prefer a simple, back-of-the-envelope approach that I find more credible for calculating both the need for and the results of UX design investment. If your tech support team tracks their support calls (and they should), make sure they tag the ones related to poor usability, such as confusing error messages. Determine that technical support cost per year. This is a real, assumption-free number that’s likely disturbingly large. And it’s just one of many costs due to poor usability. Make getting that number down part of your UX team’s mission and thereby improve customer satisfaction. Your impact will be measurable through the same tech support data.

▶ 5:25

Still, such ROI numbers miss the point. Great UX design is no longer about getting return on investment—it’s about staying in the game! It’s about gaining or at least preserving market share and staying relevant to today’s users. If your product is harder to use than the competition’s, it’s game over for getting new users. In The Innovator’s Dilemma , Clayton Christensen describes how disruptive innovations displace established market leaders, often through much simpler solutions. These new solutions aren’t feature-rich—they simply do a better job at the few things users care about the most, eventually eroding the legacy player’s market share. The clear implication: Suppose you are an established player with a market-leading, powerful, feature-rich legacy product that’s hard to use and requires substantial documentation and training. If you have a competitor that is a disruptive innovator, they aren’t going to compete with you on features (where you are strong). They are going to attack your poor UX (where you are weak) with a simple, intuitive UI that doesn’t require documentation or training. Such a competitor can turn your legacy product’s greatest strength into its greatest weakness. For modern software, a better question than “What is the ROI on UX?” is “Do we want to remain competitive?” Harsh news. But don’t blame me—I’m not judging, I’m just being honest! Requiring UX-design

▶ 6:07

For modern software, a better question than “What is the ROI on UX?” is “Do we want to remain competitive?” Harsh news. But don’t blame me—I’m not judging, I’m just being honest! Requiring UX-design ROI is old school because it presumes that investing in your product’s user experience is optional

▶ 7:38

Designing an intuitive UI is impossible because it’s personal and subjective! I might find a UI to be intuitive and you might not. This statement is convincing only if you don’t understand what intuitive UIs are all about. The top goal of this book is to give you an objective understanding of what makes a UI intuitive. It really isn’t a matter of opinion. Our users are highly experienced, trained professionals! You can’t just walk up and use our product—our users have to be trained. It’s not designed for your mom or dad. Some applications are targeted at trained professionals, but that doesn’t give you a free pass to make your designs unintuitive. It turns out that, just like everyone else, highly experienced, trained professionals don’t like wasting time or making mistakes with an unintuitive UI. For example, when I’m flying, I certainly want the pilots to have plenty of training. But I hope that the training is focused on how to fly the aircraft safely and handle

▶ 8:00

Our users are highly experienced, trained professionals! You can’t just walk up and use our product—our users have to be trained. It’s not designed for your mom or dad. Some applications are targeted at trained professionals, but that doesn’t give you a free pass to make your designs unintuitive. It turns out that, just like everyone else, highly experienced, trained professionals don’t like wasting time or making mistakes with an unintuitive UI. For example, when I’m flying, I certainly want the pilots to have plenty of training. But I hope that the training is focused on how to fly the aircraft safely and handle emergency situations, not on understanding what the confusing, unintuitive avionics really mean.

▶ 8:59

This is an internal line-of-business app—our users must use it! They don’t have a choice, so why bother making it intuitive? As I suggested earlier, users might be motivated to use an unintuitive app if they are forced, so this claim is at least plausible. But there are two flaws:

▶ 9:42

People can learn! People learn things all the time, so they will just learn how to use our app. Do you want the success of your app to depend upon people learning stuff? I don’t think so. More about this excuse in a moment.

▶ 10:02

Now, let’s work this through. Suppose we are Blackberry. We used to own the smartphone market (our products were called “crackberries” because they were so addictive) and we want to get back in the game. Which design approach makes more sense? The intuitive design that users can pick up and immediately figure out on their own, or the radically innovative design with an unintuitive navigation model that our own salespeople can’t even demo ?

▶ 10:15

I vote for the intuitive design. Yes, it’s true that users can learn, but will they? What happens if they don’t learn or don’t remember what they learned? As we’ll see in Chapter 5, not everything can be intuitive and it does make sense to design certain interactions to be strategically unintuitive (instead of accidentally unintuitive), but only if those interactions are advanced, infrequent, and optional. Do you want the success of your product to rely on people having to learn its essential interactions?

▶ 10:42

Some popular but unhelpful definitions Before I present the definition that I recommend, let’s take a quick look at some popular but impractical definitions. People often say an intuitive UI is Simple, easy to use, better These aren’t good definitions because they confuse intuitive UI with completely different design attributes. We know what simple means, what easy to use means, and what better means—and they are different from what we mean by intuitive . Still, they are accurate in the sense that when people say a UI is intuitive, they often mean that they like it or think it is better than the alternatives. Really “dumbed down” so any idiot can get it This definition is flat-out wrong. An intuitive UI isn’t dumbed down, and we shouldn’t assume that our users are stupid. This viewpoint is so wrong that we will explore it in detail later in this chapter. An “unrealistically high bar” that most UIs can’t achieve I have heard many people assert that an intuitive UI is some unattainable perfection. This is wrong, of course, because it’s possible to design intuitive UIs once you know how. Suggesting that intuitiveness is unattainable is hardly motivating and, simply put, false. A gap between the design model and the user model This definition comes from Don Norman’s The Design of Everyday Things . Norman asserts that designers effectively have a conversation with their users. It’s not a direct conversation—it takes place through the product. Design models are designers’ intention for how they believe the product should work, whereas user models are users’ interpretations of how they think that design works. For an intuitive design, these models should be the same. I love the concept, but it is difficult to apply. To do so, you must figure out the design model, the user model, whether there’s a gap between the models, whether that gap is important, and what to do about it. That’s way too much figuring. Familiar This definition involves assessing whether target users can apply previously learned knowledge to their interaction with the current design. Successfully doing so requires consistency with those prior interactions, otherwise users will be misled or confused. While I agree that intuitive UIs need to leverage previous knowledge, this is a secondary consideration and possibly misleading because many familiar designs are often unintuitive. We’ll explore problems with defining intuitive as merely familiar in Chapter 4. Learnable In this case a design has attributes that make it easy to learn. However, an intuitive UI isn’t about making a UI easy to learn—it’s about avoiding the need for learning in the first place. We’ll explore this distinction in Chapter 4. Obvious always wins I like this one—if it were only obvious what obvious means and how to correctly choose the winner. Whatever Apple does As a company, Apple certainly has a high bar for design and an enviable track record for great user experiences (ignoring iTunes). Still, just because Apple does something doesn’t make it intuitive. I keep track of all the unintuitive UI I find on my iPhone—it’s a very long list. Not sure, but I know it when I see it—it just feels right Although a frequent response to my request for a definition, this answer is an evasion and I suspect a less embarrassing way to say I have no idea . You can’t design for something—or even recognize if you have it—without being able to define it. As you can see, there is a lot of confusion. The lack of a common, practical definition for intuitive UI is sometimes used by UX design thought leaders as a reason to dismiss the concept entirely. Nobody knows what intuitive means, so why bother? Let’s focus on other design objectives instead. Let’s not repeat their mistake or wallow in their remorse. As designers we need this concept—badly! We need a better, more specific, more practical definition. So let’s define intuitive UI

▶ 11:13

A practical definition Here’s the definition I find actually useful: A user interface is intuitive when target users understand its behavior and effect without use of reason, memorization, experimentation, assistance, or training. Or to rephrase more simply: an intuitive UI is immediately self-explanatory to its target user. This is a practical definition because it is focused on the outcome we want. If your target users must resort to reason, memorizing, experimenting, seeking help, or training, your UI isn’t intuitive by definition. If you find this definition narrow, that is very much deliberate. Remember the problem we are trying to solve: few people know what this important UX concept means. An overly broad definition—one that is essentially a synonym for good —would fail to address the problem.

▶ 15:23

Designers often refer to well-designed interactions as being smooth . As you might guess, I avoid using vague, abstract words like smooth, but we can try to redeem it with a specific definition. An interaction is smooth when Users complete a task successfully on the first try. Users make very few mistakes along the way. Users maintain their flow, without awkward pauses to think things through or experiment. By contrast, an interaction isn’t smooth when users have to think or experiment because mistakes are essentially interaction experiments. This leads to what I call the Manifestation of Intuitive UI : You can observe that a UI is intuitive when users successfully complete tasks on the first try consistently, without making mistakes. This is what intuitive UI looks like, and it’s observable and measurable. Yes, it’s a thing!

▶ 16:16

Intuitive UIs are not dumbed down I mentioned that occasionally people define intuitive as dumbed down . This is not only wrong and disrespectful to our users but also counterproductive. It is not uncommon for a team with a poorly designed product that users dislike to attempt to fix it with a severely dumbed-down, spoon-fed, irritating design. Teams that try this invariably discover that their users prefer the original—even if it’s unintuitive. Such stories are not an indictment of intuitive UI but of dumbed-down UI. Dumbing down says that you believe your users are dumb—which you should never do!

▶ 17:11

However, I prefer a more principled approach: analyzing the sequence of steps—both mental and physical—that a user performs to complete a task with your app, identifying the potential problems for each step, and determining design attributes that prevent those problems. I call the sequence of steps the interaction lifecycle. If the user can get through all the steps and successfully complete the task without reasoning, experimentation, memorization, documentation, or training, then our definition of intuitive UI has been met. By contrast, if the user can’t complete all the steps of the interaction lifecycle, that meets our definition of unintuitive.

▶ 17:52

The Eight Attributes of Intuitive UI And now the moment you have been waiting for: the Eight Attributes of Intuitive UI are discoverability, affordance, comprehensibility, responsive feedback, predictability, efficiency, forgiveness, and explorability.

▶ 18:35

Let’ s look at each attribute in detail, but first, here’s how they map to the interaction life-cycle steps: Sets a goal to accomplish. Finds the starting point that might achieve the goal. Discoverability, affordance, comprehensibility, predictability. Performs the action specific to the goal. Affordance, efficiency, explorability. Observes the action’s results to determine whether goal was achieved as expected. Responsive feedback, predictability. If successful, continues to the next goal; otherwise, fixes any problems. Forgiveness, comprehensibility.

▶ 18:54

Discoverability is the target users’ ability to locate the UI elements needed to achieve a goal—when they need them. Because discoverability facilitates the first step in

▶ 19:31

Frequent tasks need a clear, visually obvious starting point. Users need to know where to look (and possibly interact) first for common tasks. Advanced, infrequent tasks can be much less obvious.

▶ 19:43

Often users need to interact with a specific object. The best place to present object-specific commands is directly on the object itself, either persistently or by entering an edit mode.

▶ 19:57

A common pattern for poor discoverability is an initial, empty state—especially for lists, collections, or initial configurations. Common solutions are to provide initial samples (such as sample photos in a photo album) or provide clear instructions on how to add items. Doing so is a form of user onboarding, which strives to get new users familiar and successful with an app as quickly as possible.

▶ 20:10

Unintuitive: Poor presentation An interactive UI element has a poor presentation when it doesn’t look interactive—or possibly doesn’t look interactive now . This could be due to missing affordance (the second intuitive attribute), nonobvious dynamic affordance (revealed on hover or another interaction but not appearing interactive now), appearing disabled, or being so small or hard to find that users don’t notice it. Such examples of poor presentation greatly diminish a UI element’s discoverability.

▶ 20:37

Unintuitive: Poor location and layout An interactive UI element has a poor location by context, layout, or convention. For context, users expect proximity and sensible physical layout. For a given UI element, users expect any relevant commands will be physically near that element. The pairing of labels to their associated UI elements should never be ambiguous. They also expect the reverse—that any commands physically near the element are relevant to that object unless there is a clear separator. A classic unintuitive example is a DVD player with the On/Off switch next to the DVD tray and the button for ejecting discs in a completely different place.

▶ 21:12

A goal of well-designed layout is to suggest relationships. Group boxes (along with panes) are often used to make relationships explicit, whereas separators are used to make the lack of relationship explicit. Generally, it’s better to show relationships using layout alone and resort to panes, boxes, and separators only when necessary.

▶ 21:56

Finally, it’s worth mentioning that a top cause of user frustration is when designers decide to move UI elements from one release to the next, even if the new location makes more sense (to new users) than the old one. Be strategic when placing or moving UI elements across releases; make sure new locations are worth any frustration to your current users.

▶ 22:17

Unintuitive: Too many competing options Perhaps the desired UI element is hidden in plain sight but users can’t find it because they are overwhelmed by all the options. It’s like playing Where’s Waldo? Programmers are especially fond of designing overly complex, jam-packed screens in the mistaken belief that doing so results in a more efficient UI. This approach fails because there’s a limit to how much users can discover and comprehend simultaneously. Better to take advantage of priority, context, and grouping to make things easier to find.

▶ 22:41

Unintuitive: Just plain hard to find, like a puzzle The desired UI elements are hidden initially, then revealed dynamically when users perform some action. Such interactions feel like a puzzle, as if you are trying to access a jewelry box’s secret compartment. Some users never find these UI elements and their interaction with your product fails.

▶ 23:14

Here is the dynamic UI challenge: on one hand, we don’t want the overall experience to feel overwhelming, but on the other hand, we don’t want it to feel like a puzzle either. The trick to get the right balance. Display enough information statically so that users can confidently and accurately predict (the fifth attribute) what they will see dynamically. When designing dynamic interactions, assume that users won’t proceed if they lack confidence.

▶ 23:38

An affordance is a visual property of a UI element that suggests, first, that the element is interactive and, second, how to interact with it. Once affordances have helped users determine that a UI element is interactive, they should further help users understand how to perform its primary interaction (such as tap) and, on rare occasions, secondary interactions (such as long press or 3D Touches).

▶ 24:07

Affordances are often a visual metaphor of some real-world counterpart: buttons, radio buttons, sliders, knobs, spinners, handles, grabbers are all based on real-world interactions. The most basic affordance is a button, which visually suggests clicking or tapping. By convention, colored or underlined text is assumed to be a link, which also visually suggests clicking or tapping, although the link affordance is less obvious and potentially misleading when compared to a button.

▶ 24:33

Consistency is crucial here—if an element looks interactive, make sure it is. If it looks like a button or link, make sure it is. Putting text in a box creates the appearance of a button and misleads the user. To emphasize some text, make it bold or italicized rather than underlined.

▶ 25:03

You would think the need for clear, unambiguous affordances would be obvious, but on occasion designers try to eliminate them—only to end up regretting it. An obvious example is when Microsoft temporarily removed the Start Menu button from the Windows 8 desktop. Where did access to the Start Menu go? How did you get back to the desktop from the Start Menu? Nobody knew—highly experienced users no longer knew how the product worked. As Luke Wroblewski, an internationally recognized digital product leader, likes to say, obvious always wins . There

▶ 25:22

The need for labels In The Design of Everyday Things , Don Norman famously points out how door handles have affordances. For example, some handles indicate pulling whereas others indicate pushing. If the affordance is misleading, the design flaw is often fixed with a label. I’m sure you’ve had the experience: you try to open a door, so you pull, pull, pull, until finally you see the label that says Push . As a result, Norman concludes, “If a door handle needs a sign, its design is probably faulty.” FIGURE 3-20 Are you supposed to pull or push this door? The affordance clearly indicates pull, but the label says otherwise. These are known as Norman doors . The Design of Everyday Things is a well-named book, because it is about everyday things and not technology. Here is my translation of Norman’s insight for intuitive UI: If a UI element needs a label to explain its interaction, its affordance has failed.

▶ 25:58

Of course, many UI elements need labels, but those labels should focus on the purpose of the element—not on how to do the primary interaction. Having to explain a UI element’s primary interaction in a label clearly indicates that its affordance isn’t working.

▶ 26:54

Comprehensibility is the target user’s ability to understand the meaning and effect of a UI element —enough to recognize that it is the right element for the desired task, to understand what the element does, and to make the right choices while interacting with it. Comprehensibility is the user’s ability to understand the meaning and effect of a UI element.

▶ 27:11

There is an art to (and many, many guidelines for) designing effective icons, but ultimately icon design boils down to a single inconvenient truth, which I call Everett’s Rule for Custom Icons: Users understand the standard icons, but they won’t understand your custom icons unless they are labeled.

▶ 27:33

There is no science behind this rule, but I’ve found exceptions to be surprisingly rare. If you design custom icons, you’re going to have to label them to make them comprehensible. While it might be a good idea to use custom icons to aid recognition, you will still need the text labels for comprehensibility.

▶ 27:54

Let’s consider an example. The following buttons are from a reservation system. What do you suppose these commands do in this View Reservation window? FIGURE 3-30 What do these commands do in a View Reservation window? Because it’s a modal window, users will assume that Cancel means close the window , but it really means cancel this reservation . I know this because I wanted to cancel the reservation and couldn’t find the command anywhere. Instead of clinging to single-word labels, let’s add a word or two for clarity. Make the second button “Cancel Reservation” and all is well. This example is so typical—often the difference between clarity and confusion is a single word. If you would say that extra word in person to make things clear, put it in the UI label. Add the word!!

▶ 28:13

world over knowledge in the head. Gaining “knowledge in the head” requires memorization, experimentation, documentation, or training—and you now know what that means.

▶ 28:59

Responsive feedback is a clear, accurate, immediate indication of the current state of an interaction or the resulting state. If an interaction has completed, users need a clear indication of completion and whether it succeeded or failed. Most feedback needs to be responsive to be useful—delayed feedback is inconvenient at best or misleading at worst.

▶ 29:11

To see how poor feedback leads to unintuitive interactions, consider a garage door remote control. When you press the button, the remote flashes a light for feedback. However, that feedback indicates that a signal was sent by the transmitter, not that it was received by the door, so that feedback is largely useless—it really only indicates that the remote is working. FIGURE 3-35 Garage door openers are often unintuitive because their feedback isn’t responsive. Neither the tactile feedback of the button nor the flashing LED reliably mean that the door is opening. The feedback we use to determine that the signal was received is the movement of the door itself. But given that the garage-door-is-moving feedback is laggy rather than responsive, it’s not uncommon to unnecessarily press the button again, which results in undoing the very thing we’re trying to do! Now the door has been told to open and to close, so the door stays closed. Having clear, accurate, immediate feedback (plus more forgiveness) would fix this problem.

▶ 29:33

Users need responsive feedback for both the current interaction and the resulting status. For interaction feedback, users need to know that the interaction has started and is either in progress or has completed. If successful results can be displayed quickly (under a second), the best feedback is to immediately (and clearly visibly) display the results. If more time is required (under 10 seconds), immediately display an activity indicator so that users know the task is in progress. If even more time is required (10+ seconds), display an accurate progress indicator with percentage complete feedback. Make sure that activity or progress indicators are displayed near the interaction.

▶ 30:36

Status feedback Indicating status—typically success, warning, failure; on vs. off; location—is an important part of responsive feedback. Status colors are often used in this feedback : green for success, yellow for warning, and red for failure. The interpretation of these colors is culturally dependent, but their meaning in the context of status is globally consistent due to the United Nations Conventions on Road Signs and Signals , so you don’t have to localize them. For accessibility, it’s important to consider that not all users can distinguish every color. Approximately 8% of adult males have a form of color confusion (a more accurate term for color blindness), so color must be used redundantly. I recommend designing in monochrome and making sure that status indicators have a unique shape or text label for each state. There are many tools that simulate the common forms of color confusion—an excellent way to make sure your designs are visually accessible. Responsive feedback is important when changing status so that users know the status has in fact been changed.

▶ 31:19

Predictability determines whether target users can accurately predict the results of an interaction before they initiate it. An interaction is unpredictable if target users are surprised by the results or any of its side effects. Discoverability, affordances, and comprehensibility set the stage before the interaction—predictability is the user’s assessment of how well the interaction’s results met expectations. Predictability is crucial for an intuitive interaction lifecycle because an interaction with surprising results or side effects is unlikely to achieve the user’s goals. Predictability determines whether target users can accurately predict the results of an interaction before they initiate it. An interaction is unpredictable if target users are surprised by its results or any of its side effects. An interaction can lead to unpredictable results in several ways. The results could be flat out wrong, users could be confused or misunderstand the design, or there could be a significant unexpected side effect even if the main outcome is as expected. Let’s examine each type of unpredictability that contributes to a UI’s unintuitiveness.

▶ 32:27

Unintuitive: Flat-out wrong In this case, an interaction is unpredictable because the behavior is just flat-out wrong—the outcome makes no sense for any likely scenario or prior experience. For example, a Back command should mean to the previously visited page (in its previous state), never clear or start over.

▶ 33:36

Unintuitive: Misunderstanding In this case, an interaction is unpredictable because users misunderstood it. As mentioned, comprehensibility affects predictability, so possibly the label was poorly phrased or misleading, or perhaps the user didn’t even read it. When using a product, users have expectations—formally referred to as a mental model —for how they believe the product works. For example, some users associate air conditioning (AC) with cooling, so good luck getting them to choose AC to dehumidify a car in the middle of winter.

▶ 33:57

For search, most experienced users expect that if a query has no matches, making the query more specific would be futile.

▶ 34:31

Natural mapping helps avoid misunderstanding. Natural mapping is when there is a clear relationship between what users want to do and how they should do it. Moving physical objects without natural mapping can be extremely unintuitive. For example, a car seat controller should look like a car seat—as opposed to the old fashion unintuitive bank of switches.

▶ 34:40

Unintuitive: Undesired side effects In this case, the overall result is predictable, but there are unexpected, frustrating, or even annoying side effects. A side effect is a secondary, possibly unwanted, result of an interaction. For example, consider viewing your Inbox in portrait mode on a mobile device, rotating to landscape and then back again to portrait, and landing on a completely different part of your Inbox or even in an email.

▶ 35:03

Users might not accurately predict an intuitive side effect, but they would definitely be confused by its absence. Here are some common interaction side effects that are potentially unintuitive: Moving Examples include navigating to different pages or scrolling the current page. Resetting Examples include resetting searches, filters, sort orders, selections, input or view modes. Deleting Examples include accepting a meeting invitation that results in deleting the invitation email as well. Order When filling out a form, users expect their input to possibly affect fields below the current field but never above. Changing modes Examples include changing the effect of taps or clicks. Make mode changes obvious, difficult to do accidentally, and very easy to revert.

▶ 35:33

Best additional ways to evaluate predictability Usability studies are a great way to evaluate predictability. I recommend putting extra emphasis on situations where users correct, redo, or abandon tasks. Discovering that users frequently tap Cancel is a clear sign of poor predictability. There is a simple way to evaluate predictability during design reviews: ask participants to guess the outcome of an interaction before you show it or explain it. Many incorrect predictions are a clear sign of a problem. Try this technique—it’s amazingly effective! You will be surprised by how many design problems you find .

▶ 36:20

Efficiency , in our context, determines whether the design helps target users perform their top tasks without unnecessary interaction or repetition. If a design interferes with user goals by requiring difficult, unnecessary, or highly repetitive interaction or by poor error handling, users will describe it as unintuitive (along with clunky and cumbersome) and rightly so. Generally, efficiency is broad enough for a book of its own (and that’s on my to-do list!), so here I’ll focus only on those areas where efficiency directly affects intuitiveness.

▶ 37:00

Unintuitive: Inefficient interaction Tasks with inefficient interaction are often the result of poor control sizing and poor layout. The interactive part of a UI element should be at least as large as its container/affordance.

▶ 37:36

For small targets, consider making the interactive target larger—possibly much larger—than the visible UI element.

▶ 37:51

Sticky menu bars and controllers are a great way to maintain context. Here, the TED app provides a sticky media controller so that you can explore while a video is playing.

▶ 38:00

Also, make sure that UI elements that are frequently used together are placed together. Users shouldn’t have to move across the screen or scroll to perform routine interaction combinations.

▶ 38:11

Appropriate defaults You don’t always exactly know what your users want. (If you do, you should just do it!) If you know with reasonable probability (based on the current context) what your users want, provide that value or result as a default. Doing so not only makes the interaction more efficient but also less error-prone. That said, make sure any defaults are valid. Accepting a default should never result in error, loss, or harm (or worse—see the sidebar at the end of the chapter). Even though you might not know what users want the first time they perform a task, you should have a better idea any subsequent time because the next input is very often based on or related to the previous input.

▶ 38:23

Consider first-time use a special exception for having appropriate defaults. Your app will know more on subsequent use. Here, after 12 years and many searches, Yelp still assumes that I’m in San Francisco, which is annoying. Even without location awareness, my last location is a better default.

▶ 39:07

Some notable exceptions: don’t default private information like passwords, social security numbers, or credit card numbers, and don’t use defaults to bias input that should be unbiased. Also, don’t draw drastic conclusions based on the current context.

▶ 39:27

Unintuitive: Forgetting or not using user input There’s often an even better default than the ones I just mentioned: the input the user entered mere moments ago. Unintuitive UIs ask users questions but then fail to take full advantage of the answers. If user input is important enough to ask for, it’s important enough to remember and reuse. For example, it’s common to require personal information during registration, such as name, email, phone number, address, etc., and then later require users to manually provide the same information elsewhere (for, say, how to be notified). At the very least, previously entered info should be used as the default. But it gets worse. It’s not uncommon for user input to get cleared due to some problem or the input not being entered in exactly the right sequence. And the more complex the input, the more likely this will happen, resulting in what I call Everett’s Law of Complex Input: The more complex the input, the more likely users will have to enter it more than once.

▶ 39:43

Some designers believe that error messages are the worst user experience and the best error message is no error message. But this is wrong—having confused users or making significant mistakes is far worse. We certainly want to avoid unnecessary messages, but intuitive UIs need necessary error messages. Otherwise, users are forced to think and experiment to deduce the problem on their own. What’s a necessary error message? Here’s a simple test: Write the error message (as best you can). If it’s informative, consider it necessary; if not, eliminate it.

▶ 40:46

If you must use an error window, be sure to display it only once—there’s nothing more annoying than dismissing the same error message repeatedly. FIGURE 3-60 Thanks for telling me…eight times in a row. Unnecessary errors like the one on the left can be really annoying. Display status contextually, as on the right, rather than displaying it as an error that requires dismissing.

▶ 41:23

OK, technically these email addresses aren’t the same, but email addresses aren’t case-sensitive. Furthermore, the keyboard defaulted to uppercase for

▶ 41:48

Another common example is when apps fuss over capitalization/case, punctuation, and whitespace, such as unnecessary leading or trailing spaces.

▶ 41:58

FIGURE 3-64 I typed the coupon code correctly—except that it was supposed to be all uppercase. Why does case matter for a coupon code? And good to know that it’s error code 620 and not 621 or 619. Oh, and thanks for clearing my input on error.

▶ 42:08

One last example is when search is overly fussy, returning results only for literal exact matches. This problem includes searches that can’t handle different spellings (like Wi-Fi vs WiFi), similar words (like car vs. auto), plurals vs. singular, common abbreviations (like USA vs. United States), or common misspellings. We need to change the old saying: almost only counts in horseshoes, hand grenades, and intuitive search.

▶ 42:27

Unintuitive: Unnecessary restrictions/annoyances Unnecessary restrictions are those that interfere with users achieving their goals by requiring unnecessary interaction or repetition. A good example is requiring users to select a single item at a time when the task requires selecting multiple items.

▶ 42:56

Forgiveness assesses whether an interaction prevents mistakes, minimizes the negative impact of mistakes, or makes mistakes easy to recover from. Intuitive apps assume that small mistakes are common, and they accommodate these mistakes. By contrast, unintuitive apps are not forgiving and result in a significant loss of work or inconvenience, such as forcing the user to completely redo the task. Unforgiving apps tend to result in many mistakes incorrectly attributed to “human error.”

▶ 43:15

Start Over—the official onramp to the unhappy path.

▶ 43:46

To make a UI intuitive, the unhappy path needs to be designed just as carefully as the happy path, but in practice it is rarely considered.

▶ 43:50

Preventing mistakes While not well known, the best approach to forgiveness is to prevent mistakes in the first place. It’s impossible to prevent all mistakes generally, but we can and should prevent users from easily making mistakes. Perhaps the best example is that most buttons take effect on tap-release or mouse-button-up instead of tap-down or mouse-button-down. Doing so gives users an opportunity to abandon an unwanted command by moving off the control before release.

▶ 44:00

The worst place for a Trash command? How about directly over the Home button, where it is begging to be tapped accidentally when you mean to press the Home button. If you are an iPhone user, you have probably done this many times without even realizing it.

▶ 44:28

For touch-based interaction, targets need to be at least 9mm square for accuracy and even larger for comfortable, mistake-preventing interaction. Prefer big, fingertip-sized targets whenever practical. Consult your platform’s guidelines for additional sizing recommendations. FIGURE 3-74 For accurate touch-based interactions, 9mm square is considered the minimum size. Larger is better. For touch-based interaction, spacing can be as important as sizing. Put enough space between interactive UI elements to prevent accidental touch. Again, consult your platform’s guidelines for spacing recommendations.

▶ 44:44

Undo Undo is the classic forgiveness feature, and your app should provide Undo whenever practical. Unfortunately, it’s not always practical to provide Undo—often for performance reasons—as we’ll explore in detail in Chapter 5, so your app needs to be forgiving in other ways. Another challenge with Undo is that its implementation is often unintuitive because its results are not predictable. Moderately experienced users should be able to accurately predict the effect of an Undo command. And if your app does anything automatically, make sure any immediately applied Undo command undoes the automatic effect. Use a broad interpretation of Undo. Don’t just think about an Undo command—also make sure that every uncommitted command has an opposite. Every OK needs a Cancel, every Add needs a Remove, every Forward needs a Back, every Accept needs a No Thanks, every Open needs a Close, and so on.

▶ 45:25

Easy recovery Once a user makes a mistake, make it easy to fix. Make items easy to edit, make it easy to enter edit mode, easy to abandon changes if unwanted, and easy to go back where the user came from, without completely starting over. History features are very forgiving. Be sure to not clear erroneous input—let users choose to clear instead. For multistep tasks, always have a Back.

▶ 46:24

Explorability determines whether target users can use your app without fear of getting lost or making significant mistakes. A good antonym for explorable is hazard-prone. (By contrast, a good antonym for forgiving is error-prone .) An explorable app builds the user’s confidence and sense of mastery. Explorability is a higher-level attribute than the others—it’s possible for an app to have the other seven attributes yet still feel unintuitive if it lacks explorability. Top causes for poor explorability are confusing, nonstandard navigation models and unclear, nonstandard commit models.

▶ 46:54

Confirm destructive actions We already covered the need to confirm destructive actions in the “Forgiveness” section, but the examples there were fairly routine (such as accidentally clearing a calculation). For actions with significant consequences, explorability requires both confirmation and awareness. It should be impossible for a user to permanently delete a photo album, for example, without a confirmation that demands the user’s attention. (This is an unfortunate accident that I have personally experienced. It was surprisingly easy to do.) The challenge is that over-confirming leads to habituation. Verifying everything is practically the same as inconveniently verifying nothing—users quickly learn to ignore routine confirmations. The best solution: Draw special attention to actions with significant consequences, and don’t bother confirming insignificant actions. Make the safest choice the default. I recommend such confirmations even if there is an Undo (such as a Trash Can or Recycle Bin to recover the files). The reason: Undo is helpful only if the user is aware that there is something to undo. Significant irreversible destructive actions should require users to make two consecutive mistakes, not just one.

▶ 47:33

Clear commit models An app’s commit model determines how changes are committed or discarded and how users navigate to the next step in a task. There are two common models: explicit save and instant commit . Explicit save means that users must explicitly save any changes or they will be abandoned, whereas instant commit means any changes are applied immediately. Although either model can support Undo, the explicit save model is the better choice when users need to be able to explore without fear. Your photo editor app better use explicit save or I’m not using it ! For your app to be explorable, you need to choose the right commit model and make it visually obvious which model you are using—at a glance, without scrolling. Support Undo and Revert as necessary. Users should never be surprised to discover which commit model is being used. The worst possible surprise: a complex multi-step explicit-commit-at-every-step task with the commit buttons below the fold, where the user completes the task only to discover that nothing was saved. (Many of us who have configured a wireless router can attest to this pain.)

▶ 48:48

Building confidence Confidence is a feeling users have when they believe that they are doing the right thing and their goals are being satisfied. Users need to feel confident when using your app—especially for tasks that have consequences.

▶ 49:58

This is a familiar design pattern, and it illustrates how all the visual and interactive elements work together and how to justify every design decision based on the Eight Attributes of Intuitive UI. Let’s start with the simplest, unintuitive UI, which would be to have Search hidden behind a hamburger menu: FIGURE 3-91 Putting Search in a hamburger menu isn’t discoverable . This design lacks discoverability. To make the feature discoverable, we should put Search directly on the screen. If the primary purpose of the page were to find things, the search box would go prominently in the top center, but because search is secondary the upper right would be a better choice. Search needs a text box. For affordance, the dark-gray bordered box plus a flashing caret on focus indicates that the text is editable. The width of the text box indicates the size of the expected input—in this case 30 characters. FIGURE 3-92 Putting search in upper right makes it discoverable . The text box border, caret, and width are affordances for editable text and length of expected input. As is, the user would have to type Enter to perform a search. To make the Search command discoverable, it needs a Search button. The button should be placed at the right of the search text box to make the relationship between the two controls predictable (because the flow matches reading order). Applying Everett’s Rule for Custom Icons , we can safely use the standard search icon here. FIGURE 3-93 Adding a search command button with the standard search icon for discoverability , affordance , and comprehensibility . This search box is resizable, so we need to add a resize grabber for discoverability and affordance. On hover or tap, the cursor changes to reinforce both, plus indicates the direction of resize. FIGURE 3-94 Adding a resizable grabber for affordance . Once the user taps the Search button, the interaction needs to provide responsive feedback. There are a couple of possible solutions: If the app is designed to return research results immediately, just start to display them. This is the best solution, and this is what made Google search famous. Another solution would be to display an activity indicator, either where the search results will be displayed or in the Search box itself. FIGURE 3-95 An activity indicator for responsive feedback . Immediately returning results would be better. With the basic search mechanics done, let’s now focus on making the search functionality obvious. Being able to search for people, companies, or groups is not obvious from context, so let’s add a placeholder to the text box to make that clear. FIGURE 3-96 Adding the “Search for people, companies, groups” placeholder for comprehensibility and predictability . Target users might not know exactly what they are looking for. For example, suppose the user is looking for someone named Elizabeth Smith. Should the user search for Elizabeth…or Beth, Lisa, Liz, Liza, Eliza, Betty, Bettie, Betsy, or Lisbeth? Would an intuitive UI return no matches for Elizabeth Smith when there are matches for Liz Smith? If we are designing a tool to help users find people, shouldn’t the design actually help users find people? Of course it should, because intuitive UIs are efficient. FIGURE 3-97 Efficient search returns results based on users’ intent, not their literal input. On occasion, users might search for a name and get the wrong type of results. For example, let’s assume that the name Everett McKay is extremely common, with thousands of people and dozens of companies having that name. For efficiency, users might want to search for a specific category. While we could attempt to use custom icons for this purpose, let’s apply Everett’s Rule for Custom Icons and use icon+text label pairs instead. FIGURE 3-98 An efficient search for specific categories. Users repeat searches, so for efficiency let’s facilitate repeats. FIGURE 3-99 Adding a most-recently-used dropdown for efficient repeated searches. But once users start typing, they are indicating more specific intent. For efficiency, let’s adjust the content of the dropdown to show still-relevant recent searches, plus make relevant suggestions. FIGURE 3-100 Adjusting the most-recently-used dropdown based on user input for efficient repeated searches. Finally, users often make small mistakes, so what if users type a search that was close but not quite? They should be able to change the search and try again, rather than completely start over. But surprisingly, some search UIs immediately clear themselves or don’t allow for modification—very unforgiving. Instead, we can let users decide when to clear by providing a clear command in the text box. FIGURE 3-101 Our final design: adding a Clear command for forgiveness and efficiency . Instead of applying this process, we could have just chosen the standard search box pattern. FIGURE 3-102 The standard search box pattern, without applying the Eight Attributes of Intuitive UI. But the results would not be intuitive. Users would have to think, experiment, and deduce how the interaction works because this design makes no effort to be self-explanatory. Applying the Eight Attributes of Intuitive UI helps you get the details right and defend and prioritize those design details to your team.

▶ 50:12

Let’s define familiar as an assessment of whether target users can apply previously learned knowledge to the current interaction, and let’s explore a few examples. We’ll start with light switches—what UI could be more familiar? Light switches are very familiar, but are they intuitive? If they were, you should be able to accurately predict the result of flipping the switches. Before you answer, let me give you a hint—suppose these switches are in a hotel bathroom. Another hint: the leftmost switch turns on the bathroom fan. Not intuitive, right? And if you’re like me, you have discovered this problem by taking a shower and then, after your shower, realizing there was a fan you were supposed to turn on first.

▶ 55:50

Although very familiar, door handles can be unintuitive. The need for a label is a clue there’s a problem. Note that the handle’s design says pull but the label says push.

▶ 56:33

With these examples, I hope you see the problem. If we equate intuitive with familiar and decide that a specific UI element is familiar and therefore intuitive, we can easily be misled. The Eight Attributes of Intuitive UI are a much better indicator. Take a look again: the vertical speed gauge is intuitive not because it’s familiar but because it has the right design attributes. Familiarity is a secondary attribute that affects discoverability, affordance, comprehensibility, and predictability. When poorly designed, familiar UIs are likely to confuse or mislead because they set incorrect expectations.

▶ 56:45

But where do users get that prior knowledge? It could be based on domain knowledge. It could also be based on prior experience with your app—things your users have learned with the current version or even prior versions. An important perspective is based on Jakob Nielsen’s Law of the Internet User Experience , which I have taken the liberty to generalize to the following: Users spend most of their time using software other than yours.

▶ 57:25

This simple observation is quite profound. Your users’ understanding of where to discover features; how to interpret affordances, labels, and icons; and how to predict outcomes accurately is based on their prior experience with all other software. If your app is inconsistent with your target users’ prior experiences, it’s your app that is unintuitive. Reassigning a standard shortcut or gesture might seem sensible to you, but the lack of consistency will confuse your users. Surprisingly, this means that we can have designs that are clearly missing intuitive attributes (like discoverability and affordance), but target users will still consider them to be intuitive based on conventions/idioms they have learned with other apps. Let’s consider some common idioms: interactive logos in the upper-left corner of a page (to go Home) and interactive item headings and images on a summary page (to go to the item’s page). Experienced users will know to tap these without hesitation. Still, it’s wise to use them as shortcuts and have discoverable alternatives with clear affordances.

▶ 57:51

great way to achieve consistency is to make sure your team is familiar with your app’s platform guidelines. For iOS, check the iOS Human Interface Guidelines , and for Android, check both the Android Design Principles and Material Design Guidelines

▶ 59:00

I have seen many examples of bad consistency over the years—it’s a very easy trap to fall into. When in doubt, a simple question to ask is, “What does this consistency accomplish?” If the only answer you can give is “Consistency!” your design might be better off without it. FIGURE 4-13 Making all the fields a uniform length doesn’t make this form easier to use or understand. Rather, it makes it harder to scan or understand the size of the expected input. The version on the right is better. Consistency is a secondary attribute that affects discoverability, affordance, comprehensibility, predictability. But watch out for bad consistency

▶ 59:17

Many people believe that intuitive UIs are easily learnable. On occasion, you might hear someone assert that a product is “intuitive once you learn how to use it.” Surprisingly, this is wrong! As you’ll see in Chapter 5, an easily learnable UI can be described as highly usable, but the goal of an intuitive UI is to avoid the need for learning in the first place—making learnability merely a consolation prize. (So, saying a product is “very usable once you learn it” is a more credible claim.) Interactions that require learning are often that way because they are poorly designed and users must learn to overcome design flaws. (Catastrophic and embarrassing outcomes are, unintentionally, a particularly effective learning tool.) If you discover that your design requires learning, try to find a simple alternative that eliminates the need. Often, you can.

▶ 59:57

The first morning, I looked at the controller and noticed that the indicator suggests I should rotate the top knob left to turn on the shower. I did so and it worked as expected. The second morning? I looked at the controller and noticed that the indicator suggests I should rotate the top knob left to turn on the shower, which I immediately did. The third morning? Same thing . But what did I learn? Nothing! I didn’t have to learn anything because the design is intuitive. In effect, I relearned how to use the shower controller each morning, but I didn’t retain the information nor did I need to. If I had to memorize or experiment, that would reveal a design flaw. This is exactly as it should be—if a design has the appropriate attributes of intuitive UI, there is no need to learn anything. Learnability is required only when any important intuitive attributes are missing. Remove the legend, for example, and I would have to learn how to use the shower controller through experimentation and memorization.

▶ 60:49

While important, learnability applies more to not quite intuitive design than to intuitive design. For most interactions, your design goal should be to eliminate the need for learning in the first place. Learnable is a secondary attribute that compensates for when any of the Eight Attributes of Intuitive UI are missing. Learnability isn’t the goal; it’s a consolation prize.

▶ 61:49

Poorly designed UIs require thought, and invisible here means that users aren’t thinking about the UI. We are not using “invisible” literally—whether users actually see anything on the screen is beside the point. (In this sense, a poorly designed voice-based interface could be very “visible” if it’s distracting.)

▶ 62:11

But all too often, invisible UI is interpreted as “the best UI is no UI”—this interpretation is very wrong. Instead of trying to correctly interpret invisible or worrying about flow, focus on the Eight Attributes of Intuitive UI.

▶ 62:32

If making a UI “invisible” enhances those attributes (by doing the right thing automatically, for example), embrace it. But if making a UI “invisible” harms those attributes (for example, by affecting discoverability, affordance, or feedback), reject it.

▶ 62:51

Confirmations, by their very nature, are flow stoppers. The user just gave a command saying, “I want to do this” and the confirmation stops the user to ask, “Are you sure you want to do this?” Of course, the answer is yes—often with a groan. But properly designed confirmations give users a good reason not to proceed, instead of routine “double checking.” A good confirmation forces users to stop and think—by design. And if there is a good reason not to proceed, the confirming step is intuitive and doesn’t unnecessarily harm flow. American Airlines Flight 965 to Cali Colombia tragically crashed into a mountain due to “pilot error,” specifically because a pilot incorrectly programmed the flight system. A good confirmation might have helped prevent this disaster. FIGURE 4-17 Also a flow stopper, but rightly so and still intuitive. Yes, sometimes you must make the user think! Invisible and flow are secondary attributes that, while important, are vague and easily misinterpreted.

▶ 63:07

And for the fun of it, let’s explore one more bonus attribute: digestible . People occasionally describe an intuitive UI as easily digestible. But what exactly does that mean? Literally, it means that it can be consumed and eventually pooped out. Hopefully, what digestible is really supposed to mean is easily comprehensible , which of course is one of the Eight Attributes of Intuitive UI, or perhaps scanable . UX professionals use too many vague, abstract terms or metaphors to describe design concepts. Because such language lacks practical, specific meaning, these terms and metaphors make it difficult to communicate your ideas persuasively to your team. Everyone needs to interpret what these metaphors mean, perhaps differently.

▶ 64:10

It’s surprising how much impact a meaningful vocabulary can make. If you tell me my UI isn’t digestible, I have no idea what that means or what to do about it. But if you tell me a UI element isn’t discoverable, has a misleading affordance, or has a label that isn’t comprehensible, I know exactly what that means and I know exactly what to do about it. The discussion transforms from being personal and subjective to being objective and actionable.

▶ 64:57

Let’s ditch the metaphors too! Try to get your team to use more meaningful language during design decisions. Explain why it is important with some good examples. If someone describes a UI as being digestible (or smooth, frictionless, or natural), ask “What exactly does that mean?” or suggest a more specific, meaningful term, as with “By digestible do you mean comprehensible?” The sooner you get rid of that vague language and questionable metaphors, the sooner your team will have more productive design discussions. You will be pleasantly surprised by the difference! Have design discussions using a specific, meaningful vocabulary. It’s very difficult to have productive discussions based on vague, abstract terms and metaphors. When appropriate, ask team members to define the terms or propose alternative language

▶ 65:26

Significant destructive, irreversible actions Irreversible and destructive actions with significant consequences should require thought—and lots of it. They shouldn’t be efficient; users should have to go way out of their way to perform them.

▶ 66:16

Shortcuts and gestures are usually not discoverable and lack affordance, but this doesn’t have to be the case. Keyboard shortcuts are often discoverable in desktop software, for example, through their documentation in menus and tooltips.

▶ 66:31

Although shortcuts and gestures are generally a good thing and will make expert users happy, don’t overdo them. Both can be frustrating and annoying if users trigger them accidentally. If users perform disorienting gestures accidentally, they will definitely not be impressed by the intuitiveness of your app.

▶ 66:47

The top level of usable but not fully intuitive is sensible , which might lack discoverability or affordance, but a sensible interaction is so natural that users will quickly experiment and discover that it works as expected. (Here, natural can be defined as similar to real-world behaviors or well-known standard interactions or conventions.) Users would describe such interactions as intuitive, even though they don’t strictly meet our definition of intuitive, because they require only trivial thought and experimentation. A good example here is horizontal swipe to navigate from one photo to another.

▶ 67:07

The next level is learnable , which might also be missing discoverability or affordance and which isn’t nearly as obvious as sensible. I’m calling this learnable because users often learn these interactions by observing others. Users still might describe such interactions as intuitive, even though they don’t meet the definition. Good examples are spread and pinch gestures to zoom in and out of an image, or perhaps the power + some other button sequence for screen grabs. These gestures are easy to learn—once you see someone else do them—but you might not figure them out on your own.

▶ 67:44

What about onboarding and coach marks? It’s common to see onboarding and coach marks being used to help users understand features and interactions, especially in mobile apps. Onboarding is a brief overview of an app that is displayed on first launch and that often explains how to use its (frankly) unintuitive features. By contrast, coach marks call out and explain the various features on a single page on demand.

▶ 68:19

There are practical problems to these strategies: onboarding and coach marks make your app appear hard to use and unintuitive. Onboarding requires memorization and coach marks are a form of documentation, so by definition your app has announced it’s not intuitive. They are also very easy to skip, which is by design, of course, but users often skip onboarding in particular because it appears at the wrong time. Users want to experience and explore your app first and learn the details later, when they’re ready and motivated. To paraphrase Don Norman: if your app’s interaction needs coach marks, its design is probably faulty. Are onboarding and coach marks a good idea? They might be in special circumstances, but my assessment is usually not. The simplest way to decide is to ask, “Is there a practical alternative design that makes onboarding or coach marks unnecessary?” Almost always the answer is Yes. Nonstandard interactions are usually unnecessary and always risky . If your app has nonstandard gestures (that are hopefully redundant), the best approach is to display focused coach marks contextually, when the user is likely to use them and are motivated to learn them. If the gestures are especially useful, you can display them automatically in context—otherwise display them on demand.

▶ 68:45

All this said, I am not completely opposed to onboarding. Like a modern user’s manual (discussed in Chapter 1), effective onboarding should focus on demonstrating the app’s value, not on explaining confusing, unintuitive UI. Selling your app’s value is crucial to its success, and effective onboarding can be perfect for that purpose. Don’t assume that users will immediately figure out your app’s value themselves—or spend a lot of time doing

▶ 70:05

Summary There’s a cost to making a UI intuitive, and sometimes it’s not worth paying the price or sometimes other considerations are more important. Shortcuts and gestures are common examples—they are great to have but not worth making intuitive. Using the Levels of Intuitiveness will help you make the right compromises. Remember that if an interaction can’t be fully intuitive, making it sensible or learnable is a good alternative. Although a trainable UI can still be usable, requiring training will lose many users. But most importantly, make sure you design unintuitive interactions strategically rather than accidentally. All too often unintuitive interactions are purely accidental.

▶ 70:33

You might now be thinking that there can’t possibly be anything left to cover. Actually, there is—what you have learned so far is all you need to design an intuitive individual interaction, but what about a higher-level task flow in which multiple steps are required for a task to be successfully completed? For example, suppose that you’re designing the checkout process for an e-commerce app. Could you design all the individual interactions to be intuitive but still have an unintuitive task flow? The surprising answer is yes! In fact, this happens quite often. You need higher-level thinking to design intuitive, self-explanatory task flows—to eliminate the need for users to think, experiment, memorize, or read documentation to get tasks done. In this chapter, you will learn simple techniques to achieve this goal. Just as a user manual is a clear sign that a UI isn’t intuitive, the need for an external checklist is a clear sign that a task flow is unintuitive. The reason: A checklist is a summary of the important information needed by a user to perform a task that a UI simply fails to make obvious.

▶ 71:18

Crucially, inductive UIs answer that first question all users have when they see a page for the first time: What am I supposed to do here?

▶ 72:27

If putting explicit instructions on a page strikes you as an odd idea, consider that we put titles on practically everything else to make them self-explanatory. Books have titles, chapter names, subheadings, figure captions, and so on. Imagine a book without chapter titles—users would have to read many pages just to figure out what a chapter is about. Too many task flows are like that.

▶ 72:36

In Don’t Make Me Think, Steve Krug boldly claims that “instructions must die.” Do yourself a favor and ignore such advice. Removing good instructions requires more thought from users! As a designer, you have ultimately three options when designing tasks: Option 1: Make all your screens self-explanatory without instructions. Option 2: Make all your screens self-explanatory with instructions. Option 3: Depend on experimentation, documentation, training, and tech support to get users through tasks. A harsh reality check: Option 1 is very difficult to do, and all too often ends up being Option 3. Option 2 is the way to go.

▶ 73:00

We took the “scenic route” to design this main instruction, but normally you can get to a good instruction more directly. Think about what you would actually say to the target user, make sure it is useful and specific, and then get rid of any unnecessary words. That’s where you want to be. Design task flows by designing the main instructions first and then using them to design the pages. Choose concise main instructions that match what you would say in person.

▶ 73:44

If I had an hour to solve a problem and my life depended on it, I would use the first 55 minutes determining the proper question to ask, for once I knew the proper question, I could solve the problem in less than five minutes. –Albert Einstein That “proper question” for intuitive page design is the main instruction. When to not display a main instruction At this point, I hope it’s clear that the inductive UI concept—using main instructions to design self-explanatory pages—has tremendous value. The concept isn’t about having chatty pages with silly instructions that clearly aren’t necessary. Rather, it’s about designing intuitive task flows and pages with integrity. It’s about eliminating the need for training and documentation at the task level. That’s a huge benefit from such a simple technique . Still, as a UX design trainer who instructs dozens of workshops per year, I have noticed that although some designers eagerly embrace the concept, many designers are terrified to put instructions on their pages, even when the need is obvious. How do you tell when the need is obvious? Easy: during a design presentation or design review, the first thing the designer explains is the missing main instruction for a page. If that instruction is important enough to explain explicitly when the designer is in the room, it’s clearly important enough to state explicitly when

▶ 74:12

When to not display a main instruction At this point, I hope it’s clear that the inductive UI concept—using main instructions to design self-explanatory pages—has tremendous value. The concept isn’t about having chatty pages with silly instructions that clearly aren’t necessary. Rather, it’s about designing intuitive task flows and pages with integrity. It’s about eliminating the need for training and documentation at the task level. That’s a huge benefit from such a simple technique . Still, as a UX design trainer who instructs dozens of workshops per year, I have noticed that although some designers eagerly embrace the concept, many designers are terrified to put instructions on their pages, even when the need is obvious. How do you tell when the need is obvious? Easy: during a design presentation or design review, the first thing the designer explains is the missing main instruction for a page. If that instruction is important enough to explain explicitly when the designer is in the room, it’s clearly important enough to state explicitly when the designer isn’t there so that users understand how to use the page.

▶ 75:37

Another situation when the need is obvious: when users must scroll the page to figure out what to do. Modern responsive design often results in an extensive scrolling (who decided that’s a good idea?), so this is especially a concern with responsive design. Reports of the demise of designing “above the fold” (that is, content users can see without scrolling) are greatly exaggerated. Users should never have to scroll to determine if they are on the right page or the purpose of the page. See the next section for more on this problem.

▶ 76:46

What about responsive design? Most modern websites are using responsive design , which uses flexible layouts, images, and styles to adapt to any screen size and orientation. Responsive design often results in tasks that require scrolling through very long pages instead of navigating to shorter ones. Doesn’t responsive design change everything? Surprisingly, not really. Let’s take a look at why that’s true. Responsive designs often have a significantly different task flow model , where users interact using the following steps: Review the large, mostly useless hero image (a large, prominent banner image) above the fold to recognize visually that this is a responsive design. Do not find what they are looking for, so start scrolling. Scroll, scroll, scroll. Scroll, scroll, scroll. Find the large, mostly useless fat footer to visually recognize that they have finally reached the end of the interminably long page. Desperately hope that perhaps what they are looking for is hidden in the hamburger menu. Try a command in the hamburger menu. (Nope, not there either—commands there just scroll to a section on the page.) I’m exaggerating a bit, but this is the unfortunate (and unnecessary) state-of-the-art responsive design style at the time of this writing. Misuse of the responsive design clichés often results in what I call Terrible UX from Responsive Designs ( or TURDs ). Responsive task flows are often not broken into pages but into sections instead. I believe the need for good instructions is actually even stronger for these responsive page sections than for more traditional page-based design. Here’s why: Having instructions—you might call these section instructions —helps users scan the page sections. Users shouldn’t have to read the sections carefully to figure out what they are for. Remember the first question that all users have: What am I supposed to do here? Navigating to a page provides context and indicates intent, whereas scrolling gives no context. In traditional page-based navigation, the user has to perform an explicit action to navigate to the next page, and this action provides context. For

▶ 77:20

Summar y The first question all users have when they see a page for the first time is: What am I supposed to do here? Surprisingly, we rarely answer this question in our designs, but doing so is required for intuitive task flows. Intuitive task flows are easily explainable, so start your page design by focusing on explainability. Having main instructions not only makes pages self-explanatory (reducing the need for documentation and training), but also helps ensure that those pages’ designs have integrity and focus. Best of all, explainable first makes your overall design process more efficient by helping you find task flow problems sooner. Designers are often afraid to put main instructions on their pages. If the purpose of the page isn’t obvious, give the instruction explicitly. (When in doubt, just do it!)

▶ 79:30

Furthermore, a merely usable UI isn’t that high of a bar. (Aaron Walter aptly compares usable design to edible food. You can and should do better.)

▶ 80:23

The bottom line: On its own, one round of usability testing isn’t likely to be enough, regardless of the number of participants. For your team to do its best work, it must be able to find routine design problems on its own, without being dependent on usability testing. To be efficient, reserve usability testing for the hard-to-find design problems that you can’t readily find. This will reduce the number of rounds of usability testing required. While usability testing is the most dependable measure of success, you can make it more effective and efficient by preceding it with expert evaluation techniques to find routine design problems first.

▶ 80:35

Use the importance of the interaction plus the Levels of Intuitiveness (from Chapter 5) to see if there is a problem. Use the Eight Attributes of Intuitive UI (Chapter 3) both to help determine the Level of Intuitiveness and to identify what specifically needs improvement. Not everything has to be fully intuitive, but you should avoid designs that require training and documentation.

▶ 81:16

You assess the interaction for the Eight Attributes of Intuitive UI, using a simple Pass/Fail for each attribute. Is it plausible that the target users would agree that the attribute is present? If so, that’s a Pass. If an attribute is missing, ask whether it’s plausible that the target users would agree that the attribute’s absence isn’t a problem. If that answer is yes, that’s also a Pass. If not, it’s a Fail.

▶ 81:41

I find this grading is fairly easy to apply, but it’s important that you check your personal knowledge of how the UI works at the door. Make these assessments based on what target users already know or see on the screen, not on your own experience with the app. The fact that you and your team know exactly how it works means nothing.

▶ 82:08

For the Levels of Intuitiveness, I use the following grading: Sensible Does the interaction follow well-known standards, apply real-world conventions, or match knowledge from the target user’s prior experience? If so, it’s sensible because there’s a realistic chance that users will quickly figure it out through a little thought or experimentation. Learnable Is it like sensible , but most likely users quickly learned it from somebody else instead of on their own? If so, that’s learnable by definition. Guessable Does the interaction follow a pattern that isn’t well known to the target users or is inconsistently applied? Is there a realistic chance that users will figure it out on their own with sufficient experience? If so, that’s guessable . Trainable Did you have to ask for help, check documentation, or search the web? If so, it’s trainable

▶ 82:29

Working at a higher level of UX persuasion, having a tested (not hypothetical) solution, presenting it to your team with an objective design vocabulary, and showing that solving the problem leads to reducing costs with real numbers—this approach wins

▶ 83:18

(While often referred to as user testing , usability testing makes it clear that you are testing the design, not the person—an important distinction.)

▶ 83:35

Successful usability testing is the least subjective measure of intuitive design. After all, we can agree that our own designs are fantastically intuitive, but none of that matters if actual target users can’t get real tasks done.

▶ 83:44

Usability testing is the ultimate measure, but it’s fairly time- and labor-intensive. Here’s a summary of the steps involved: Determine the goal of the study and metrics for success. Have something to test (real product, prototype, MVP). Create a list of tasks for users to perform that achieves the goals of the study. Set up the test environment; do a trial run to find and fix problems. Recruit participants from real target users. Perform the study; record the results. Analyze the results; make a list of recommended changes.

▶ 83:59

Conclusion As a modern UX designer, a crucial part of your job is to design UIs that your target users can understand immediately on their own, without reasoning, experimenting, memorizing, training, or reading documentation. Your users expect this now, and they are no longer motivated to spend time learning your app, reading documentation, or getting training. You now know what it means to be intuitive (by definition), the specific attributes required to make a UI intuitive, and how to evaluate intuitiveness without relying solely on user testing. That said, you appreciate that not everything needs to be intuitive as other design tradeoffs might be more important, and you know how to make those tradeoffs strategically rather than accidentally. You have a better vocabulary that you can use to discuss intuitive UI with your team persuasively, without resorting to subjective personal opinion, analogies, or metaphors. You also understand that ultimately a UI is intuitive only if your target users demonstrate that it is by performing the top tasks smoothly and effortlessly. The goal of this book isn’t to replace usability testing, but to make it—as well as your overall design process—more effective and less expensive. Remember the Manifestation of Intuitive UI : You observe that users successfully complete tasks on the first try consistently, without making mistakes. If that’s not the case for your app’s important interactions, you have more work to do.

▶ 84:35