In the world of product design, people use the words ‘intuitive’ and ‘obvious’ almost as liberally as some CEO’s use ‘synergy’ or ‘bottom line’. Perhaps the most common design feedback I hear from users is, “it’s just not very intuitive” or “[fill in the blank] wasn’t obvious to me”. Don’t get me wrong, those are totally valid critiques; great product design should feel obvious to the user. However, that feedback can often result in confusion and frustration for designers, developers, and anyone involved in the app creation process.
We rarely design things that we ourselves don’t believe to be intuitive. So when users don’t understand how to use the applications we’ve worked hard to design for them, our natural reaction is to feel defensive. We assume there’s something wrong with them instead of blaming the design and looking for ways to make it more obvious to the people using it. To break this cycle, we need to understand the disconnect and consider what actually makes a product design seem obvious to its users.
What makes something obvious?
Something is obvious to a person when it works as a person expects it to, and those expectations are rooted in personal experience. Human perception is a combination of new and previous experiences, and obviousness is determined by the amount of effort required for a person to take a new experience and make sense of it within the framework of what they already know. Think of a person’s previous experience as a big jigsaw puzzle and a new experience as a new puzzle piece. Does the new piece slide seamlessly into an empty space in the puzzle, or does it require rearranging and brute force to make it fit?
Here’s an exaggerated example. Let’s say you completed an important form at work using a software product on which you were just trained. You’ve finished your task and now you want to save your progress and move on. At the end of the form, you encounter the two buttons in Figure 1.
Which button should you click? You might say that the choice is obvious; after all, the buttons are clearly labeled. But you probably had to stop and think about it––even if for just a brief moment. You just finished the form, you know you want to save it, and the button on the left is clearly labeled “Save.” However, if your experience with other software products is similar to mine, red often means “warning” and blue means “not warning.” You may have been a little confused into deleting all your hard work.
So is this button design obvious or not? If I had no previous experience to compare it against, I think it would be. I wanted to save my work, and there’s a button that says “Save.” However, since I do have previous experience to compare it against, and that experience is riddled with red flags, red self-destruct buttons, and HQ saying, “Don’t cut the red wire!” I would have to rearrange a few pieces in my mental puzzle to make sense of this.
Most designers know enough about basic color psychology and common design patterns to instinctively not design something as egregiously confusing as a blue “Delete” button and a red “Save” button. But more subtle variations of this mistake appear in websites and software products all the time, and they occur when designers work in a vacuum of their own experience and neglect to consider the experience their users bring with them when they use products.
Conforming to users’ mental models
A key element of the experience our customers are bringing to their interactions with our products are their mental models. Steven Bradley of Vanseo Design said it well:
“Mental models are broader conceptualizations of how things work, and they explain cause and effect. Mental models can be easily transferred from one object to another as long as the objects use the same paradigm. For example, interface menus work mostly the same across different software. Similar are links and website navigation. We have a mental model of how these things work, which makes it easy to use them when we encounter them in a different place. Mental models help us build conventions.”
So put simply, mental models are how humans explain or make sense of how things work, and that conceptualization heavily informs how we interact with things. So why do we need to consider mental models in design? Often in product design, the reality of how something works is too technical or just too odd for the average person to understand without more education. If our users are unsure of their conceptualization of how it works, they will be unsure of how to interact with it. It’s the responsibility of product design to bridge the gap between the way the system actually works, and the mental models employed by our customers.
In his book, About Face: The Essentials of Interaction Design, Alan Cooper breaks this concept down into three parts: the system model, how the technology actually works; the user’s mental model, a user’s conceptualization of how the technology works; and the represented model, the way a design presents how the technology works. Of these three models, the only one that a designer controls is the represented model. The closer a particular design’s represented model is to matching a user’s mental model, the more ‘obvious’ that design will be.
Here’s an example to illustrate this concept. Take a moment to picture the files, folders, zipped folders and other elements of your computer's file structure. This may shock you, but there aren’t actually rows of physical, manilla folders inside your computer’s hard drive. In fact, when you add a file to a folder on your computer, you’re not technically putting one thing inside of another thing. You’re actually updating that file’s path from your computer’s root directory. The relationship between physical folders and files is a concept the average computer user is familiar with. Using a represented model that allows users to employ that conceptualization when managing files on their computer is totally sufficient in helping them complete their tasks.
Essentially, we don’t need to design so literally. As long as shielding users from some of the more nasty, technical aspects of how the sausage is made doesn’t impair their ability to effectively complete their tasks, it’s better to design our products in a way that more closely resembles the way people think our products work than the way they actually work. Doing so will make our product designs feel a lot more obvious and intuitive.
Sounds easy, I’ll start tomorrow.
All of this may sound easy in theory, but it can actually be really tough to do in practice because it requires designers to get outside of themselves and step into the shoes of the people they are designing for. A common mistake is assuming that the people using our products have the same mental models as we do, so we fall into the trap of designing the product to match our own conceptualizations instead of theirs. This can sometimes work depending on the product we’re designing and how closely we align it with our target audience. But often, designers have a deeper understanding of how the system works than the average end user does, so our mental model will more closely resemble the system model than the mental models of users. Then we feel frustrated when we hear our product designs aren’t intuitive because we really thought those designs were foolproof.
It’s not up to the designer to determine what’s obvious––that’s the job of our end users––and the only way we can learn how to make our designs intuitive is to ask them. A lot. We need to spend plenty of time with our target audience so that we don’t unwittingly start believing that their experiences and expectations are the same as ours. That said, there are right and wrong ways to gather feedback and insights from users. Entire articles and books have been written on this subject, but here are a couple helpful tips.
First, don’t lead the witness. If we show our designs to someone and ask something like, “is it obvious that you can do [fill in the blank] here?” we’re much less likely to get helpful feedback. Whether the person we ask says, “yeah, I think so,” to be polite, to not look dumb, or because it actually is obvious now that we’ve so courteously explained it, we’re probably not getting to the truth with that approach. Open-ended questions are our best friend here. Try asking, “what actions does it look like you can take here?” or “how would you accomplish [fill in the blank] on this screen.” Better yet, create a prototype, give a user a few tasks to complete with it, and observe how it goes. This will quickly show us just how obvious (or not) our design really is.
Second, we should go into every user feedback session assuming that our design is wrong and needs to be fixed. Changing our posture in this way actually changes what we hope to get from the interaction. If we assume our design is correct before asking for feedback, then what we’re really after is affirmation that our design is as good as we thought. However, if we assume we’re wrong, then we actually start to look to users as the people that hold the valuable insights needed to make our designs better. Isn’t that humanizing? And why shouldn’t we assume we’re wrong? Product design is incredibly difficult, and even the best designers hardly ever get it right on the first iteration.
However, if we assume we’re wrong, then we actually start to look to users as the people that hold the valuable insights needed to make our designs better. Isn’t that humanizing?
Less design, more conventions
In addition to developing an intimate understanding of our audience, stealing design patterns from other products your customers are using is not only okay, it’s encouraged. This may sound odd, but often good design doesn’t mean more design. In most cases, reusing common design patterns, patterns we did not have the esteemed pleasure of inventing, will result in more obvious interactions and better overall experiences for our end users. Jakob’s Law, coined by Jakob Nielson of the Nielson Norman Group, states that “users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know”. Unless our product is a hovercraft, we don’t need to reinvent the wheel. People like wheels; we expect wheels.
Julie Zhuo, former VP of Product Design at Facebook, current badass, goes so far as to say that the best designs are so obvious that they’re invisible:
“Many of the new services or products I appreciate the most tend to have little in the way of new visuals. In fact, they tend to achieve better ease of use by shifting toward invisible design—cutting out entire steps, ditching whole surface areas, or relying on existing patterns instead of inventing new ones. The result is experiences that feel seamless and intuitive, almost magical.”
Every designer craves to hear the words “this design is magical” during a usability test, but sometimes it's a better sign when our beautiful brain child is overlooked entirely.
The key to obvious design
Conceptually this is all pretty simple. The key to designing intuitive products for our users is taking time to define what they know and how they think, and doing whatever we can to make our designs fit within that. Some features operate basically the same from product to product, so reusing conventions that our users have already mastered is a great way to make their jobs easier. For the features that will be brand new to our users, we can work with them to find similar paradigms that they are familiar with and try to allow them to conceptualize those when interacting with our product. This might mean abstracting some of the more “technically correct” details of our products’ functions, but as long as it's helping users, it’s worth doing. Lastly, more than anything else, we just need to be disciplined about frequently questioning our own assumptions and make sure we remember the real human beings we’re designing for. The rest will flow from that.
Are you getting the most out of your business apps? Take this quick assessment to identify UX design problem areas in your apps.
Skuid Skool: Uplevel your app-building skills. Sign up for Skuid Skool today!
.jpg)
