—
4
Min
Read
Most client workshops feel productive in the room and change nothing after it.
Two days of sticky notes. A journey map nobody opens again. The same UX problem still sitting in the product a month later.
The issue usually isn't the team. It's that the workshop was built around the process instead of the fix.
Here's how I run workshops with SaaS founders: get to the point, ask the questions that matter, and end with something people can click.
Key Takeaways
A good workshop starts with the problem that's costing users, not with an exercise.
Five sharp questions do more than a full day of activities.
Founders and their users often already know the answer. Your job is to hear it and move.
AI and a React boilerplate turn a hand-drawn wireframe into a working prototype in hours.
Testing the real thing with 2 to 3 users beats debating a picture of it.
The first version is rarely the final one. Building it is how you find the better idea.
1. Start with the problem, not the process
A good UX workshop opens with the one problem that's costing users or revenue right now. Everything else in the session serves that problem.
Most workshops start with an agenda: warm-up, personas, journey map, dot voting. By the time the team reaches the actual problem, the energy is gone.
I flip it. Before we meet, I ask the founder to pick one problem worth fixing this month.
Ask before the session:
Where do users get stuck most?
What do support tickets keep repeating?
Which screen do you avoid showing in demos?
If you had one week, what would you fix first?
A workshop without a problem is a meeting with markers.
2. What questions should you ask in a UX workshop?
Ask questions that show what users actually do and what the founder already suspects. Skip the ones that only produce more opinions.
Founders have lived with their product for years. They've heard every complaint. The answer is usually already in the room. It just hasn't been said out loud.
Ask:
What are users trying to get done on this screen?
What have you already tried, and what happened?
What do your best customers do differently?
If this were fixed tomorrow, what would change in the numbers?
What do you think the answer is?
That last one matters most. Then actually listen.
3. When to skip the process and just build
If the founder and the users already agree on what's broken, skip the personas and journey maps and go straight to building.
Process exists to find the answer. When the answer is already in the room, process only slows you down.
On one project, the onboarding flow hadn't been thought through. Users were dropping off before they ever reached the product. Everyone in the room already knew it.
So we skipped the personas and journey maps. I sketched the layout I was suggesting by hand, super lo-fi. Nothing fancy. Just enough for the whole team to point at it and agree.
That's my take on workshop deliverables: polished mockups slow the room down. People start debating colors and spacing before they agree on the layout. A hand-drawn wireframe keeps the conversation on structure, and it's all you need to start building.
Skip the process when:
Users keep reporting the same issue.
The founder can describe the fix in one sentence.
The data points to one screen.
Being wrong costs one more iteration, not a rebuild.
Process still earns its place when the audience is unclear, the market is new, or stakeholders disagree. Respect the process. Just don't hide behind it.
4. Iterate fast with AI and a React boilerplate
Turn workshop decisions into a working prototype the same day. With AI and a solid boilerplate, that takes hours, not days.
I start from a React starter that already has the layout shell, components and design tokens in place. AI scaffolds the screens, the mock data and the states people forget: empty, loading, error.
My stack is Next.js, Tailwind and shadcn/ui. The hand-drawn wireframe from the workshop goes straight into Claude Code and comes out as a working screen.
What AI doesn't do is decide. Hierarchy, copy, what to cut. That's where the design work is now.
Use:
A React starter with your design tokens already in it
AI to scaffold screens and realistic mock data
Real copy, not lorem ipsum
One clear flow, not the whole app
A clickable prototype gets better feedback than a Figma frame. People react to how it behaves.
AI makes it fast. Decisions make it good.
5. Test it with real users before you polish it
Put the prototype in front of 2 to 3 real users within a week. You'll learn more from watching them click than from another internal review.
Keep it light. A 20-minute call, one task, screen share on. Ask the founder to join and stay quiet.
Watch for:
Where they hesitate
What they click first
What they ignore
Fix what you saw. Test again.
6. Let the first idea lead you to a better one
The idea from the workshop is a starting point. Once it's built and tested, the better solution usually shows up on its own.
Ideas are hard to judge on a whiteboard. They're easy to judge once you can click them.
On that onboarding project, the original idea was a TurboTax-style onboarding: a guided, step-by-step flow that asked everything up front.
Once we saw it working, the better idea was obvious. Remove as many steps as possible. Onboarding shrank to a small checkbox on the create-account screen. The remaining questions moved later, asked only when a user chose to start a different flow.
We only got there because the first version existed.
After the first test, ask:
What did users do that we didn't expect?
What did they ignore?
Is there a simpler version hiding in here?
You don't find the better idea by talking about it. You find it by building the first one.
Traditional workshop vs. a fast-fix workshop
Traditional workshop | Fast-fix workshop | |
|---|---|---|
Starts with | Agenda and exercises | One problem costing users |
Output | Sticky notes, personas, journey map | Working React prototype |
Time to a working prototype | Weeks | Hours |
What the team reacts to | Descriptions and pictures | A product they can click |
Role of the founder | Participant | Decision-maker in the room |
Cost of being wrong | Weeks of rework | One more iteration |
Final thoughts
Judge a workshop by one thing: did something in the product get better the week after?
The faster you get to a real version, the faster you get to the good one.
On that onboarding project, we went from workshop to working prototype in hours. Not days.
What founders get:
A testable fix in hours, not weeks
Fewer support tickets on the problem screen
Better activation on the flow you fixed
Engineers building from a tested prototype instead of a guess
Test the real thing before you build it. Bring me the UX problem that keeps coming up. We'll run a focused session, and you'll have a working prototype to put in front of users within days. Book a Call With Isaac
