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.
(Related: I also wrote about when is the best time to run a design sprint.)