The Assumption Trap
Every designer makes assumptions. It’s unavoidable. The moment you start thinking about a problem, your brain fills gaps with educated guesses based on your experience.
The dangerous part isn’t making assumptions. It’s treating them as facts.
In my EdTech work, I’ve seen teams make catastrophic assumptions:
- “Students want gamification” (They actually found it patronizing)
- “Teachers need more features” (They needed simpler tools, not more complexity)
- “Parents check progress daily” (Most checked monthly at best)
Every one of these assumptions felt reasonable. Every one led to wasted effort. Every one could have been validated before building.
The Cost of Unvalidated Assumptions
Let me be specific about what happens when you build on assumptions:
Wasted Development Time
That three-month feature I mentioned? That was three months of design, engineering, QA, and project management time. Thousands of hours. All wasted because we never validated whether anyone wanted it.
Opportunity Cost
While we built that useless feature, we could have been solving actual user problems. We missed opportunities that would have generated real value.
Team Morale
Nothing demoralizes a team faster than building something nobody uses. Designers feel their work doesn’t matter. Engineers question product decisions. Everyone starts doubting the process.
User Trust
When you ship features users don’t want or need, they start ignoring your updates. They assume new features will be irrelevant. You train them not to pay attention to your product evolution.
This is why I’m paranoid about assumptions now. One expensive lesson was enough.
Common Dangerous Assumptions
Here are assumptions I’ve seen destroy projects. I’ve made most of these myself:
“Users will figure it out”
No, they won’t. If it’s not immediately obvious, most users will give up. I once watched five consecutive users fail at the same task we thought was “intuitive.”
“Users want what they say they want”
Surprisingly, this is also an assumption. Users are terrible at predicting their own behavior. They’ll say they want feature X, then never use it when you build it.
“We’re just like our users”
You’re not. You know too much. You understand the product too deeply. You can’t see it with fresh eyes anymore. This is the “curse of knowledge,” and it’s deadly.
“This worked for [Famous Company], so it’ll work for us”
Different users. Different problems. Different context. What works for Netflix doesn’t necessarily work for your EdTech startup.
“We don’t have time for research”
You know what takes more time? Building the wrong thing, then rebuilding it after it fails. Research is faster than failure.
Every one of these assumptions feels logical in the moment. Every one has derailed projects I’ve worked on.
What User Research Actually Does
Research isn’t about proving you’re right. It’s about discovering what you don’t know.
Good research:
Challenges Your Assumptions
It should make you uncomfortable. If research confirms everything you already believed, you probably asked leading questions.
Reveals User Context
You learn not just what users do, but why they do it, where they do it, and what else is happening in their lives when they use your product.
Uncovers Unmet Needs
Sometimes the biggest opportunities aren’t what users explicitly ask for. They’re the problems users have gotten so used to that they don’t even complain anymore.
Builds Empathy
Watching real people struggle with your product changes how you design. You start seeing through their eyes instead of your own.
Creates Shared Understanding
When your entire team watches user research, everyone aligns on what matters. Fewer debates about opinions, more focus on user evidence.
Research You Can Do Right Now
You don’t need a research degree or a massive budget to start validating assumptions. Here’s what I recommend:
- Five-User Testing
Jakob Nielsen’s research shows that testing with just five users uncovers 85% of usability issues. You don’t need 50 people. You need five good conversations.
- “Teach Me How You…” Sessions
Ask users to show you how they currently solve the problem your product addresses. Don’t show them your solution. Just watch and listen.
- Support Ticket Analysis
Your support tickets are free research data. What are people confused about? Where do they get stuck? What language do they use?
- Analytics Review
Look at where users drop off. Which features get ignored? Where do they spend time? Behavior often contradicts what people say they do.
- Competitor Research
How do your competitors’ users talk about their products? What do they love? What frustrates them? You’ll learn about your space without building anything.
I use all of these regularly. None require special tools or training. They just require curiosity and humility.
The Most Important Research Question
Here’s the question I ask before designing anything:
“How would I know if I’m wrong about this?”
If you can’t answer that question, you’re building on unvalidated assumptions.
For example: • Assumption: “Users want a dark mode” • Validation: “I’ll add an analytics event to see how many people use light vs. dark mode in similar apps”
- Assumption: “This onboarding flow is clear”
- Validation: “I’ll watch five people go through it and count how many complete it without help”
- Assumption: “Teachers need a gradebook feature”
- Validation: “I’ll interview 10 teachers about how they currently track grades and what problems they face”
Every assumption becomes testable when you ask: “How would I know if I’m wrong?”
That question has saved me from countless bad decisions.
When Students Don’t Understand Research
I see designers make these research mistakes constantly:
Mistake 1: Doing Research Once
Research isn’t a phase. It’s continuous. You research before designing, during design to validate, and after launch to learn what’s actually happening.
One student told me: “We did research at the start. We’re done now.”
No. Users change. Context changes. Your product changes. Research never stops.
Mistake 2: Ignoring Negative Findings
If research contradicts your vision, that’s the most valuable finding possible. Don’t dismiss it. Don’t explain it away. Change your vision.
Mistake 3: Asking What People Want
Don’t ask “Would you use this feature?” Watch what they actually do. Behavior trumps opinions every time.
Mistake 4: Only Talking to Friendly Users
Your power users love everything. Talk to people who barely use your product. Talk to people who abandoned it. That’s where the real insights are.
Mistake 5: Confusing Data with Understanding
“70% of users click here” is data. Understanding why they click—that requires deeper research. Numbers tell you what. Conversations tell you why.
From Assumptions to Evidence
Here’s my process for every project:
Step 1: List Your Assumptions
Write down everything you believe about users, their problems, and potential solutions. Be honest. Get it all out.
Step 2: Prioritize by Risk
Which assumptions, if wrong, would invalidate your entire approach? Those are the ones to test first.
Step 3: Design Quick Tests
How can you validate each assumption with minimal effort? Don’t over-engineer research. Simple tests answer important questions.
Step 4: Act on What You Learn
Research is worthless if you ignore the findings. Be willing to change direction based on evidence.
Step 5: Share Widely
When research reveals something important, make sure your entire team knows. One conversation with users can inform dozens of decisions.
This process has saved me from more bad decisions than I can count.
The Humility Required
The hardest part of research-driven design isn’t the methods. It’s the mindset.
You have to genuinely believe you might be wrong. About everything.
This is hard for designers. We’re trained to have vision. To be confident. To defend our decisions.
But the best designers I know balance confidence with curiosity. They have strong opinions, loosely held. They’re passionate about solving user problems, not about specific solutions.
I once had a junior designer tell me: “But this is obviously the right solution. Why would we test it?”
I showed them the recording of five users trying to use their “obvious” solution. Four failed completely.
“Obviously” is the most dangerous word in design.
When you find yourself thinking something is obvious, that’s exactly when you need research. Because if it’s truly obvious, research will confirm it quickly. And if it’s not obvious, research will save you from an expensive mistake.
Research is how you turn “I think” into “I know.” And in UX, knowing is everything.
Don’t Forget These Key Points
- Assumptions are unavoidable, but treating them as facts is dangerous—always identify and validate critical assumptions before building
- The most valuable research findings contradict your expectations—if research only confirms what you believed, question your methods
- Research is continuous, not a one-time phase—keep learning about users throughout the entire product lifecycle
- Watch what users do, not just what they say—behavior reveals truth better than opinions
- Ask “How would I know if I’m wrong?”—every assumption should have a testable validation method