Got on a call last month with a potential client. Series A SaaS company, 18 people, looking for design help.

“Before we start, can you walk us through your design process?”

I should’ve known.

They screen-shared a 40-slide deck. Their “UX design process.” Eight phases. Twelve deliverables. Three validation gates. Stakeholder touchpoints color-coded by department.

“This is what we follow internally. We want to make sure your process aligns with ours.”

I asked: “What’s broken in your product right now?”

“Oh, activation is stuck at 23%. Users don’t understand our workspace setup.”

“How long have you known this?”

“About six months. We’re in the research phase now. Journey mapping.”

I ended the call. Saved us both time.

If your ux design process diagram has you journey mapping for six months while your activation rate bleeds, you don’t have a process. You have a way to avoid shipping fixes.

The Two Types of UX Design Diagrams

Every ux design diagram I’ve been shown falls into two categories:

1. Decorative
Looks impressive in pitch decks. Describes nothing useful. Usually includes words like “empathize,” “synthesize,” “ideate.” Always has arrows pointing in multiple directions to suggest this is complex, strategic work.

Gets printed on foam core for the office. Nobody follows it.

2. Accurate but useless
So detailed nobody remembers it after the meeting ends. Swim lanes showing when research talks to design talks to dev talks to product. Seven feedback loops. Three validation gates. Zero connection to how work actually happens when someone says “can you just make the button bigger?”

Not “conduct user research” → “Why are 68% of users bouncing at this exact screen?”

Not “iterate based on feedback” → “Did that label change make completion rate go up or down?”

Most ux design process diagram templates you’ll find online fall into category 1. Beautiful. Useless. Made for selling services, not fixing products.

Why I Stopped Making Process Diagrams

Early in my career, I made these diagrams. Thought they made me look professional. More strategic than “I just fix what’s broken.”

Client: “So what’s your process?”
Me: [Shows diagram with swim lanes and Double Diamond framework]
Client: “Great. When can you start?”

I’d start. The diagram would go in a folder. Never looked at again.

Because the actual work was: “Your signup form confuses people” → “Let’s change this label from ‘workspace’ to ‘team name’” → “Did it work?” → “Yes, completion went from 28% to 43%” → “Ship it.”

The moment I stopped believing in process diagrams: B2B SaaS client, roughly $8M ARR, decent product, terrible onboarding. They had an 8-phase ux design process diagram. Commissioned by a consultant. Documented beautifully.

I was hired to “follow the process” and fix their onboarding.

Week 1: Phase 1 – Stakeholder interviews (scheduled 12 people across 3 departments)
Week 2: Phase 2 – User research synthesis (create empathy maps, identify pain points)
Week 3: Phase 3 – Journey mapping workshop (full-day session with product team)

Tuesday of Week 3, CEO pulls me aside: “We’re demoing to enterprise prospects Friday. The signup flow is embarrassing. Can you just fix it?”

I looked at where users were dropping off. 61% bounced at “Create workspace or join existing.”

Watched 5 user recordings. They all clicked “Join existing” and typed their company name. Got an error. Tried again. Left.

Changed “workspace” to “team name.” Added one line: “This is for you and your direct collaborators.”

Took 4 hours. Shipped Thursday night.

Activation: 28% → 44% by Monday.

The 8-phase diagram? Still sitting in Notion. We were supposed to be on Phase 3 of 8. Never got past Week 3 because the actual problem got fixed and nobody cared about the remaining phases.

That’s when I realized: no ux design process diagram survives contact with “we ship Friday.”

This is the reality of most UX work. The diagram says one thing. The deadline says another. The deadline wins.

The diagram doesn’t account for reality. So you ignore the diagram. Then feel guilty about “not having a proper process.” Then stop making diagrams.

Around year 3, I stopped showing process diagrams entirely. Started showing before/after metrics instead.

Turns out clients care more about “activation went from 31% to 54% in 4 weeks” than “we followed the Double Diamond framework with fidelity.”

