UX Myths: The Right Approach Part 1
Discover the shocking truths behind common UX myths! Our blog debunks false beliefs about user experience design. Join us to uncover the reality.
Have you ever gotten feedback from your client that sounds something like: “... we came from this industry so we know what users want… ” or “... we need to get to that page in 3 clicks… ” or “… I want this page to be original and unique…” That way of thinking and understanding is something people often read online, is repeated constantly and people believe in those facts. But they aren't necessarily true. Such thinking originates from myths that were created over a period of time. Due to common misconceptions, it can often be challenging to convince clients of the value these processes can bring.
In the following article, you will read about myths that are often mentioned and these assumptions are often directed at UX designers by clients or partners who are not experts in that business. This article aims to highlight 5 of the most common UX myths observed from our experience and professional point of view.
Myth #1 Users can articulate what they want
“If I had asked people what they wanted, they would have said faster horses.” This is something Henry Ford most probably never said, but he was definitely thinking out of the box.
What users say and what they actually do – are two different things. Sometimes clients and inexperienced designers rely too much on users' feedback. This means that everything they say should be considered and changed in the product. There could be situations where some clients have their own idea of who they think their “target audience” is, and everything that we suggest needs to be tested with users, they want to do by themselves. Yes, the cost for them is zero, but what is the actual outcome?
The right approach
Human preferences and decisions are not stable. There is a difference between imagining using something and actually using it. That said, it doesn't mean you should quit listening to your users, but instead find the right approach in interviewing them. Here are some methods that could help you extract the most relevant insights from your users:
Watch users work - Prepare a prototype (or a real product) and watch users as they attempt to perform tasks that you ask them to do.
Show and listen - Only after the user has interacted with the design and has a real feeling of how it actually works, can you collect some preference data from them.
Understand their behavior - Make sure to track and measure their experience. If they say “I would have seen this button if it had been bigger” - all you need to understand here is that they didn't see the button. Go and design a better solution.
Be aware of self-selection bias - Don't choose your users through a random sampling of all your users. Instead, do your best to segment your users based on relevant criteria or at least be aware of your bias when certain segments aren't represented.
Myth #2 Users are lazy
We often find ourselves in situations where we hear from designers that they think that users are a bit dull, or even stupid; that they don't want to make an effort to explore the design or get to know the site a little, so some will even say that they didn't choose a good user for testing, etc. The worst-case scenario is that designers think the users are… lazy.
Why is this so? It happens often that during usability testing, the designer is thinking in their head, “No, this is not how I imagined you to follow this flow…” or even “Just please concentrate on the task, don't be so lazy…” But in fact, in most cases, the users are being efficient.
So if your instinct is to label the user as lazy, remember that those same characteristics are actually the result of efficiency-based behaviors.
The right approach
As human nature is what it is, users want to minimize the total mental effort in almost anything they do in their lives. But if we try some different methods, we can maybe increase their curiosity by doing this:
Make the design cohesive - If you are consistent in your interface from the beginning, and use uniform elements, fonts, and colors - you minimize the user's cognitive load because you standardize your design into one system.
Use the “Hook” model - Aim to create an organic bond with your user to make a product a part of their lives. Sell them your product so they can create day-by-day routines and habits with your product.
Warn users to use a more suitable device - “Device inertia” happens when multiple devices are accessible to the user, but they will continue using the device with which is currently working, even if the other device is potentially much more suitable. If you want the user to have the best user experience, and the user is currently on their phone - if there is a flow that is only suitable for desktop devices, give them a note that the experience quality on mobile devices will be poorer and suggest they switch to the desktop version. The user will probably stick to the mobile device, but your job as a UX designer is completed.
Users are not replaceable, all people don’t have the same way of thinking or understanding. So the conclusion is that you as a designer should find the best design solution instead of labeling your users as “lazy”.
Myth #3 You can also be your user
You surely had a client who was trying to make decisions on behalf of “their” users, right? How did you act at that moment? Do you think that you made enough effort to explain to the client that they cannot make some decisions so lightly because they have a different background, different experience, and a different mindset than their users?
It often happens that designers or clients have some assumptions about their users and based on those assumptions they often follow the wrong direction, and mistakes and problems occur fast. This happens mostly because:
The thinking that only people who are completely different from us, that only they will have different thoughts and opinions
The thinking that “It’s not convenient for me, so other users will also struggle.”
The thinking that all users today have the same experience and knowledge of technology
And many more…
The right approach
“A mental model is based on belief, not facts: that is, its a model of what users know (or think they know) about a system such as your website” - Nielsen Norman
To avoid misunderstanding in product development, it is important to test your assumptions, talk with your users, and make some tests - so you can iterate easier and safer. To do this, you probably need to convince the client how important this is.
The easiest way to do this is to answer the questions: What? Why? How?
In this way, you will explain what the steps are that you plan to take and show how reasonable each stage is. You need to explain why you think it is necessary to do that and why you as a professional think that it will be helpful later on in the project. How will you do that, describe the process and explain to the client how it will impact the product itself. To conclude, repeat to yourself and to your client that you are making products first and foremost for others and not for yourself.
Myth #4 Testing is always optional
Many organizations and product teams still communicate to the clients that the testing phase is optional. What are we indirectly telling the client when we tell them that testing is optional? The client takes this as the fact that testing is probably expensive, and that it is certainly not as important as being optional.
It is mentioned as a myth because there are many articles that are written, about how Product Designers should be experts, they need to know how to do their job, and why should they waste time and test some website or application if they have done a dozen of those websites or apps? This circulating fact puts us all in the same basket and every time I talk about it with a client, I have to justify myself and spend time explaining the benefits that come from testing and why it shouldn't be optional, but required. Let's ask ourselves, when a new car is finished, do you think it should be put on the road before it is tested?
The right approach
Users’ behavior is often hard to predict, which is why it is important to test. After you gain the client’s trust, and when you get to know him a little, find the most painless way to justify the situation where you decided that the product needs to be tested. Prepare several arguments that will help you convince the client of the importance of testing before developing the application. Here are some:
Usability testing can be very fast and cheaply done - creating a lo-fi prototype with a maximum of 5 users - and still bring valuable results
For many projects, you can use remote and unmoderated tests
We will gather results on whether testers can complete tasks successfully and independently
We will see how much users enjoy or do not enjoy using a product
Many situations that could lead to negative user feedback will be prevented
Corrections will be made faster before the design goes into development
And many more…
To conclude this myth: “Tests are as important to the health of a project as the production code is. Perhaps they are even more important because tests preserve and enhance the flexibility, paintability, and reusability of the production code” - Robert C. Martin
Myth #5 Constant design iteration is bad
A lot of designers, especially juniors, are afraid of making iterations. They often think they will seem inexperienced, think that the client is not satisfied with them, whether they should even ask for feedback, and so on. They think that if there are a lot of comments from the mentor or the client, they will not end up as a great designer.
But just the opposite - iterating and learning about the design processes, patterns, and most importantly users will make you 1% better each day.
By designing an interface, and playing with the layout, hierarchy, and all other elements - the designers hands are open to do what they know best - solve problems. That means that iterations should be the rule when it comes to UX or UI design. Sometimes it could lengthen the process with a certain amount of time, but it is definitely less than what the team would spend on fixing a bad design.
The right approach
A good designer should ensure that they understand how iteration works and how to use it best in their own work. They need to make sure they gave their best, but by understanding human behavior they will make sure that their design will likely work and avoid things that are likely to fail. There are some benefits that iterations provide:
You can have multiple sessions of feedback from the users
Focus on the fundamentals first, and build on them through iterations (in that way, you can make sure you don't miss important rules)
You can gather the “red flags” from the real users
You can keep up with the changing that the consumer demands
If the iterations are done before building the app, it will ensure a small amount of changes brought to the product after building it
To conclude this myth - the iteration process is surely not bad. Of course, a balance is needed, and a certain amount of iterations will be acceptable to both the client and you. With experience comes the knowledge of how many iterations to do and when. But if you are unsure for a moment, you can always ask a more experienced colleague, as we do at Cinnamon. Always be open to feedback, communicate your ideas and suggestions, and always argue your beliefs.
To conclude, be sure about your decisions and stand firmly behind your convictions.
Make an effort to provide a quality argument for each of your decisions, so that the clients can see that you are a self-confident and professional designer.
A dose of (Design) Dopamine
Updates and resources
Quality content for free