You Are Not Your User, and That’s the Whole Point

The most dangerous assumption in product design is the one we make.

Photo by Fatemeh Rezvani on Unsplash

There’s a phrase I keep hearing in meetings. It comes up when someone’s trying to justify a design decision, or push back on doing research, or explain why a feature should work a certain way. It sounds reasonable and it sounds grounded.

It goes like this: “Well, I’m a user too, so I think…”

I used to say it myself a lot. So I believed it made my opinions more valid that not just a gut feeling, but lived experience. Surely being an actual user of the product gave me a leg up on understanding what users need?

It doesn’t. In fact, it might be one of the sneakiest traps in product design.

The curse of knowing too much

When you work on a product every day whether you’re a designer, engineer, PM, or founder which you develop a relationship with it that no regular user ever will. You know where everything lives and you remember why certain decisions were made. You’ve built mental shortcuts that feel like intuition but are really just familiarity.

Familiarity is not the same as understanding, and expertise about a product is not the same as empathy for its users.

This is called the curse of knowledge and it’s brutal in product design. The longer you’ve worked on something, the harder it becomes to see it with fresh eyes. You stop noticing the rough edges because you’ve long since developed workarounds. You forget that something is confusing because it stopped confusing you months ago.

When decisions get made from that place from insider familiarity disguised as user empathy, the product quietly drifts away from the people it’s supposed to serve.

What insider bias actually looks like

It rarely shows up as obvious arrogance. More often it sounds like this:

“If I were a user, I’d obviously want it this way.” said by someone who has never watched a real user try to use the feature

“We don’t need to test this, it’s pretty intuitive.” intuitive to whom, exactly?

“The users who complained are just not the right users.” a convenient way to dismiss signal you don’t want to hear

These aren’t signs of bad intent. They’re signs of a team that’s gotten too close to its own product. It happens to everyone, and it happened to me.

The problem is that when you act on insider bias, you’re essentially designing for a user who doesn’t exist combining a perfectly informed, context-rich version of yourself rather than for the actual humans who come to your product with zero of your backstory and none of your patience.

So what is User-Centered Design, really?

A lot of people hear “User-Centered Design” and picture formal research labs, expensive usability tests, and six-month discovery phases. That’s a version of UCD but it’s not the only version, and it’s definitely not the version accessible to most teams building products from scratch.

At its core, UCD is simpler than that. It’s just a commitment to making decisions based on what you learn about real users, not what you assume about them. The methods scale, and the mindset doesn’t have to.

The proportional UCD toolkit:

1. Watch someone use your product for 20 minutes and just watch. Don’t help them, three sessions like this will teach you more than a month of internal debate.
2. List every assumption your team is making about users, and then rank them by how badly things would go if you were wrong. Validate the risky ones first.
3. Read your support tickets and app store reviews as if they’re research data. Users who bother to complain are giving you free insight.
4. Before shipping a new feature, find five people outside your company and ask them to complete one task with it. Five is enough to find the big issues.
5. Keep a “what we heard from users” doc. Revisit it in every design review and make the user’s voice physically present in the room.

Knowing when to trust yourself and when not to

This isn’t about never using your judgement. Design intuition is real and valuable, especially when it’s built on a foundation of actual exposure to users. The question is whether you can tell the difference between intuition and wishful thinking.

Trust your instinct for: established UI patterns, micro-interactions, and anything that’s already consistent with how your users have shown they think.

Go to real users for: new features targeting unfamiliar segments, decisions where the team is split, and anything that keeps generating complaints you haven’t fully understood.

The uncomfortable truth about being “on the inside”

Here’s what nobody tells you when you start working on a product: the moment you join the team, your perspective starts to become less valuable as a user stand-in, and more valuable as a translator which someone who can take what real users tell you and turn it into design decisions.

That’s actually a more interesting and more important role than being a self-appointed user representative. It means your job is to close the gap between the people building the product and the people using it. And you can’t close a gap you’re not aware of.

Don’t position yourself as the user and position yourself as the advocate for the user. There’s a big difference

Being an advocate means saying “let’s check that with real users” instead of “I think users would.” It means treating your own instincts as hypotheses to be tested, not conclusions to be defended. It means being curious about the moments where your assumptions turned out to be wrong because those are the moments where you actually learn something.

Making this real, today

You don’t need a research team, you don’t need a budget, you need a habit shift.

Start by separating two kinds of conversations in your team: the “what do we think users want?" and the "what did users actually tell us?" The first one is fine for generating ideas, and the second one is what should drive decisions.

And next time you catch yourself or someone on your team starting a sentence with “if I were a user…” you must interrupt and ask, "How do we actually know that? What would it take to find out?”