3 Thoughts From Running a Google Sprint
If you’re unfamiliar with a Google Sprint, it’s a framework to take something from an abstract idea to a testable (physical or digital) prototype in just five days. A considerably short amount of time in the world of product (or UX) design.
Starting with a broad problem (or blue-sky business challenge) you and your team (of around five to seven designers / non-designers) break down an issue (i.e. how do we acquire more customer data) into one main goal (i.e. how do we get our HTML source code on more websites).
The first day is about narrowing the project scope: what’s the one challenge the room’s spending the week trying to solve? After a unanimous agreement from the group-- the Sprint begins with a very clear goal in mind.
Fast forwarding a bit, here’s what’s important to note: at the end of the week, it’s not the visual design or prototype you’re testing. It’s the viability of your answer. How well does the solution you and the team chose to mockup (and prototype) address the initial challenge the room agreed to tackle on day one?
Your solution could be a raging success with glowing user feedback! In that case, pack your bags because you’re an absolute hero. And shoot me an email, because I have a few projects I’d like to give you.
The reality is, there’s probably a lot of rework and thinking needing to go back into your solution. It’s not that you failed-- it simply means that particular solution isn’t the right one to continue building. But there’s still so much value in that realisation.
With only a week’s work (and a few pieces of paper hanging from the walls) that’s a valuable piece of insight to discover with an extremely low level of risk. Think: better a ‘failed’ Sprint than a failed product release to your 12,000+ monthly users.
And that’s exactly where I think this system really shines. After only five days, not only do you and your team have a deep understanding of your initial business challenge, but a really good indication if that problem is even the right one worth tackling. The feedback you get from the last day of testing could reveal that there’s a bigger issue at play. Or, it could reveal that ‘it’s just not something I’d use.’
At the end of the day you’re answering the questions:
How important is this business challenge? And how much more thinking do we need to put into our solution to get something out the door?
That said, here are a few takeaways from my first Google Sprint, and why I would (without a doubt) run another.
1. A common goal (getting the team on the same page)
A Sprint is centered around teamwork.
Having something that’s (hopefully) well thought-out and in working order after a few days takes a big push from everyone. Day one is centered around focusing the group and getting everyone to an equal starting point. The benefit of clearly listing out goals, subgoals, concerns, and potential pitfalls of the project before kicking off is enormous. Everyone feels heard, everyone sees the problem from a different perspective, and everyone shares what they know (or at least what they think they know).
With a majority of decision being made by a democratic voting structure (called dot voting), everyone’s invested in what’s being tested. With all group voting being centered around discussion (rather than dictation), this becomes more than a simple ‘work project’ and something everyone wants to see get built.
2. Leveraging expertise from those close to your organisation
After the room has a clear understanding of what challenge their addressing, there’s a need to pull in outsider information. Luckily, chances are you’re working with (at least a few) smart people.
With a looming deadline, there’s limited time or resource to hold external interviews with your ‘target audience.’ So, introduce yourself to the team because a primary source of information will be your neighbor, a colleague, or anyone within the organisation that has some familiarity with the problem.
Giving everyone a chance to share what they know not only helps the end design, but also eliminates blockers based on assumption (think: if I think that solution isn’t viable because our development team can’t write code for iOS, but a colleague knows that’s incorrect-- that’ll have a longer impact than just our five day Sprint).
3. Designing as you go-- using usability testing sessions as targeted discovery research
There’s a magic around timeboxing (giving yourself only a certain amount of time to complete a task). Aside from only having five days, the Sprint outlines a timetable for each task making sure teams have a fighting chance and make it to the end.
By removing ‘approvals,’ ‘sign-offs,’ and other management roadblocks, the week moves along nicely. It’s always inspiring to see an idea come to fruition; especially if it’s an idea you’ve contributed too. And when that idea is sitting in front of your target user, the insights start pouring in.
Up until completing a Sprint, I always assumed user interviews and contextual inquires where the best way to pull insight during the early stages of design. Now, I’m not saying they’re useless (there’s definitely value in discovery research), but there’s a different type of insight that comes from sitting in front of a prototype with a potential user.
In my opinion, the pitfalls of discovery research comes with relevance-- but when there’s a solution sitting between you and your user, the amount of applicable insight you’re sure to pull is truly valuable.
Unlike discovery research, a prototype starts a conversation around a user’s actual behaviours, not their attitude towards something. This deals exclusively with how they use something, not how they think they’ll use it. And THAT is something you can confidently base your designs in. Having that level of understanding in around a week makes the long days completely worthwhile.