By Nick Butler
Tags: Agile
This case study looks at what we learnt running our first five-day Google design sprint — what worked well and where we got it wrong.
It’ll make the most sense if you first read our post on what the Google sprint is and why to run one and our day-by-day how-to sprint guide.
You can also read an updated and expanded version of this post on the official Sprint Stories website.
The sprint is designed to help you tackle big business challenges, especially when time is short, stakes are high and issues are thorny.
Our challenge was to create a new home page for the Boost website. Our home page is a valuable piece of real estate and we want it to make prospective customers feel at home. Unfortunately, because our clients come first, our own projects and properties don’t always get the love they deserve. The sprint let us tackle the home page when we had resource available, taking maximum advantage of a short window of opportunity.
Two of the defining features of the design sprint are its length and its density. It’s a tightly structured five day process.
Because you’re always moving from one activity to another the five days go by fast. You’re not always sure why you’re doing things, but the reasons became clear later. This means that everyone on the sprint needs to take a leap of faith and commit to the process, to make it work.
Keeping the five days clear from interruptions was trickier. Gavin said that despite having explained that he was booked up for the five days he was asked more than once if he had any free time. James had to come and go as clients called. The 10.00am starts from Monday to Thursday helped us keep on top of emails and we did manage to keep everyone except James in the room for the full five days.
There was no sign that going device-free caused irreparable harm either, perhaps because we didn’t need to go completely cold-turkey.
For people like me, who need time to mull over ideas, it would have helped to have prepared in advance for the sessions where you have to make substantial contributions such as Ask the Experts, Lightning Presentations or Sketching Solutions.
Some things you don’t want to do ahead of time. For instance we recruited our interview subjects before starting the design sprint. Because we didn’t wait until Monday afternoon, when the Decider picks the target customer, we ended up recruiting the wrong people.
We didn’t take enough risks, especially in our sketches and the resulting prototype. Our sprint should have taken the chance to try high risk and high reward approaches.
We should have brought our CEO in for key sessions, perhaps the Goal-setting, Ask the Experts, Sketching or Deciding sessions. Nathan would have been well-suited to the role of Guest Troublemaker. His perspective, a kind of evidence-based iconoclasm, would have encouraged risk-taking. And of course, it’s vital he’s on board with the final product.
Next time Bonnie runs a sprint she plans to start by jointly coming up with a team charter.
She found the slide deck available on the Sprint book website handy and says she used their checklists as a day-to-day reference during the sprint more than the book itself. On the other hand, Sprint bot, the automated sprint coaching by email, she thought would only be useful if you hadn’t read the book.
Bonnie’s other tips:
Kicking off with the Sprint in 90 seconds video worked well. It’s a super-concise introduction to the sprint and a chance to meet a couple of the guys behind the Sprint book.
Because we were building one page, our Map couldn’t show the full process our customers would follow on our site. Probably a good thing, it ended up being complex enough.
The afternoon Ask the Experts session seemed like a process you’d get better at with practice. As an expert it can feel like a stretch to tell the team all you know about the challenge at hand. And for the team listening it doesn’t always come naturally to act like a bunch of reporters digging for a story.
Additionally, the How Might We approach to taking notes during this session requires some mental gymnastics. Remembering to phrase problems as solutions by writing them in the form “How might we [resolve the problem]” can slow down your note taking. One option we talked about afterwards is to write your notes as you would normally, and convert them into HMWs later.
An opportunity we may have missed was getting one expert to talk through previous efforts at redoing the Boost home page, or website as a whole. We might have found some good ways ahead and avoided some past pitfalls.
At the end of the day we had determined our:
For the Lightning Demos, we didn’t come up with the list of existing inspiring solutions ahead of time. This meant that we had some double ups. Choosing the topics as a team on Monday would avoid this.
It was during the Sketching that I most wished I’d done some homework the night before. If, like me, you don’t have a constant flow of ideas on tap, and you plan to do some prep, consider starting with the first step in sprint’s structured sketching process: gathering key information by taking notes based on the goal, map and HMW questions, checking reference material and reexamining old ideas.
The structured approach to choosing—with the designated Decider locked into the process—worked well, producing quick, focussed choices. Not having people pitch their ideas meant that ideas had to stand on their own, independent of the persuasive abilities of the creator.
We also found that the Heat Map gave us a clear visual indicator of what people were responding to.
To get an idea how to storyboard a single page, Bonnie checked what other people had done on home page sprints on the sprint case studies site.
After our Rumble vs. All in One discussion, we decided to go All in One, merging the two designs that had attracted the most dots.
The problem was, this introduced a large number of questions about how to integrate the two. Without the structured decision-making of the other stages we resorted to design by committee, with all its downsides. Discussions dragged on and got heated, new ideas were introduced and past decisions were revisited.
Having a team charter would have helped here. We could also have dipped into the toolkit of decision-making processes and pick the ones best-suited to the decisions at hand. And we could have broken down the task into chunks and given the team specific roles.
Design by committee reared its ugly head during prototyping too. If she had her time over, Bonnie would have set up a separate work space for our Makers (designers Brayden and Emma).
We also didn’t write or design the opening scene that would bring our interview subjects to our home page (most likely a Google search results screen). Doing so would have helped us set the scene for our interview subjects.
This was where we diverged most from the Sprint book.
The interview subjects we’d recruited weren’t well-suited to testing whether we’d achieve our long-term goal of exciting people to work with us. They were current or former clients so came to the testing already excited by Boost. When we realised this we went to Plan B. We set up a second batch of interviews which we ran simultaneously, using a different script.
This meant we couldn’t follow the Watch Together, Learn Together approach recommended in the book. Because we didn’t all see all the tests, and because the two batches weren’t exactly comparable, we found we didn’t have a shared view of the lessons of the testing.
This, and completing the testing in two locations, meant we ended the sprint apart rather than together.
We took a few days to find time in diaries to get together and decide on outcomes of testing. As mentioned, these weren’t clear cut. The lack of clarity wasn’t helped by the fact that, unlike the rest of the book, the section on how to extract lessons from testing didn’t clearly spell out the process. It does give a few examples which we tried, not entirely successfully, to apply to our sprint.
We showed the prototype to Nathan, our CEO. He didn’t feel we’d nailed the “why”, the emotional connection.
Based on our findings from the testing we created version two of the prototype. Nathan felt we’d strayed still further from conveying the “why”.
Gavin reckons we should have burned the prototype, that we should have taken it and the lessons of the testing and used these to create a post-sprint home page. Otherwise you risk becoming wedded to the specifics of the prototype and not the key ideas it embodies.
That’s what we’re doing now, but are back to trying to fit this in around our client work.
To avoid losing momentum after your sprint, you might want to book the time to complete the next steps, whatever they might turn out to be, into your calendars.
We recommend you stick as closely as possible to the book for your first design sprint. The activities have been tried and tested and the book spells out very clearly and simply what to do. It includes many well-told case studies that help you understand how the sprint works in practice, along with why the activities are set up as they are.
You can then tweak your approach based on your own experiences and requirements.
What we found was that the sprint is an excellent way of being safe to fail. You haven’t spent months developing a final product, only to find it misses the mark. The design sprint is a chance to take chances.
If you’ve any questions about running a sprint that these posts haven’t answered, give Sean a call on +64 4 939 0062 or email [email protected].
What the Google sprint is and why to run one
The Sprint book website — provides tools including checklists, a sprint supplies shopping list, and an introductory slide deck
Google’s sprint resources — includes different activity options
Sprint resources on the GV website
Agile kick-off meeting toolkit — an alternative set of project discovery tools
Sprint stories and case studies
Jake Knapp’s Facilitator’s Handbook: 24 Design Sprint Tips
Magnifying glass icon image created by D3images – Freepik.com
