There’s a scene in the 1995 movie Apollo 13 that depicts the dramatic steps taken by NASA’s mission control team to save the lives of the Apollo astronauts after carbon dioxide had built up to dangerous levels on the Lunar Module, threatening to poison the three men on board.
(A quick explainer: The Apollo 13 astronauts flew up into space in a command module, but when an explosion on the CM damaged their oxygen tanks, they aborted the mission to the moon and climbed into the lunar module—the small craft that would have landed them on the moon—in order to get back home. The lunar module has been described as a sort-of “life raft” the astronauts used to return to earth.)
The problem for the Apollo 13 astronauts was the filters they had brought with them from the command module (to filter out the carbon dioxide, obviously) were square; the filters for the lunar module, however, needed to be round. And so, in that scene from Apollo 13, Gene Kranz, NASA’s Flight Director on the mission who was played by Ed Harris in the movie, instructs his mission control team to “invent a way to fit a square peg into a round hole.”
What happened next in the movie (and in real life) is the mission control team worked around the clock until it had figured out a solution using only the tools that the astronauts had on board with them on the lunar module. It was not only a remarkable display of engineering brilliance by the men, but also a remarkable display of teamwork and problem solving as well.
We mention all of this as a way of helping to explain the purpose of a Design Sprint, which you may know about (or at least heard about), but which you and your team may have yet to undertake. Now, the Apollo 13 story is admittedly a dramatic example—we’re going to assume that no one will die if your Design Sprint ends in failure—but it does put into (extreme) focus what a Design Sprint is meant to accomplish: It’s a five-day process in which you and your team identify a problem or challenge, build a prototype, and then test it with users.
Gloria Lo, a UX designer at Rokt, points out one of the benefits of a Design Sprint is that it “cuts out all inefficiencies and ineffective discussions” at your design firm.
“No more dreadful back-to-back meetings that take up your entire day leaving you with little time to get anything done,” she explains. “A [five-day] sprint forces you and your team to focus and work towards something realistic by the end of the week.”
But before you get started, you might want to check out how to organize your “war room” for the sprint and make a list of the supplies you should stock up on for the sprint.
When Jake Knapp came up with the idea for the Design Sprint while he was working at Google Ventures (GV), he was essentially looking for a more effective method of carrying out group brainstorming sessions. (Since Knapp devised the strategy while at GV, it’s often referred to as a Google Design Sprint).
Knapp recalled how he’d organized numerous brainstorming workshops at Google back in 2008 (he left GV a couple of years ago), but when he went back and looked at what came of those workshops, he found that the “results were depressing.”
“Not a single new idea generated in the brainstorms had been built or launched,” Knapp noted, “The best ideas—the solutions that teams actually executed—came from individual work.”
While disappointed, Knapp remained undeterred in his belief that teamwork was important to producing results in any industry. And so, he came up with the Design Sprint, which was meant to answer the four problems he found with traditional brainstorming workshops: There were too many shallow ideas; certain personalities dominated the conversation; there was too much groupthink; and, worst of all, the brainstorming sessions produced no results.
What perhaps separates the Design Sprint from some of the brainstorming sessions you may have participated in is that Knapp’s method involves everyone on your team, not just designers; your marketing, sales, engineering teams and your CEO are all involved in the process. You will also need to have a designated Decider (usually the CEO, a product manager or other executive) who makes the final call on what solution or solutions to prototype.
Knapp has described the sprint a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more,” which allows you to feel “like fast-forwarding into the future to see your finished product in the market.” One interesting aspect of a sprint is that while the overall goal is to foster teamwork in order to work toward building and testing a viable prototype, Knapp’s method does not diminish the advantages of working as individuals.
In fact, Knapp’s found that allowing individual team members to work on their own actually improves the work that everyone does when they’re working as a team.
When you consider some of the problems Knapp found with his brainstorming workshops—including too many shallow ideas, too much groupthink and certain personalities taking importance over content—they are all issues that occur in a group that doesn’t have a clear method to follow.
“In a group brainstorm, ideas are shouted out loud, rapid fire,” Knapp explained. “The goal is quantity, with the assumption that there will be diamonds among the coal. But details matter, and good ideas require time for deep thought.”
With a Design Sprint—which begins on Monday and concludes on Friday—time is given to working through a problem on your own, eliminating the “loud, rapid fire” process of generating ideas that can plague the group brainstorming session. On Monday, you will join as a group and map a target of what you’re trying to accomplish, while on Tuesday each individual will spend an hour or so sketching out solutions.
“In the end, there are fewer solutions than in a group brainstorm, but each one is opinionated, unique, and highly detailed,” according to Knapp.
On Wednesday, the best solution will be chosen; but again, here’s where a Design Sprint corrects the inefficiencies of a group brainstorming session. Each person in the group will review the sketches and then there will be a “structured critique” in which everyone weighs in on what they liked and didn’t like. (It should be noted that these sketches are supposed to be anonymous, where you don’t actually identify who designed the sketch.)
However, after the group completes its critique of the sketches, the Decider will ultimately be responsible for choosing which solutions to move forward with and prototype. This could result in only one prototype being built, or multiple prototypes, depending on if the solutions fit together or need to be broken up into more than one prototype.
On Thursday, your team will build the prototype.
“Ideally the quality should be good enough so that it appears real to users but not too much that you spend forever perfecting it,” Rokt’s Gloria Lo notes. “For example, creating mockups using Sketch or Keynote and importing that into a prototyping tool like [InVision] is an easy way to get software prototypes out quickly.”
Friday is the final day of your sprint and the day when you will test your prototype out on users to solicit feedback. A general rule of thumb is to aim for about five different users for the testing.
When considering what your team will walk away with after the five days spent working together, “probably the most valuable benefit of design sprints is that they introduce stakeholders to the importance of validating ideas with real users,” according to Paul Boag, author of User Experience Revolution. Lo seems to agree, asserting that the “user is king” in the sprint process, and recommends that the five-day project begin by drawing up an empathy map “to better understand your users and prioritise their needs.”
One important thing to keep in mind when you’re doing a Design Sprint for the first time: You should trust the process laid out by Knapp and GV, rather than trying to modify it for any reason – such as shortening the number of days of your sprint to make it less of a time commitment. (It’s possible, however, that you might want to modify it once you’ve done enough sprints to get the hang of it.)
Mogens Overbeck, a UX designer, posted an entertaining recap last year of what he learned by “taking part in a ‘bad’ sprint,” warning that you should “NOT, under any circumstances start revising the foundation of the sprint, which was defined at the beginning of the process.”
“In our case, assumptions, questions, goals and problems were literally revised on the last day of the sprint, rendering much of the process pointless, since everything in the sprint is built on top of this foundation,” Overbeck adds. “Mess with the foundation—and the whole house comes crashing down.”
There’s no doubt that a Design Sprint can seem like a daunting task; setting aside a full work week is admittedly not easy on anyone’s schedule. But the benefits far outweigh any inconveniences it may pose for your team, providing structure to a process that can sometimes be too chaotic and yield too few viable solutions to a problem you’re looking to solve.
At the end of the week, your sprint should not only improve how your team works through a problem, but provide the team with a much more effective way to solve it.
