Menu ▼

Do you need to test at the end of a design sprint?

One of my biggest gripes with collaborative group activities is that people name many of them design sprints. I have nothing against project kick-offs, brainstorming, design jams, and various other UX workshops; I lead or participate in them more often than design sprints, but they have different purposes. When people do a mishmash of activities and call it a design sprint, the most valuable part of the design sprint method is overlooked.

What is that critical part? The whole method was developed to cut through everyone’s assumptions and test them as early as possible. Of course, people want to come together, share insights, and brainstorm solutions, but they will too often skip the hardest, the most awkward, and the most crucial part—testing with the target customers.

Without testing at the end of the sprint, assumptions stay assumptions. With testing, assumptions turn into learning and insights.

It’s been seven years since I read the canonical book, and even though I’ve led design sprints at Google since before the book was published, I wanted to check it again. And there it is, on the front cover and then immediately on the inside of the cover.

A composite of two photos. The one on the left is the book’s
cover, and a part of the subtitle is about testing new ideas.
The photo on the right is a diagram that shows the schedule of
a five-day design sprint, Monday through Friday. Friday has
one main theme associated with it, and that is testing. Under
the word testing and a drawing of two people in a conversation
is the word learn.

(Related: I also wrote about when is the best time to run a design sprint.)

Previous blog post:
Interaction 23

Stay up to date:
Email · RSS feed · LinkedIn · Mastodon

Back to top ▲