I Know What Users Want
Usability TestingWhen we first start learning design, it is incredibly easy to fall into a specific trap. We look at a layout, imagine how we would click through it, and think we already know what users want.
The hard truth of user interface design is we are not our user
In psychology, this trap is called False Consensus Effect cognitive bias where we overestimate how much other people share our choices and behaviors. A cognitive bias where we assume other people share our preferences, habits, and technical knowledge.
Because of this bias, we falsely assume that our preferences, our habits, and our technical knowledge are identical to those of the people who will actually use the product. As designers, we know how digital products work behind the scenes. Our users usually do not.
Imagine we are designing a website for a local bicycle shop. Because we understand UI trends, we might love the idea of a sleek, minimalist layout where the navigation is tucked away inside a tiny, hidden menu. But a customer visiting that site in a hurry might just want a giant, obvious button that says “Book a Repair.” If we design strictly for our own tastes, we fall victim to the false-consensus effect and build something that frustrates our actual audience. Good design relies on evidence, not ego. Instead of letting this bias dictate our choices, here is what we should do:
Talk to our users
Get out of our own heads and speak to the people who will actually interact with the product. Ask them what they are trying to achieve, what frustrates them, and what they need to succeed.
Watch them complete tasks
What people say and what they do are often two different things. Watching someone try to navigate a layout is often the fastest way to spot friction. We will quickly see where they get confused or where the cognitive load is just too high.
Check the data
Support emails and analytics never lie. Reviewing support questions or watching user session replays can show us exactly where people get stuck, rage-click, or abandon the page entirely.
Test our prototypes early
Let’s not wait until a project is finished to see if it works. Get our early prototypes in front of real people. We need to see if our visual hierarchy actually guides the eye properly for someone who hasn’t been staring at the design for 40 hours.
Treat our assumptions as hypotheses
Next time we catch ourselves thinking, “Users will definitely understand how this works,” we need to stop. Label that thought as a hypothesis. It is an educated guess, not a fact. Our next step is to go prove or disprove it with real people.
Unless we are building a tool that only we will ever use, we are designing for someone else. Let’s learn to leave our own assumptions at the door, recognize our biases, and let the users show us what they actually need.
