The 4-Day Design Sprint: A Step-by-Step Guide That Actually Works

When I was at ANZ, we tried doing workshops to get alignment and move fast. We had the post-its, the energy, the walls full of ideas. But the truth is, we weren’t really talking to real users, and most of the time we’d finish the week still debating what to build.

It wasn’t until I started using Design Sprints properly at SEEK that things shifted. We made it work in a way that felt structured but still creative. Tight timelines, clear steps, and actual prototypes in front of users. We were learning more in 4 days than we’d been learning in months before.

Since then, I’ve used this approach across teams and projects, and I keep coming back to it because it just… works.

So here’s how I run a Design Sprint. Step by step. With all the messy human bits included.

Day 1: Understand & Map

This is the foundation. Don’t rush it. If you skip the groundwork, everything else becomes guesswork.

1. Expert Interviews (usually 5–6 rounds)

These are quick-fire sessions with people who know the space—product, tech, design, support, sometimes even sales or compliance.

What I usually do:

• Set up a timer: 10–15 minutes per expert.
• Ask questions like: What’s broken? What do users complain about? What’s working surprisingly well?
• Capture everything as How Might We (HMW) notes. So if someone says “Users don’t know what button to click,” you write: “How might we make the action feel obvious?”

You’ll end up with a wall (or FigJam board) full of problem reframes. It’s noisy, but it’s good noise.

2. Define the Long-Term Goal

Ask the team: If we nailed this, what would success look like 6 or 12 months from now? Write it out in plain language.

For example:

“In 6 months, a new user should be able to publish their first job ad in under 5 minutes.”

It’s not about features. It’s about outcomes.

3. Sprint Questions

Now switch to doubt mode. What do we not know? What’s risky?

Write out 5–10 questions like:

• Will people trust us with their job data?
• Can someone complete onboarding without human support?
• Will managers invite their team to use this?

These will guide your prototype and user testing later.

4. Mapping the Journey

Here’s where it all connects.

You draw a simple flow across a whiteboard (or digital board):

CopyDiscover → Land on Site → Explore → Sign Up → First Use

Then add stickies under each stage—user needs, pain points, uncertainty.

Finally, ask the team: Where’s the biggest risk or opportunity? Circle that. That’s your sprint focus.

This part used to fall flat when I was at ANZ—we just didn’t have the access to users or clarity on their journey. At SEEK, we flipped this. We pulled in insights from past interviews, product usage, and even old support tickets. You don’t need perfect data. Just enough to pick your moment.

Day 2: Sketching Solutions (Individually, Not in a Group Think Tank)

Now that we know what we’re solving, it’s time to get creative. But quietly. This part isn’t about wild brainstorming, it’s about structured thinking.

1. Lightning Demos (30–45 mins)

Each person finds 1–2 examples from other products that solve a similar problem well.

What I’ve found works:

• Don’t just stick to direct competitors.
• Pull ideas from onboarding flows, dashboards, booking experiences—whatever sparks a thought.
• Present them quickly (2 minutes each), while someone sketches the best bits on the board.

2. Four-Part Sketching Process

Now everyone goes into their own headspace. No group chat. Just paper and thinking time.

1. Notes – Spend 10–15 mins reviewing the map, long-term goal, HMWs.
2. Ideas – Jot down rough concepts or small components. Sometimes it’s just a layout idea or a clever microinteraction.
3. Crazy 8s – Fold a sheet into 8 panels. Sketch 8 variations in 8 minutes. No judging. Just fast ideas.
4. Solution Sketch – Pick your strongest direction. Turn it into a 3-panel storyboard, showing what the user sees and does.

All sketches are anonymous. This keeps it fair. I’ve seen quiet team members contribute absolute gold this way—ideas that might’ve been drowned out in a traditional brainstorm.

Day 3: Decide & Storyboard

This is the day things usually start to feel real. You walk in with a messy wall full of sketches and half-formed ideas, and (hopefully) walk out with one solid concept you’re going to prototype. It’s a mix of excitement and “wait… are we actually doing this?”

