01 Nov What Is a Design Sprint? Solving a Big Website Problem in One Week
Part 8 of UX Foundations for Small Business Websites — a series on the UX principles I use in client work, and this one is about the design sprint.
In the last post, I wrote about design thinking — the ongoing way of working that starts with people and circles through problems, ideas, drafts, and testing.
A design sprint is its focused cousin. Google Ventures created the five-day process. Instead of stretching that way of working across a whole project, a sprint compresses the same logic into a single, scheduled week. The team is small, the question is big, and the deadline is hard. By Friday, real users will have tried a realistic draft of the answer.
Businesses use sprints when a decision is too big to guess at and too tangled to settle by meeting about it for another month.
What a sprint week actually looks like
Every team runs the details a little differently, but the rhythm I work with goes like this:
First, orient everyone on the real problem. The week opens with one shared picture of the challenge, the audience, and what success looks like. The team listens to the experts, then chooses the target. If the team can’t agree on what question the week is answering, nothing after this matters.
Next, everyone sketches solutions — independently. Not a brainstorming free-for-all where the loudest voice wins. Each person works out their own answer on paper, quietly. You end up with several genuinely different approaches. That’s better than one idea with five people’s fingerprints politely on it.
Then, the team decides. The team reviews the sketches properly, then combines or chooses the strongest pieces. The group maps out exactly what they will build for testing. This is where a good facilitator earns their keep. The group makes each decision by name and states the reasons. The team defers nothing to a follow-up meeting that never quite happens.
After that, build just enough to test. The next stretch is heads-down production of a realistic-looking draft. For a website problem, that’s usually a clickable version of the key pages or flow. It has to be convincing enough that a test user behaves naturally. But it also has to be disposable enough that nobody cries if the test kills it. Think stage set, not a house.
Finally, put it in front of real users. The week ends with a handful of people from the actual audience. They attempt the actual tasks while the team watches. Five honest users, behaving naturally, will tell you more about your big idea than five weeks of internal opinion. To close the week, the team reviews what it learned, including the parts that sting. Then it decides what happens next while the evidence is fresh.
Before any of this, somebody writes a short brief. It covers the challenge, the audience, the time and people committed, and the decision the design sprint needs to produce. Skipping the honest look-back afterward means repeating the same friction next time. That look-back covers what worked about how we worked, not just what we built.
Sprint vs. design thinking, in one breath
Design thinking is the mindset I bring to every project, all the time. A sprint is a scheduled event — a pressure-cooker week, with a team, a brief, and a test at the end — that uses that mindset to break one specific logjam. Think of one as how you cook, and the other as a single, very planned cook-off.
When it’s worth it for a small business — and when it isn’t
I’ll give you the honest version, because I’d rather lose a sale than sell you a ceremony.
A sprint earns its keep when: you’re launching something genuinely new (a new location, a new service line, an online store where none existed), several decision-makers disagree and the calendar is burning, or the cost of building the wrong thing is high enough that one testing week is cheap insurance. A festival adding online ticketing, a non-profit rebuilding how volunteers sign up — those are sprint-shaped problems.
It’s overkill when: the problem is small, well understood, or mostly execution. If you already know your contact page needs to be findable and your phone number needs to work on mobile, you don’t need a week and a team. You need a Tuesday and a designer. I’ll tell you that on a discovery call, too.
The point of the sprint was never the sticky notes. It’s that Friday arrives with evidence instead of opinions — and everybody in the room saw the same users hit the same walls, so Monday’s decision makes itself.
Got a big, tangled website decision coming up — a launch, a new service, a rebuild nobody can agree on? Let’s talk about whether a focused sprint fits, or whether it’s a Tuesday-sized problem. Contact me to start the conversation.
Previous in this series: Design Thinking, Explained With a Real Project · Next: What Does a UX Designer Actually Do?
This article is my own take, in my own words, on UX principles I use in client work — informed in part by completing Google’s Foundations of User Experience (UX) Design course on Coursera. It is not affiliated with or endorsed by Google or Coursera.