Your Expert Is Not Your User

Experts offer insights, but they’re not your users. Build better software by balancing in-house input with market feedback.

If you develop or design enterprise software—especially for industry-specific applications—you probably recognize user stories that start like this:

As a user, I would like to … so that I can …

It captures a critical, essential part of software development:

Understand your user. Build for your user.

The reality is that users don’t always have a say in the development process.

As a UX designer, my role was to represent the user perspective. That meant doing research—going out there, talking to users, asking questions and understanding their behavior through empathy and proven methods.

At the end of the day, I wanted to design with the user in mind.

And the same goes for developers. They ask questions about logic, flow and outcomes because what we’re ultimately trying to do is simple:

Build software that helps someone accomplish a task.

But my users were out in the field. They worked under time pressure. They were on 12-hour shifts. They were all over the world. It wasn’t as simple as hopping on a call, sending out a survey or visiting them on site.

The truth is: it’s common for developers and designers to build software from a distance. And, unfortunately, user research isn’t always prioritized enough to include user input as a constant in the process.

So what most companies do—and rightfully so—is bring in expertise. They bring in the expert. As an intermediate.

But that’s risky too.

Because the expert is not your user.

How Experts Show Up in Software Development

Most organizations that build enterprise software have in-house expertise. The form that expertise takes can vary—depending on the project phase, level of organizational support, strategic context, leadership involvement and how design is integrated into development.

In my experience, expert involvement typically shows up in three ways:

Internal or External Business Consultants and Analysts

These people translate customer needs—including those of the end user—into something the business can act on. They’re usually externally focused and available only in a reactive role. Some are full-time, others part-time.

Product Owners or Product Managers

These are usually people who came from the field or domain and later moved into IT or development. They may no longer fully represent the end-user perspective—though a good product owner stays close to it.

The SME—Subject Matter Expert

Let’s just call them “the expert”: someone who has performed the user role themselves—or still does so part-time. SMEs often serve as internal representatives of that role.

In the teams I worked on, we paired each feature with an SME, and typically worked in a triangle: SME, UX designer and product owner. Each brought a slightly different angle, but we shared one goal: discovering, creating and defining the right product requirements.

4 Pitfalls to Avoid When Relying on Experts

Working with experts is a blessing—because honestly, you can’t know what they know. You haven’t experienced what they’ve experienced. And you probably never will.

I’ve worked with many different experts. And there are four things you absolutely need to avoid when you do.

Expert Bias

This is often referred to as the curse of knowledge: assuming others know what you know.

A very common thing I’ve heard from experts when simplifying workflows or adjusting terminology:

“The user is not stupid.”

That simple statement reveals a bigger tension: simplicity vs. complexity.

Experts are used to working on high-cognitive-load projects. They’re comfortable spending energy to understand. But good design is meant to reduce that load—to make decisions easier and help people move faster.

Assuming everyone knows what the expert knows leads to overcomplication. And it often creates barriers for junior users—the very people your product should support too.

Anecdote Over Evidence

Stories matter. Experts help visualize and humanize what users go through.

But the risk is that anecdotes start to sound like facts—and real evidence gets ignored.

An expert might recall hating a flow or avoiding a feature—but that doesn’t mean it’s useless. It just means we need to check the data.

I’ve seen experts become sources of truth, replacing research entirely. And when that happens, data stops driving decisions.

Over-Reliance on a Single Voice

Data gives you scale. It brings in input from across the whole user base—not just one voice. But when teams rely too much on an expert, the product can be too much based on personal preference.

I’ve seen it happen: no room for other perspectives, no space for insights from non-experts. In the end, we weren’t designing for users. We were designing for the expert.

Skipping Market Validation

This might be the biggest risk of all.

At the end of the day, having an expert on the team can lead you to skip validation. I’ve seen it myself: we had the potential, but didn’t listen to the market enough. We iterated internally—but lost the market opportunity.

Without user feedback, we assumed we were right. And we were close. But not close enough.

3 Ways to Make Experts Your Allies

Cross-Check

Validate your assumptions—with testing, with research. Cross-check everything. With data.

Make sure your expert is a real advocate—an echo of the market, not a substitute for it. When that’s true, their input, experience and ideas will strengthen your entire development cycle.

You’ll move faster and smarter because your team already holds a lot of the needed insight. That reduces the need for expensive, time-consuming research phases.

Collaborate

The expert shouldn’t write requirements and expect us to just follow. It needs to be a collaborative effort.

I’ve seen developers shift how experts think about the domain. That back-and-forth made space for real innovation. I’ve also done user research side-by-side with experts. I would interview users—and ask the “stupid” questions:

Why do you do that? What is this? What does that mean?

But I brought the expert along as a translator.

Cocreate

I’ve worked with amazing experts who had a clear vision for the future. They knew how software could change the game. They’d felt the pain. They’d used bad tools. They knew what was missing.

So when we cocreated (sketches, wireframes, prototypes), we built some of the best features I’ve seen. We actually built market-leading, groundbreaking features.

In those moments, I wasn’t the designer. I was the facilitator. The expert led the thinking.

And unlocking that kind of creativity? That drives real success.

Conclusion: Respect the Expert, Champion the User

The truth is, having an expert on your team is a goldmine. It can give you a real edge—but it’s also a risk. A potential trap. Make sure they’re a user’s advocate, not a stand-in for the user.

Collaborate. Work together. But never lose the user representation.

In the end, it’s the market that will tell you what works—not the people who build the software.

And honestly, I couldn’t have done it without an expert by my side.

But without users? There wouldn’t have been a point in doing it at all.