The business world is rife with misbeliefs about user experience design.
Just browse nearly any UX publication and you'll find articles bemoaning or correcting falsehoods about the design process.
Perhaps it's the way UX design conflicts with the traditional believes of stakeholders and engineers. Stakeholders tend to think research is a waste of time. Engineers often fail to comprehend why users don't want to dig through documentation.
Or it could just be everyone's catching up to UX's sudden rise in popularity over the past eight years as seen here in Google Trends:
Whatever the reason, there are clear misunderstandings about the process and value of UX design.
Rectifying these misbeliefs is important because they stymie user research and derail expereince design. In short, they stop designers from doing their best work — which is what everyone really wants, right?
Here is a list of misbeliefs that we've experienced most often in our work at DePalma — plus clarifications about each subject.
"We don't need to do research. We already know our users."
I've been told the classics never go out of style. Perhaps it's true. This is one of the oldest UX misconceptions around, and it's one that will likely persist for a long time. Maybe indefinitely.
Why? Because this logic is a product of a powerful cognitive bias known as the false-consensus effect. This bais refers to the tendency to vastly overstimate how many people share your beliefs, preferences, values, and habits.
This is why we're surprised when others don't agree with us, and why we rationalize their disagreement by assuming any dissent to our opinions is part of a small minority.
We're wrong, of course. Human beliefs are widly complex, and we shouldn't be surprised when people think differently than we do.
It's easy to see how this applies to UX design. Believing end-users experience the world and solve probems in the same way you do is (nearly always) untrue.
Relying on this logic to make design decisions will precipitate a product designed for you, not something that's based on the needs of your audience.
And that means your product will fail. Or in the very best case underperform. You must remember that you are not your users, and that is why you have to do research.
GE and the power of field research
In the first chapter of the indelible Creative Confidence, the Kelley brothers tell the story of Doug Dietz, a technician who lead the design and development of a magnetic resonance imaging (MRI) machine for GE healthcare.
In Doug's eyes, his MRI machine was a modern marvel. Not only could it take extremely detailed images of the inside of the human body, but it was also competing for an international Design Excellence Award.
Here it is in all it's glory:
Then one day, Doug's perspective on his work was forever altered. While visiting a hospital, he observed a young child brought to tears because she was terrified to enter the huge machine.
A nurse told Doug it was a common occurrence — most children were afraid of the machine.
Doug had an epiphany, and he spent the next few years redesigning his machine to better suit children by redecorating the machines and their storage rooms as theme park-esque adventure environments.
As a result, children became less affriad of the MRI machines.
Here's how the redesigned version looked:
Before Doug performed his own user research — before he watched a segment of his audience actually use the product — he thought he knew everything he needed to about his users.
In reality, he had massive gaps in his understanding of how people viewed and used his design.
That's why we must always do user research: to establish a true understanding of our audience and build solutions that effectively meet their needs.
"Empathize with users? That doesn't sound like a serious process."
Oh, but it is. Empathizing with users is a very real, very important, part of the experience design process.
There are actually multiple types of empathy, the two most important of which are cognitive and affective empathy.
Cognitive empathy refers to understanding a situtation from someone else's perspective.
Affective empathy describes the ability to understand someone else's emotional state and respond appropriately.
Emotional design does play a role in experience design, but the majority of the research we do focuses on cognitive empathy, which helps us understand the users' motivations, thought process, and challenges.
While designers may be less supsceptible to false-consensus, they are actually more apt to fall prey to the curse of knowledge, which refers to the inability to recreate their state of mind before they knew something.
This concept is well illustrated by a study conducted in 1990 at Stanford University.
The study divided participants into two roles: tappers and listeners. Tappers were asked to pick a popular song they thought everyone should know, like “Happy Birthday” and tap the rhythm out on a table.
As you can imagine, the listener’s job was to listen and guess the name of the song.
Before the activity began, researchers asked the tapping cohort how often they thought listeners would correctly guess the song. They estimated 50% of listeners would know what they were tapping.
In reality, only 2.5% of listeners correctly identified the song.
Why were tappers so overconfident? Because they couldn't appropriately conceive what it was like before they knew what song they were tapping. The rhythm was obvious in their mind.
The same can happen to anyone working on a product design. We have so much knowledge about the solution we’re building that we forget our audience — the people who will actually use the product — don’t have anywhere near as much understanding of how it works.
So we do empathy research, and we translate that research into empathy maps, which are important tools for helping designers consider the context of use for their audience.
Empathy maps (as seen here next to our persona) plot what users think, feel, see, and do.
When we designed an AI personal assistant, we built empathy maps to help understand
- how our audience would engage with the application,
- what they were feeling as they used the software,
- and the myriad of environmental factors that influenced their experience.
Here's the empathy map we made, along with a user story constructed from our research to better understand the user's typical day.
During this process we discovered that the way users communicated with the AI assistant would need to be flexible based on the environment.
Voice was the primary input method — like people use with Siri and Alexa — but the hearing portion of the empathy map told us that our audience of business consultants was often in loud places, like airports, subways, or crowded offices.
These environments made it very difficult to interact with the assistant just using voice, which significantly impacted the user experience.
To provide an optimal experience, we designed visual input methods that didn’t rely on voice. One option allows users to text with the assistant, and the other acted like an online form, where users put in a request and filled out details about the request.
Both of these features adapted the AI assistant’s user experience to the day-to-day environment of our target audience, making the interaction simpler and more valuable.
These new input methods became a cornerstone of the project, but we never could have reached that conclusion without developing a sense of cognitive and affective empathy with our audience.
“The research process takes too long. We need to get started on design.”
If you’re not doing research, then you’re not really doing UX design. Research and usability testing aren’t just one step in the process; they’re ongoing inputs that continually inform how the design should move forward.
Without research and testing, you’re doing visual design, not UX design.
What’s more, you’re running a huge risk. If you don’t allot at least some time for user research, then you’re going to design and code something that people may not even want.
That’s how software was developed thirty years ago, which is why it was (mostly) terrible.
Unfortunately, this is a fate that many IT departments still suffer. We’ve worked with clients who have spent a fortune fixing design problems and bugs after the code is live.
These changes take significantly longer — sometimes by a factor of 100x — and cost much more than if they were made earlier in the process, or prevented altogether with better research.
Now, there should definitely be flexibility in the process. Every project has to deal with constraints, and the research process should adjust to each set of new constraints.
If someone tells you it can’t, then you might want to look for another UX firm.
“This mockup doesn’t look finished. It’s missing important elements.”
At its core, UX design follows an evidence-based, iterative process. Each new version of the design is adapted from what came before based on user feedback.
This sequential approach make sure that each creative decision is validated by the audience and product stakeholders before it becomes a permanent fixture in the design.
The more traditional approach runs straight to high fidelity mockups without building a consensus around the foundations of the design.
As we’ve just covered, this is a waste of resources.
Here’s an example of how iteration happens. At DePalma, we always make the first visual representation of a design a low-fidelity wireframe. These are very simple outlines of what the final interface will look like.
Based on the input from the end-users and stakeholders, we’ll evolve that design to a high-fidelity wireframe, which includes more detailed design elements.
After another round of feedback and some usability testing, we’ll move to a polished version that’s much closer to the final design.
Now, this example is a simplification of the process, but hopefully it gives you some perspective on how each version of the design is critiqued before we move to the next step.
In the end, the result is better for our clients, because you and your users have input every step of the way.
“We don’t need an entire team an entire team for this project.”
Actually, you might. Just check out this venn diagram:
It’s overwhelming isn’t it? But it illustrates just how many disciplines coalesce during the UX design process.
In our experience, many stakeholders assume design and development are all performed by the same people, but the professionals who code software are not the same people who design it. There are often multiple designers — each with their own specialties — who work on the research, experience, and visuals of a solution.
Assuming one person can handle all of that responsibility with the same degree of skill as an entire team of specialists just isn’t accurate.
That’s like asking one person to perform an entire symphony. Sure, it’s not impossible, but would anyone want to listen to it?
Like everything else in the design process, this is variability here. The exact amount of design resources you need on your project depends on your scope.
I’ve already written more extensively about when it’s best to hire one designer and when you work with a UX agency, so if you’re on the fence, you can read that comparison for more detail.
It would be disingenuous to pretend that UX design should be well understood by everyone. The industry’s rapid rise in popularity means more people than ever are thinking about how to use it to improve products and services.
And that’s a good thing.
But in our rush to adopt UX design and prioritize the user experience, we must be mindful of what makes this discipline successful in the first place.
And that means understanding how some of the core concepts work, so designers and researchers can do the work that’s required to build optimized experiences.