
Got a deck in my email last Tuesday. Subject line: "UX Strategy for [Product Name]."
I was genuinely curious. Maybe a little optimistic. (I know, I know.)
Opened it.
Slide 1: Screenshot of Stripe's pricing page
Slide 2: Screenshot of Notion's sidebar
Slide 3: Screenshot of Linear's command palette
Slide 4: "We want something clean and modern like these"
Slide 5: Three Dribbble shots
Slide 6: "Questions?"
Six slides. Five screenshots. Zero strategy.
When I asked about their target users, their core problem, what success actually looks like – the response was: "We can cover that in the kickoff call, but the visual direction is what we need to align on first."
Translation: We spent 17 minutes Googling competitors, screenshotted the pretty ones, and now we're ready for you to design our entire product.
(Also: We think picking colors comes before understanding the problem. This will end well.)
I don't take these projects anymore. Not because I can't design from inspiration – I can. But because I've watched this exact pattern play out enough times to know how it ends.
Week 7. $18K spent. Designs that look great in screenshots but solve nothing. Founder saying "something feels off but I can't explain what."
The what is: you designed for aesthetics you liked instead of problems you understood.
Let me show you how this happens.
You think: "We're being smart. Why reinvent the wheel? These companies figured it out. We'll learn from the best and adapt it to our needs."
What's actually happening: You're copying homework from students who took a completely different test.
Stripe optimizes for trust in financial transactions with enterprise buyers who need compliance documentation.
Notion optimizes for flexibility for knowledge workers who want to customize everything.
Linear optimizes for speed for developers who hate clicking more than once.
Those are three different strategies for three different audiences with three different core problems.
When you screenshot all three and say "combine these," you're not being strategic. You're asking me to design for three contradictory user types simultaneously while optimizing for three conflicting priorities.
The designs will look cohesive in Figma. They'll fall apart the moment real users touch them because they're optimized for nothing specific.
Here's what your screenshot deck tells me:
Which companies you admire ✓
What aesthetics you like ✓
Here's what it doesn't tell me:
Who you're designing for (and "product managers" doesn't count)
What problem you're solving that competitors aren't
Why users would choose you over doing nothing (your actual competitor)
What success looks like beyond "intuitive and modern"
Whether any of your assumptions have been tested
That gap – between "I like how Stripe looks" and "product design strategy for our specific users solving our specific problem" – is where projects go to die.
What you say: "We want Stripe's pricing structure, Notion's sidebar, Linear's shortcuts, and Figma's collaboration. Make it cohesive."
What I hear: "We don't know what we're optimizing for, so we're optimizing for everything, which means we'll deliver nothing particularly well."
What happens: Six weeks later, you have a product that's:
Too flexible (Notion influence) for users who want opinionated guidance
Too fast/minimal (Linear influence) for users who need hand-holding
Too collaborative (Figma influence) for users working solo
Trying to signal trust (Stripe influence) while also being playful and modern
Users land on it confused. They don't understand what problem you solve or who you're for. Your "best of everything" approach means you're not the best at anything specific.
And when activation tanks, you blame the designer for not making it "cohesive enough."
The cohesion wasn't the problem. Trying to serve four different user types with four conflicting priorities was the problem.
What you say: "We've been talking to customers for months. We don't need research. We just need the designs."
What you mean: "The founder has talked to three customers who were polite at a conference."
What happens:
I ask: "Who specifically are we designing for?"
You answer: "B2B SaaS companies" or "product teams who want to be more productive."
That's not a user. That's 47,000 different user types with different contexts, different problems, different workflows, different priorities.
A product manager at a 8-person startup has completely different needs than a product manager at a 600-person enterprise. One is wearing six hats and needs speed. The other is coordinating across twelve teams and needs structure.
But you've convinced yourself "we know our users" because you've talked to some people who said your idea sounds interesting.
Three months later, your SaaS product design is live. Half your users complain it's too simple. The other half complain it's too complex. Both are right – because you tried to serve everyone instead of being exceptional for someone specific.
And when I point out "this is what happens when you design for 'product managers' instead of for Steve, the solo PM at a growth-stage B2B SaaS who's managing three products simultaneously with zero help," you act surprised that specificity matters.
The timeline:
Week 1: "Let's start designing. We can figure out strategy as we go."
Week 4: Designs are 50% done based on your screenshot mood board.
Week 7: "Actually, can we define our strategy now? These don't feel right."
What happened: You built the house, then hired the architect to explain why the bathroom should've been somewhere else.
Sure, I can tell you. But the bathroom's already built.
The real cost:
You spent $18K designing for a user you hadn't defined, solving a problem you hadn't articulated, optimizing for success metrics you hadn't identified.
Now we're redesigning everything because – surprise – "clean and modern like Stripe" wasn't sufficient strategic direction.
The $12K you saved by skipping upfront strategy work? You're now spending $25K to redo what we already did, plus another $8K to fix the technical debt from implementing designs that didn't account for your actual architecture constraints.
(The math never seems to math until after the mistake. Then suddenly everyone understands why strategy comes first.)
What you send: "Here's our competitive analysis. We studied Stripe, Notion, Linear, and Figma."
What I see: You took screenshots and wrote down which companies you admire.
Real competitive analysis asks:
What are they optimizing for?
What trade-offs did they make?
Who are they targeting vs who are you targeting?
Where are the gaps you could fill?
What did they try that failed?
Why did they design X this way instead of Y?
Your "analysis" answers:
They look nice
We should look similar
(end of analysis)
What happens:
You copy Stripe's pricing page structure. Stripe spent 3 years and $400K testing, iterating, and optimizing that page for enterprise buyers who need trust signals and compliance documentation.
Your target users are small business owners who want to try your product for $49/month. They don't need compliance docs. They need to understand if your product solves their problem in the next 20 seconds before they bounce.
But you copied Stripe's homework because it looked trustworthy. Now your SaaS website design signals "expensive enterprise tool" to users looking for "affordable small business solution."
Your conversion rate is 0.8%. Industry average is 3-5%. You're losing 80% of potential customers because you optimized for the wrong audience by copying a company serving a completely different market.
You can point at a screenshot and say "like this." Everyone nods. Feels productive.
Strategy is invisible – questions, frameworks, trade-offs, decisions. Can't screenshot it. Can't point at it in a meeting. Feels theoretical, optional, less "real."
But here's what actually happens:
Without strategy, you're designing for aesthetics that worked for someone else's completely different situation. Like seeing someone wearing a suit at their wedding and deciding to wear the same suit to your job interview, your kid's soccer game, and your beach vacation.
The suit looked good in one specific context. That doesn't mean it works everywhere.
"Who are we designing for?" sounds simple until you try to answer it specifically.
"B2B SaaS companies" feels like an answer. It's not. It's you avoiding saying "I don't actually know who our specific user is because we haven't talked to enough people yet."
"What problem are we solving?" sounds simple until you realize "help teams be more productive" could mean 400 different things.
Startups skip strategy because strategy forces you to confront questions you don't have answers to yet. Screenshots let you feel like you're making progress while avoiding the hard thinking.
You're optimizing for "when can we start designing" instead of "what should we design."
Starting fast feels like winning. But starting fast in the wrong direction means you'll need to stop, turn around, and start again later. Which is slower than just figuring out the direction first.
I've watched founders spend $35K and three months building the wrong thing because they were too impatient to spend $12K and three weeks understanding what the right thing was.
This one's not your fault. Most founders haven't seen real product strategy work. They've seen outputs (interfaces, prototypes) and inspiration (Dribbble, competitor screenshots).
Strategy happens in between. It's the "why" that informs the "what."
But if you've never seen strategy done properly, it's easy to think:
Screenshots = competitive analysis
"Users want intuitive interfaces" = user research
"Clean and modern" = design principles
"Like Stripe but for our space" = positioning
None of those are strategy. They're the things people say when they're skipping strategy and don't realize it.
Before I take a project, I need to know if you've done the thinking or if you're expecting me to guess at your entire business strategy while designing your interface.
If you can't name three specific people – what they do daily, what frustrates them, why they'd choose your product over doing nothing – you don't have a strategy. You have a market hypothesis.
The difference:
Market hypothesis: "Product managers need better tools"
Strategy: "Solo PMs at 20-50 person B2B SaaS companies who are managing 2-3 products simultaneously with zero design support and keep getting asked 'when will this be ready' by founders who don't understand product development"
One is a vague target. The other is someone I can actually design for.
"Users love it" isn't an answer.
What metric changes if this works?
Activation rate goes from 23% to 40%?
Time to first value drops from 8 days to 2?
Feature adoption for your core workflow hits 60%?
Support tickets about "how do I..." drop by half?
If you don't know what we're optimizing for, I'm designing blind. I'll make something that looks like your screenshots and we'll both hope it moves some number in the right direction.
That's not design. That's expensive guessing.
If your strategy is based entirely on:
What you think users want
Looking at competitors and imagining your product is similar
Conversations with three friendly customers who were polite
That's not validation. That's untested assumptions with a Pinterest board attached.
Real validation means:
You talked to 15+ potential users systematically
You asked what they do now (not what they think of your solution)
You identified patterns in their workflows, frustrations, workarounds
You tested whether your core hypothesis is actually true
The difference between validated and unvalidated strategy? Week 7.
Validated: "The designs are working exactly as expected because we understood the problem."
Unvalidated: "Something feels off but I can't explain what."
I'm not saying you need six months of research and a 47-page strategy document before you can design anything.
I'm saying: if your entire strategic foundation is "we Googled good designs and picked the ones we like," don't act surprised when the work doesn't land.
You're not hiring a designer to make your screenshots prettier. You're hiring them to translate your strategy into interface decisions that solve your users' problems in a way that achieves your business goals.
If you don't have the strategy part, the designer has two options:
Make up your strategy for you (guessing at your user segments, value prop, positioning, success metrics, and design principles) and hope the guesses are right
Just make it look like your screenshots and hope that's close enough
Neither works.
You're not saving money by skipping strategy. You're just moving when you pay for it.
Upfront strategy: $12K-15K, 3-4 weeks, done once.
Post-design strategy: $25K to redo what you already built + $8K in technical debt from implementing the wrong thing + 8 weeks of lost time + whatever momentum you killed by launching something that doesn't work.
But the real cost isn't money or time.
It's Week 7.
Sitting in a call looking at designs that look great in Figma. Professional. Polished. "Clean and modern" just like you asked for.
And knowing something's fundamentally wrong but not being able to articulate what because you designed for aesthetics you liked instead of problems you understood.
That feeling – that expensive, sinking, "we built the wrong thing" feeling – is what I'm trying to help you avoid.
Do the strategy work first. Or budget for me to do it with you.
But don't Google competitor screenshots for 17 minutes, add them to a deck, call it "UX strategy," and expect professional product design to follow.
The companies that skip strategy and jump straight to design? They all figure this out eventually.
Usually around Week 7.
When the designs look exactly like the screenshots they sent. And nothing else works.
(By then the screenshot deck has been renamed "Inspo_OLD_v3_FINAL_archive_2024.pdf" because nobody has the heart to delete it. But they also can't look at it anymore without feeling slightly sick about how much time and money they wasted designing for someone else's users instead of their own.)
0
8
0