How to Design Interfaces That Stay Easy to Use, Not Just Easy to Learn (Chapter 1 of Learnability Isn’t Enough)

In honor of the launch of the hardcover edition, I’m sharing the first chapter of my UX book (titled Learnability Isn’t Enough: How to Design Apps That Are Easy to Use in the Long Run, Not Just the First Run).

In the chapter below, you’ll get an introduction to a framework that helps you to catch harder-to-find usability issues, helps you understand how to get the most of of your team’s design resources, and teaches you how to make changes to your app without upsetting your users. All this is done by making a novel distinction between sources of temporary and permanent UI effort.

I truly hope this is as helpful to you as it has been for me.

While better learnability is valuable, it doesn’t necessarily make an app easier to use day to day.

Surprisingly, it’s often the reverse — things that make an app easier to figure out can actually make it more difficult to use overall. This point isn’t immediately apparent to many folks, and I was no exception. For years, this was at the root of many issues with my own design work. But now that I know what to look for, I see this happening everywhere. It’s extremely common, and often leads to angry users and wasted time. In the worst cases, it can even result in a failed product.

Thankfully, you can avoid all this once you know how.

This book will teach you how to design app interfaces that are easy to use in the long run, not just the first run. Ahead, you’ll learn how to avoid the issue I just mentioned and achieve better results with less wasted time, effort, and user pain.

“Now that you’ve pointed it out, it seems crazy we haven’t been doing this already.”

— My former product manager

A mistake anyone can make

Learnability and usability are different things.

Unfortunately, they are often discussed interchangeably, with people tending to say that a change has made things “easier” when what they often mean is that it’s “easier to figure out.” But as mentioned a moment ago, it’s possible for a learnability improvement to ultimately be worse for overall ease of use. In other words, easier to learn can mean harder to use overall.

When we forget to distinguish between learnability and usability, it can lead to incorrect priorities and false confidence. I’ve seen it happen everywhere from industry giants to the smallest startups. The way we use language often creates a barrier to making this distinction clear, so it’s absurdly easy to get this wrong.

And when teams do get this wrong, the results can be disastrous.

In fact, while I was writing this book, a software update was released for Tesla vehicles that many drivers didn’t like. The new interface moved some controls into more logical and easier-to-understand menus. But as a result, it now required 2 to 3 steps to access certain controls that used to be available with a single tap or swipe. It occurred to me that this fit the pattern. These issues resulted from the interface being made easier to learn at the cost of being harder to use day to day.

So, on a lark, I made a prototype showing how they might resolve many of these complaints by making a simple change. I proposed a straightforward way for drivers to add shortcuts back to the main screen. With this change, these common controls could once again be accessed with a single tap. This idea was really nothing extraordinary, but it made a specific and targeted change. With it, the interface would require less effort to use day to day while retaining all the learnability benefits provided by the new menu system.

I posted my proposal online and asked for feedback from owners. Unexpectedly, it quickly went viral and was shared and viewed hundreds of thousands of times in a matter of hours. Soon, Tesla news sites had written articles about it. To my surprise, one of these articles even prompted a response from CEO Elon Musk himself. Unfortunately, he took the position that the change wasn’t necessary.

To say that this frustrated some people would be an understatement. The pushback he got from this was, at the time, the strongest reaction I had ever seen from the Tesla faithful. Some fans called him arrogant; others said the company had lost its way, and at least one owner sold their car and swore they’d never buy another vehicle from the brand again. A major magazine published an article amidst the backlash, and a former presidential candidate even weighed in on the situation.

Yikes.

Ultimately, three months later, the company did make the change. But in many ways, the damage to the brand had already been done.

Admittedly, the issue with this interface might seem obvious when we look at it through this framing. You might be tempted to write off design teams for being foolish enough to have made mistakes like these in the first place. But I believe these issues are the natural consequence of a larger issue with how we think about and discuss ease of use. This mistake often happens by default — it is commonplace.

Yet as mentioned earlier, when you know what to look for, you can often avoid these issues before users feel the resulting pain. This can spare you from the dramatic consequences that sometimes follow. With the tools in this book, you’ll be able to make major design changes while minimizing your risk of user backlash like this.

Usability testing can be deceptive

These new tools provide insights that typically come later in the design process. This is helpful because our usual tools and processes will often leave gaps in our knowledge until after a product has shipped.

This first became clear to me a few years ago while I was working on a tool that healthcare professionals would use in hospitals. It was an app they would use in life-or-death situations, so I wanted to take every precaution to ensure that we did things right. We did extensive usability testing, and we occasionally had the chance to shadow users as they worked, as well. While walking with one of these users through a hospital, I heard them use an expression that was new to me. It was an expression that was commonly used in the stroke ward to communicate a sense of urgency:

“Time is brain.”

That grabbed my attention. Here, every second wasted led to a worse outcome, so day-to-day efficiency was vital for these people. I suddenly wondered — how could we ensure we were doing a good job at this ahead of time, before we’d built anything?