And if I’m being honest, this day used to stress me out the most. There’s always a bit of tension when you have to pick one idea to move forward with. People get attached. Some ideas are clearly flawed but kinda beautiful. Some are boring but probably work. You’ve got to keep momentum without losing buy-in.

Here’s how I run it now—and it works.

1. Walk the Wall (a.k.a. “The Art Museum”)

Everyone’s solution sketches (from Day 2) go up on the wall. No names, no pitches, no backstory. Just the work.

We give everyone dot stickers and say: “Go look around, quietly. Mark anything interesting—could be a whole sketch or just a clever little moment.”

Honestly, this part feels weird at first. It’s quiet. People sort of wander around squinting at paper. But within 10–15 minutes, you’ve got a visual heatmap of what’s resonating with the group.

2. Speed Critique

Now we go through each sketch—one by one—and talk through the highlights.

• “What stood out?”
• “What do we like?”
• “Anything we’d steal or remix?”

But here’s the rule: nobody defends their own idea. It’s not a pitch meeting. It’s just the group reacting and reflecting. That keeps it objective and helps surface insights that might get missed otherwise.

Sometimes we’ll spot a strong idea hidden in a quiet corner of someone’s sketch. That’s the gold. Those tiny, clever solutions that solve the exact problem we mapped out on Day 1.

3. Straw Poll + Supervote

After the critiques, we do a quick vote. Everyone puts one big dot on the solution they’d back.

Then the Decider—usually someone with product or customer authority—gets the final say. They use a different color dot. Sometimes they go with the majority, sometimes they go rogue. Either way, we move forward. No more circling.

And yeah, people don’t always agree. But the sprint isn’t about consensus. It’s about learning fast. If we get it wrong, we’ll know tomorrow when we put it in front of users.

4. Build the Storyboard

This part’s my favourite—and the hardest to get right.

We take the winning solution and turn it into a 7-panel storyboard. Each panel = one key screen or interaction the user sees. You’re basically laying out what the prototype is going to look like, end to end.

We always go back to the map from Day 1 here. Remember that? The user journey we all agreed on? This is where it really pays off. You can literally walk across the map and say, “OK, panel 1 is them landing on the homepage… panel 2 is clicking through to job details… panel 3 is starting the application…”

We sketch it out rough and fast. Marker pens on a whiteboard. Just enough detail to guide tomorrow’s prototype.

And honestly, the energy in the room shifts around now. You can feel it. Everyone starts to see the thing. Not the idea in theory—but how it actually works. What the user will click. What they’ll see. What we’ll ask them to do.

By the end of the day, you’ve got a plan. And even if it’s not perfect, it’s testable. That’s the goal.

Day 4: Prototype & Test

This is where it gets real. Fast.

1. Build the Prototype

• Use Figma, InVision, or Keynote—whatever lets you fake the product well enough.
• Focus on surface detail. People don’t need a working backend, just believable screens.
• Aim for about 5–7 screens, matching your storyboard.

We usually split into small roles:

• One person builds.
• One writes copy.
• One preps the interview guide.
• One tests the prototype with teammates to catch bugs.

2. Test With Real Users

Ideally 5 users. Even 3 is better than none.

• Show them the prototype and ask open questions like: What do you think this page is for? What would you click?
• Don’t guide them. Let them struggle if they do.
• Observe reactions and take notes in real-time.

This is where everything ties back to your sprint questions from Day 1. Did your prototype answer them? Did it fail? What surprised you?

It’s rare to leave this day without clarity. Sometimes brutal clarity—but that’s the point. Better to find out now than after three sprints and a deployment.

Final Thoughts

Every step in the Design Sprint feeds the next. The map informs the sketches. The sketches shape the storyboard. The storyboard defines the prototype. And the user test either proves or kills the idea.

It’s sharp. Structured. And it forces you to stop guessing.

Back at SEEK, we used this rhythm to validate job ad ideas, onboarding flows, even entire new products. And every time we did it properly—fully committing to the process—we saved ourselves weeks of rework.

It’s not magic. It’s just a better way to get moving when things feel stuck.