Who knew.

This is also why I only work certain ways now. No committees. No 17 stakeholders. No design by consensus. The work needs to move faster than the diagram allows.

What UX Design Diagrams Actually Try to Describe

Here’s what every ux design diagram is trying to communicate, stripped of the methodology theater:

The only thing that matters:
User sees [thing] → User understands what it does → User decides to interact → User succeeds → User gets value

Or:
User sees [thing] → User confused → User leaves

Your entire job: Make the first path happen. Prevent the second.

Every UX decision, regardless of how many phases your diagram shows, breaks down to four questions:

1. What does the user see? (information architecture, labels, visual hierarchy)
2. What do they think it does? (copy, affordances, mental models)
3. What happens when they interact? (feedback, error handling, next steps)
4. Did it work? (measure, learn, adjust)

That’s it. Four questions. Not 47 steps. Not 12 phases. Not a Double Diamond, Triple Loop, or any other shape that makes design look more scientific than it is.

This is closer to what product design actually looks like in practice. Questions, not phases.

The Four Questions in Practice: A Real Example

Fintech product. Users need to see transaction history. Support getting 52 tickets per month asking “Where’s my transaction history?”

The feature existed. It was buried.

Question 1: What does the user see?

Opened their product. Main navigation had: Dashboard, Accounts, Reports, Settings.

Transaction history was under Reports → Financial Reports → Transaction Log.

Three clicks. Two of them into menus users don’t naturally explore.

Question 2: What do they think it does?

Asked 6 users where they’d look for transaction history.

• 4 said “Accounts” (because transactions = account activity)
• 2 said “Dashboard” (because it’s financial data they check daily)
• 0 said “Reports” (because nobody thinks “transaction history” when they see “reports”)

The label was for accountants. Users aren’t accountants.

This is the same problem that shows up in settings pages everywhere. Labels that make sense internally, mean nothing to users.

Question 3: What happens when they interact?

Users who found it (14% of active users) could use it fine. Clean table, good filters, export worked.

The feature wasn’t broken. The path to the feature was broken.

Question 4: Did it work?

Moved transaction history to Accounts → Transaction History. One click from main nav.

Support tickets: 52/month → 7/month (87% reduction) in 3 weeks.

Feature usage: 14% of active users → 68% of active users.

Same feature. Different label. Different location. Massive difference in outcomes.

No journey mapping. No stakeholder workshops. No 8-phase process. Just four questions answered honestly.

This is what SaaS product design looks like when you strip away the process theater. Find what’s broken. Fix it. Measure it.

The UX Design Diagram That Actually Works

If someone forces you to make a diagram (they will), here’s what belongs in it:

Not this:

• Empathy phase
• Ideation workshops
• Stakeholder buy-in sessions
• Design system governance committee
• Innovation sprints

This:

• What problem kills users? (find it in analytics, support tickets, user recordings)
• Why does it kill them? (understand the actual blocker, not what you think it is)
• What’s the smallest fix? (ship it this week, not next quarter)
• Did fewer users die? (measure completion rate, not “engagement”)

Morbid? Sure. But at least it’s honest about what you’re actually doing.

I worked with a SaaS product where 37% of support tickets were people asking “How do I see my transaction history?”

The feature existed. It was in the navigation. Under “Reports.” Third item in a submenu.

A ux design process diagram would show: Research phase → User interviews → Journey mapping → Wireframes → Prototype → Test → Iterate.

What actually happened: “Transaction history is under ‘Reports’” → “That’s stupid, users don’t think transaction history = reports” → “Move it to ‘Accounts’” → “Done” → Support tickets dropped 71% in two weeks.

No phases. No diamond. Just: found problem, understood problem, fixed problem, measured problem.

Same approach works whether you’re fixing a pricing page or redesigning onboarding. The questions stay the same.

Why Complex UX Design Diagrams Exist (The Real Reason)

