Engineers and designers explain that, being people themselves, they understand people. But this argument is flawed.
We simultaneously know too much and too little. We know too much about the technology and too little about how other people live their lives and do their activities.
Anyone involved with a product is so close to the technical details, design difficulties, and project issues that they're unable to view the product the way an unattached person can.
The gap is real
When I started in design, I assumed my instincts were enough. I'm a user too, right? I use apps every day. I know what good design feels like.
But here's what I missed: I'm not the user. I never was.
I know where every feature is because I built it. I understand the mental model because I created it. I know the workarounds for the bugs because I've reported them.
My users? They just want to get something done and move on with their lives.
The engineering method is broken
Here's something that fundamentally changed how I think about building products: the traditional engineering method has it backwards.
The traditional approach
Most teams follow this linear path:
- Define the problem
- Do background research
- Specify requirements
- Brainstorm, evaluate & choose solution
- Develop & prototype solution
- Build/test solution
- Check if it meets requirements
If it doesn't meet requirements, you go back and iterate. Sounds logical, right?
The UX-focused approach
But there's a better way. Flip the order:
- Define the problem
- Do background research
- Brainstorm, evaluate & choose solution (before requirements!)
- Develop & prototype solution
- Specify requirements (after you've learned from prototyping)
- Develop/prototype again
- Check if it meets requirements
- Build/test solution
The key insight: requirements should come from learning, not from assumptions.
Based on results and data, you make design changes, prototype, launch/test again, and review new data. It's an iterative loop, not a waterfall.
Typical vs. UX-focused requirements
Typical requirements are very different from their UX-focused counterparts. And most teams get this wrong.
Typical requirements (the problem)
Here's what typical requirements look like:
"Implement a third-party human/machine-readable knowledge base (e.g. ZenDesk, Confluence) that:
- Stores help documents, manuals, troubleshooting information and FAQs
- Allows support engineers to create articles based on predefined templates
- Allows users to opt-in to technical alerts"
Sounds reasonable. But ask yourself:
- How do we know we need a third-party vendor?
- How do we know this is what people want to see/use?
- How do we know this feature is necessary?
- How do we know users want to do this or will do this?
These questions rarely get asked. We jump to solutions before understanding the problem.
UX-focused requirements (the solution)
Now compare that to UX-focused requirements:
"Develop a seamless self-service experience that:
- Reduces user frustration by presenting help topics in simple terms they can understand
- Gives admins the ability to accept and manage inbound ticket requests from any channel — email, web, social, phone, or chat
- Reduces our current support request volume by a minimum of 43%"
Notice the difference? One describes features. The other describes outcomes.
The problem with "requirements gathering" sessions
How many of your requirements gathering sessions actually provided clues about:
- What the ideal user experience should be like?
- Who you're designing and building for — beginners, intermediates, or experts?
- What the user's journey might be from start to finish — or how many of those journeys there are?
- How users might move through workflows or screens?
- How simple or complex the UI should possibly be?
If you're honest, the answer is probably "not many." Most requirements sessions focus on features, not experiences.
What are UX-focused requirements?
Here's what makes requirements truly UX-focused:
1. They don't assume anyone truly knows
UX-focused requirements don't assume that anyone truly knows, beyond doubt, what needs to be designed or built. Humility is built into the process.
2. They generate ideas, not specifications
UX requirements generate ideas. Not features, not specifications. Ideas to be explored, qualified, and validated before they become requirements.
3. They're born from iterative activity
UX requirements are born from iterative activity: user and stakeholder research, interviews, observation, prototype creation, evaluation and testing. They emerge from learning.
4. They focus on desired outcomes
UX requirements focus on desired outcomes, not features or functionality. What do users expect and need to be able to do? What does the business need them to do? What's the desired outcome of product use?
Act on their behalf, not their requests
There's a crucial distinction here:
Don't act on the requests of your customers. Act on their behalf.
Customers will tell you what they think they want. But what they actually need is often different. Your job is to understand the underlying problem, not just implement the stated solution.
How to bridge the gap
- Watch real people use your product. Not in a lab. In the wild. The friction points will be painfully obvious.
- Maximize your exposure hours. The more time you spend observing users, the better your design intuition becomes.
- Seek the collective truth, not just one opinion. Individual feedback can be misleading. Patterns across multiple users reveal the real issues.
- Be ruthlessly truth-seeking. The truth can be painful. Your favorite feature might be the one causing confusion.
- Question every requirement. Before building anything, ask: How do we know users want this? How do we know this is necessary? What outcome are we actually trying to achieve?
- Prototype before you specify. Let learning inform your requirements, not the other way around.
The uncomfortable reality
The best designers I know are the ones who've fully internalized this: We are not our users.
And that's okay. In fact, it's liberating. Once you stop assuming you know what users want, you can finally start learning what they actually need.
The gap between us and our users isn't a bug. It's a feature — if we use it to stay curious, stay humble, and keep learning.