A team in mid-sprint, tired but caffeinated. You’re in Figma or Slack or Notion, staring at a half-finished flow someone labeled “v3-final-ish.”
Someone says, “Let’s just tweak the copy so it’s less confusing.”
Another chimes in: “Legal needs to approve it anyway.”
A third shrugs: “Our sales team just needs something to demo.”
No one asks:
“Who’s struggling right now that this helps?”
And that’s where real UX dies.
The “Who Are We Helping?” Test
Every feature. Every flow. Every headline.
Should answer one thing:
Who does this remove friction for — today?
Not in theory. Not eventually. Not after a product launch.
If your answer is:
– “The client from three months ago who wanted exports”
– “The board”
– “It makes our roadmap slide look complete”
You’re not helping. You’re appeasing.
Example Walkthrough: The Reporting Tab
Say you’re building a reporting tab.
Bad answer: “It looks good to show stakeholders what we’ve built.”
Worse answer: “One customer mentioned they wanted more visibility.”
Better answer: “Our current customers export data just to run simple weekly summaries. This gives them what they need in 2 clicks — no export.”
This shift changes everything:
– You remove bloat
– You prioritise defaults
– You write copy that tells users why it exists, not just what it does
Red Flags You’re Designing for the Wrong Person
1. “Nobody’s complained.”
Silence ≠ success. It often means “I gave up.”
2. “It’s good for the demo.”
Cool. But can your actual users even find it?
3. “We’ll walk them through it.”
If it needs a walkthrough, it’s broken.
4. “It looks more complete.”
Complete doesn’t mean useful.
5. “This unlocks a future feature.”
Great. But what does it do right now?
6. “Internally, everyone gets it.”
Internally, everyone built it. Doesn’t count.
7. “It’s consistent with the rest of the UI.”
So is every mistake that never got fixed.
What Happens When You Ignore This
We’ve seen it play out:
– A startup builds an advanced dashboard with zero adoption. Why? No one needed it yet.
– An onboarding flow that skips explaining the product’s core action because “it’s obvious.”
– A settings page that only exists because one client wanted a toggle.
Each case had good intentions.
Each missed the point: This wasn’t built for the user. It was built for the org.
A Quick Way to Fix It
You don’t need a full research cycle to course-correct. Start here:
1. “Explain It to a Stranger” Sessions
Grab someone who hasn’t seen the feature. Ask them to walk through it without context. Watch where they stall.
2. Cut Until You Can Name the Benefit
If you can’t describe the value in one sentence, remove it — or rename it.
3. Ask Better Questions
Not “Do you like this?”
Ask: “What confused you?” “What would you expect to happen here?” “What were you hoping to do next?”
One Example That Changed Everything
A client once built a feature for “pro users” that added friction for everyone else.
We cut it.
Rebuilt a version based on a single user insight: “I just want to see what changed, fast.”
Result: a lighter flow, higher engagement, and fewer support tickets.
No new feature. Just the right one.
Final Thought
If you can’t point to the person you’re helping, you’re probably helping no one.
Design for the person who’s stuck. Not the one who made the most noise in the roadmap meeting.
And if you’re still unsure?
Ask.
Then build the thing they’ll thank you for.