How to Present Design Decisions When You Have Imposter Syndrome
(Or: How I learned to stop apologizing for my brain and start shipping good work)
I need to tell you something.
I’ve been doing this for a while.
Designing for games. Long enough to know what I’m doing. Long enough that people assume I’ve got it figured out.
And I still feel like a fraud every single time I have to present a design decision.
Every. Single. Time.
The voice in my head goes something like this:
“They’re going to ask why I chose that button placement and I won’t have a good answer and they’ll realize I just... put it there because it felt right and then they’ll know I’m not a real designer and—”
You know the drill.
The thing is, I do have good reasons. Years of pattern recognition. Hundreds of shipped products. User research. A&B testing. All of it.
But imposter syndrome doesn’t care about your resume.
It just whispers: “Yeah, but do you really know? Or did you just get lucky?”
Here’s what I learned...
The hard way, over two and a half decades of faking it (and occasionally making it).
You don’t beat imposter syndrome by becoming more confident.
You beat it by building a presentation system that works even when your brain is screaming that you’re a fraud.
Because confidence is unreliable.
Systems are not.
The Thing Nobody Tells You
When you present design decisions, stakeholders aren’t looking for perfection.
They’re looking for thinking.
They want to know:
What problem you were solving
What options you considered
Why you chose this direction
What trade-offs you made
That’s it.
They don’t need you to be the Design Genius Who Never Makes Mistakes™.
They need you to be someone who can explain your process clearly enough that they trust you’re steering the ship.
(Even when you feel like you’re drowning in doubt.)
The Framework That Saved My Ass
I’m going to give you the exact structure I use.
It’s called SPARK, and it was originally meant for job interviews, but it turns out it works for any situation where you need to defend your design while your brain is telling you you’re a hack.
S - Situation
What was the actual problem?
P - Problem
What was broken or needed solving? Why did it matter?
A - Approach
What did you specifically do? What was your unique angle?
R - Result
What happened? Metrics, feedback, outcomes.
K - Knowledge
What did you learn? What would you do differently?
Here’s why this works when you have imposter syndrome:
It’s not about you being brilliant.
It’s about showing your thinking.
When my brain is screaming “they’re going to know you’re a fraud,” I just follow the structure.
Situation. Problem. Approach. Result. Knowledge.
One after another.
Like following a recipe when you’re too tired to improvise.
What This Looks Like In Real Life
Bad presentation (the imposter syndrome version):
“So... um... I redesigned the onboarding flow. I thought it would be better if we simplified things because the old version was kind of confusing? I mean, maybe? People seemed confused. So I made it cleaner. Does that make sense? Is this okay?”
Painful, right?
You’re asking for permission. Apologizing. Hedging. Waiting for someone to tell you it’s wrong.
Now watch what happens with SPARK:
Situation:
“New users were dropping off at 60% during their first session.”
Problem:
“The onboarding was overwhelming them. Five different cognitive loads in the first two minutes. People were abandoning before they understood the value.”
Approach:
“I mapped the entire user journey and broke the onboarding into three progressive steps. Each step had a clear win, so users got early validation. This spaced out the cognitive load instead of hitting them with everything at once.”
Result:
“Drop-off went from 60% to 35% in two weeks. Average time-to-first-value decreased by 40%. Support tickets about ‘not understanding how to start’ dropped by half.”
Knowledge:
“I learned that users don’t need to understand the whole system upfront. They just need to understand the next step. If I did this again, I’d test progressive disclosure earlier in the design phase instead of after launch.”
See the difference?
Same designer. Same level of imposter syndrome.
But one version sounds like someone who knows what they’re doing.
Because you’re showing your process, not asking for validation.
The Tricks That Actually Help
1. Lead with the problem, not your solution
When you start with “I designed this...” you’re putting yourself (and your fragile ego) at the center.
When you start with “Users were struggling with X...” you’re putting the problem at the center.
Much easier to defend a problem than to defend your worth as a human.
2. Say “I” instead of “we” (even when it feels scary)
Imposter syndrome makes you want to hide behind the team.
“We decided...”
“The team thought...”
“Everyone agreed...”
Stop that.
“I chose this direction because...”
“I noticed that...”
“I tested three approaches and...”
You did the work. Own it.
(Even if your voice shakes.)
3. Prepare for the questions that scare you most
You know the one.
The question that makes your stomach drop.
“Why did you make that choice?”
“Did you consider [obvious alternative you totally forgot about]?”
“What’s the data behind this?”
Write down your answers before the meeting.
Not because you’ll read them.
But because the act of writing forces your brain to stop spiraling and actually think.
4. Remember: Designers who seem confident are usually just better at hiding their doubt
That senior designer who presents like they’ve never questioned a decision in their life?
They have.
They’re just not showing you the 3am panic spiral about whether that button should be blue or green.
Confidence is a performance.
You can learn the choreography.
What To Do When Someone Challenges Your Decision
This is where imposter syndrome loves to strike.
Someone questions your choice.
Your brain immediately translates this as: “They’ve discovered you’re a fraud. Abort mission. Flee the building.”
Here’s what to do instead:
Pause.
Take a breath.
Then say: “That’s a good question. Let me walk you through my thinking.”
And then... you go back to your framework.
“The problem I was solving was X. I considered Y and Z as alternatives. I chose this direction because of these trade-offs. Based on A, B, and C.”
You’re not defending yourself.
You’re explaining your process.
Big difference.
And if they have a point?
If they bring up something you genuinely didn’t consider?
Say so.
“You know what, I didn’t think about that. That’s worth exploring.”
This is not admitting you’re a fraud.
This is called being a professional who collaborates well.
The Thing That Changed Everything For Me
I used to think I needed to stop feeling like an imposter before I could present confidently.
Wrong.
I needed to present confidently despite feeling like an imposter.
The feeling doesn’t go away.
I’ve been doing this for 25 years and I still get the voice.
“They’re going to figure out you don’t know what you’re doing.”
But now I have a system.
And the system works even when I don’t feel confident.
SPARK. Prepare answers. Lead with problems. Own my decisions.
Follow the structure.
Trust the process.
Ship the work.
Your Turn
You don’t need to feel confident.
You just need to sound like someone who’s done their thinking.
Because here’s the secret...
You have done your thinking.
Your imposter syndrome is lying to you.
You made those design decisions for reasons. Good reasons. Based on experience and research and pattern recognition and all the things that make you a designer.
You just need a way to show that thinking that doesn’t require you to feel like a genius.
That’s what SPARK does.
It gives you a script to follow when your brain is too busy panicking to improvise.
So next time you have to present...
Write down your SPARK framework before the meeting.
Prepare answers to the scary questions.
Lead with the problem, not yourself.
And remember:
Imposter syndrome doesn’t mean you’re a fraud.
It means you care enough about doing good work to worry about getting it wrong.
That’s actually the hallmark of a good designer.
The frauds never worry.
So yeah...
Still figuring this out, one presentation at a time.
P.S. - If you found this useful, hit that subscribe button. I write about UI/UX design, ADHD, AI disruption, and the uncomfortable stuff the games industry isn’t talking about. Sometimes all at once.