I thought about the usability testing we were doing. It was the typical best practice of putting changes in front of people who had never seen them before, and asking ourselves questions like “Did they know what that meant?” and “Were they able to figure it out?” Whenever an interface made it through this process with few complaints, we would determine it to have successfully passed the usability test.

The issue, though, was because we were doing what we might call “first-look” usability testing, we were only ever able to get an initial reaction from these users. Even when we talked to users who knew an earlier version of the interface well, it could be tricky to get anything more than a first impression. Because we only gave them a short time to evaluate it, they had a hard time determining how comfortable it would be to use after some time had passed.

Usability tests are often learnability tests

It dawned on me that these weren’t so much usability tests; they were learnability tests. We were only ever able to find out whether an interface was intuitive, with very little revealed about long-term ease of use until after it had been used for some time.

However, for many of these hospital users, learnability wasn’t the main concern. In fact, it was the opposite — many of them would choose an interface that was harder to learn if it meant they could move with greater speed and fluidity when the time came. In practice, learning effort did matter to them, but not as much as the day-to-day effort of using it in the weeks, months, and years that followed.

Yet in “first-look” usability testing, we saw the same results as we always did. Users had tended to prefer the easier-to-learn options, and we would conclude that they were therefore easier to use. But sometimes, what they chose turned out to be better for learnability but harder to use in the long term.

That was a problem — these tests were only telling us part of the story.

A usability blind spot

I wondered if I was missing something, so I went to see what the experts had to say. Eventually, I stumbled across this section on usability testing in the design classic About Face:

Unfortunately, it’s difficult to craft a test that assesses anything beyond first-time ease of learning. […] [U]sability testing, by its nature, focuses on assessing a product’s first-time use. It is often quite difficult (and always laborious) to measure how effective a solution is on its 50th use — in other words, for the most common target: the perpetual intermediate user. This is quite a conundrum when you are optimizing a design for intermediate or expert users.

While the book recognized the value in looking beyond first impressions, it described the process as being “laborious” and “difficult”. As a result, the advice tended to focus on assessing learnability.

This aligned with what I’d read elsewhere — it was the norm to focus on learnability. But I saw something a moment later that I did not expect. Elsewhere on that same page, the book described giving interface mockups to developers by printing them out, which hasn’t been a best practice for decades. This was a valuable reminder that design methods continually evolve over time. With that in mind, I reasoned that less painful techniques might be available to help with this today. (Thankfully, there are, and we’ll look at them in depth in Chapter 4.)

We took a moment to reflect on what we’d learned. In the hospital, we had an audience that often valued speed and efficiency over learnability. But because we were focusing on “first-look” usability testing, problems with learnability were often caught while other issues were able to sneak through unnoticed.

It became clear that this was a blind spot. Yes, users often told us about day-to-day usability issues after using an interface for some time. But we were not doing anything in the initial design phase to spot these issues in advance. In fact, when I reflected on the usability testing I had done over the years with some truly world-class design teams, I couldn’t identify a single time that we’d focused on trying to proactively spot issues with long-term ease of use. It simply wasn’t a part of the process.

Designing for efficiency and comfort

Keeping an eye on long-term ease of use seemed important. Yet while we had great tools for figuring out whether things were easy to learn, I discovered I didn’t even have concise language to describe all the effort of using an interface that somebody would experience apart from the effort of learning it.

We could see that there was effort involved in learning what to do, as well as effort that persisted even after figuring it out. It was common to focus on improving learnability. Perhaps there was also a way we could focus in on this “non-learning effort?”

With clearer language to describe this, my team and I believed we could discuss, understand, and reduce it more easily. I eventually settled on the term UI Ergonomics, as the New Oxford American Dictionary defined “ergonomic” as “relating to or designed for efficiency and comfort in the working environment.”

This seemed to resonate with people. Those two things — an interface’s overall efficiency and comfort — appeared to be essential components of this “non-learning effort.” I should note that we’re using the term “ergonomic” loosely since there may be marked differences between this and the traditional study of human factors. Yet for our purposes, the word has proven helpful as shorthand, as it seems to conjure images of unencumbered, graceful, fluid experiences designed to feel comfortable after many hours of use.

With this, I now had a simple way to discuss it with teammates and stakeholders. We could break usability into two pieces: learning effort and ergonomic effort.

Examples of learning effort and ergonomic effort

We can think of the difficulty of any task as a combination of both these types of effort. For example, picture someone who wants to get a snack from a vending machine each afternoon. They’ll need to figure out how to use the machine to select the items they want. Yet even after they’ve gotten the hang of it, they’ll still need to go through the routine of pushing the buttons correctly every time they want a snack. There is upfront (learning) effort, but there is also ongoing (ergonomic) effort.

To help illustrate, the following are examples of learning effort. These center around the effort of figuring out what to do and how to do it:

• Which button should I be looking for?
• Will this function do what I want?
• What do I do next?

And here are some examples of ergonomic effort. These center around effort that doesn’t go away, no matter how well you learn it:

• The button I need to hit is small, which makes it harder to aim for.
• It takes a moment for the device to show that it received my input, which throws me off when I’m trying to move quickly.
• The information I need is in a different location each time, which makes it difficult to spot.

What this book will cover

With the introduction out of the way, let’s take a look at what you can expect in the pages ahead. This book focuses on the vital role of ergonomic effort in designing easy-to-use apps. This is a topic that doesn’t often get much dedicated attention, so to keep things focused, there won’t be a deep exploration of learnability, capabilities, or product–market fit. Instead, along the way, you’ll see how UI Ergonomics intertwines with other factors like these in products that users truly love.

This book is a practical guide. While there are different ways you can break usability apart, splitting usability in this way unlocks a set of powerful and transformative tools. Throughout this book, I’ll walk you through these tools and show how they can help you do the following:

• Spot many interface issues proactively that typically only get fixed after users complain
• Make a better case to teammates and stakeholders for impactful changes that often get dismissed as being “unintuitive” or “insignificant”
• Make larger redesign projects less risky by avoiding interface changes that upset, frustrate, and drive away your most invested users
• Make design priorities clearer by comparing your interface to others in terms of the effort required

Part I

As you’ve just seen, Part I of this book introduces the idea of dividing usability into learning and ergonomic effort. Through this lens, the rest of Part I covers three main topics. First, it gives you a simple visual for quickly communicating why certain changes are more impactful than they might seem, which makes it easier for you to get buy-in from those you work with. Second, it shows you how you can make changes to interfaces without frustrating your existing user base. And third, it provides ways to effectively measure the effort often missed by “first-look” usability testing, which helps you to overcome the blind spot mentioned earlier. I recommend reading these chapters in order as they build on each other.

Part II

Part II of this book gives you a guide to the system I use throughout the design process that will help you spot ergonomic improvements in advance. This is called the CUPID System, which grew out of seven years of detailed notes on common sources of ergonomic effort. You can use this as a “preflight checklist” for your projects, and to help you give better feedback when reviewing work with your team. Chapters 6–10 contain many examples of specific improvements you can make to enhance the long-term usability of your app. These chapters can be read at any time, but it’s best to read Chapter 5 first.

Appendices

Lastly, the book includes several additional tools in the appendices. Appendix A introduces a tool called the Usability Matrix. This gives you a new way to compare interfaces and enables you to make clearer decisions about where to focus your design efforts. Appendix B covers the Product Pyramid, which uses this framework to help you to understand user behavior as it relates to your app. Finally, Appendix C includes the CUPID Cheat Sheets, which make it easier to use the CUPID System with your team.

As designers, we build tools to help users reach their goals with less pain and effort. The tools in this book are here to help you do the same.

Key points to remember

In this book, we split “ease-of-use” into two distinct types of effort. Learning effort is the upfront effort it takes to become familiar with an interface; ergonomic effort is all the effort that remains, which persists long after it has been learned. Often, ergonomic effort is revealed through user feedback after people have had a chance to use it for a while. Instead, with this book, you’ll see how to quickly spot opportunities and fix issues like these in advance. This is a superpower, as it allows you to move more swiftly while sparing users from much of the pain that is normally inherent to this process.

In other words, you’ll be able to ship better products with fewer complaints that need to be addressed later. This makes users happier while increasing your bandwidth, giving you a huge advantage.

Try this

• When you hear someone describe something as being “easier,” ask yourself, “Do they mean it’s easier to learn?” You’ll start to see just how common it is to talk about ease of use and ease of learning as if they were the same thing. This should help underscore how often ergonomic effort gets overlooked and why paying special attention is so important.
• Try to spot the difference between learning effort and ergonomic effort in the wild. When you have trouble with a task, ask yourself, “Would this be any easier if I knew this process better? Or is the task inherently tricky?” Remember that problems with ergonomics don’t go away with time and experience — these difficulties are inherent to the task. The more practice you get with this, the less trouble you will have catching these kinds of issues.

Up next

Even if you believe in the importance of good ergonomics, your team or stakeholders may still need some convincing.

As we’ve discussed, an interface can do well in “first-look” usability testing even when it has severe issues with ergonomics. That makes things difficult — you may need to be able to explain why an interface that passed this testing is not actually the “easier” option in the long term.

This can feel like an impossible task, so being able to communicate this point with clarity is important. Next chapter, we’ll build upon what was covered here with a visual tool to help you clarify and get the support of your team.

Thanks for reading this excerpt from Learnability Isn’t Enough: How to Design Apps That Are Easy to Use in the Long Run, Not Just the First Run. If you’re curious to read more, you can visit book.hansv.com to learn how to get your own copy.