They exist to justify budgets and timelines to people who don’t understand design.

I was subcontracted once by an agency. They’d pitched a “comprehensive UX transformation” to an enterprise client. Showed a 12-phase ux design process diagram. Quoted $120K for “discovery and strategy.”

I did the actual work. Took 3 weeks.

Here’s what the 12 phases translated to in reality:

Total time promised to client: 16 weeks
Total time I actually spent: 3 weeks
Client paid: $120K
I was paid: $18K

The diagram wasn’t describing the work. It was justifying the price.

I’m not saying the work wasn’t valuable. It was. The client’s activation rate went from 24% to 51% in 6 weeks after launch.

A 12-phase ux design diagram doesn’t make you a better designer. It makes you look like a designer who needs 12 phases to do what good designers do in 3.

The diagram is for people who hire designers but don’t understand design. It translates “I figure out what’s broken and fix it” into language that sounds strategic enough to get budget approval.

Which is fine. Just don’t confuse the translation with the work.

What Actually Happens: A Real UX Design Process Diagram

Here’s the ux design process diagram I’d show if I were being honest:

Week 1: Client says activation is low
Week 1, Day 2: Look at analytics, find the step where 60% of users drop off
Week 1, Day 3: Watch 5 user recordings, see what’s confusing them
Week 1, Day 4: “Oh, they think ‘workspace’ means their company, not a project space”
Week 1, Day 5: Change label to “team name,” add one line of helper text
Week 2: Ship it, measure it
Week 3: Activation: 28% → 43%. Done.

No swim lanes. No feedback loops. Just: found it, fixed it, shipped it, measured it.

The actual diagram would look like a checklist:

• [ ] What’s broken? (data)
• [ ] Why is it broken? (observation)
• [ ] What’s the fix? (solution)
• [ ] Did it work? (measurement)

That’s the only ux design diagram that matters.

Everything else is methodology theater to make “I fix broken interfaces” sound like “I execute strategic design operations.”

This is how most UX problems actually get solved. Not through phases. Through fast iteration on obvious problems.

When Process Diagrams Actually Help (The Only Time)

There’s exactly one situation where a ux design process diagram is useful: explaining to non-designers why fixing their broken interface isn’t instantaneous.

Founder: “Can you just make the signup flow better? Should take like a day, right?”

That’s when you need the diagram. Not because you’ll follow it. Because they think design is “make it pretty” and you need to explain why understanding the problem takes longer than they think.

But even then, you’re not following the diagram. You’re using it as a translation tool.

“Understanding why 60% drop off” becomes “user research phase.”
“Watching people fail” becomes “usability testing.”
“Designing the fix” becomes “iterative design.”
“Checking if it worked” becomes “post-launch validation.”

The diagram translates “I need time to think” into language that gets you budget approval.

Which is fine. Just don’t confuse the translation with the work.

This is the same reason people ask for design RFPs. They’re translating uncertainty into process.

The Bottom Line

Next time someone asks for your “UX design process diagram,” try this:

“I figure out what’s broken, why it’s broken, fix it, then check if it worked. That’s the process.”

If they need a prettier answer, make it four boxes:

Find problem → Understand problem → Fix problem → Measure problem

Add some arrows if it makes them feel better. Call it “agile” or “lean” or whatever methodology they’ve heard of.

Then go do the actual work, which looks nothing like the diagram.

Last time someone asked me for a process deck, I sent them a screenshot of three Jira cards: “Find what’s broken,” “Fix it,” “Measure it.”

They hired someone else. Someone who had a 40-slide process presentation. Beautiful swim lanes. Color-coded phases. Stakeholder touchpoints.

Six months later they called back. Their activation rate was still 23%. The other person had followed their diagram perfectly. Attended every workshop. Delivered every phase. Hit every milestone.

Just didn’t fix anything.

Turns out diagrams don’t ship. Fixes do.

Same pattern I’ve seen with design audits. Beautiful documentation. Zero implementation.