Tuesday, October 27, 2015

The Google Design Sprint: What to Expect and How to Prepare

Aja Shamblee
Design

DesignSprintImage

The Google Design Sprint is praised as being the perfect ideation method to solve important pressing design questions quickly and efficiently. Jake Knapp makes an excellent point about the beauty of constraints and how confining the sprint to 5 days allows for the most creative and simple ideas to shine. Typically, these design sprints have been aimed at creating solutions for start-ups, but we decided to borrow the format and use it as a bootcamp alongside our clients.

Under the guidance of two very talented UX Leads, I was lucky enough to join Rightpoint’s first Design Sprint. In this scenario, one of our long-term clients had a valid product concept but they were concerned that it wouldn’t engage or satisfy their end users. We thought a design sprint would get them closer to their goal faster than a traditional design project. Using Knapp’s approach to the five days, here’s my own personal experience and how you can prepare for each day accordingly.

Day 1: Unpack

“Dig into the problem through research, competitive review, and strategy exercises”

01_Day1

I like to think of this day as the cram session before a big test. You’ll need to have the utmost focus today, so bring lots of coffee and sugar. Our team reviewed the details of the industry, identified the problem and determined what kind of product was needed. We did this by running through a series of focused exercises to probe our client for questions. We walked through their work-flow, acknowledged personas and listed out all possible roadblocks and feedback from their users that weren’t adopting the system. What type of technical skill set did each group have? How were things being communicated and how might they be improved?

If you’re team is doing this Sprint with a client, understand that this is the day where those clients will need to feel heard and understood. Think of this as the ultimate opportunity to build a strong relationship. Your team will want to invite client members like a CEO, Product Manager, a User Expert and typically a Designer or an Engineer to each day of the sprint. My advice would be to clear everyone’s schedule entirely. If there are other distractions on the sidelines or with another project, it’s best to reschedule this sprint for another time. As our lead mentioned prior to getting started, the only reason your computer should be open is to take notes.

Day 2: Sketch

“Rapidly develop as many solutions as possible.”

  itcrowd

You know that feeling when you have a million ideas and you just don’t know where to start and none of them connect to one another? This is the day for that! One of my favorite exercises gives you 30 seconds to sketch out an idea, break for 10 seconds and then do it again 8 separate times. Truthfully, I’ve never felt such intense anxiety. But I’ll admit, it’s oddly thrilling.

These exercises basically purge you of every idea in your brain, good or bad. Everyone gets involved including clients. The best part is that each person can choose to focus on whatever they want so that the biggest ideas run freely. An alternative method is to narrow the ideas down to a particular topic as a team, like “Checkout” or “Notifications” and have everyone sketch solutions based on those concepts. The first time they do it, they’ll likely feel like they just went through a tornado. But trust me, it gets easier.

Once the speed rounds are done, each person will choose one of the sketches they’d like to expand on and map out a quick wire of that interaction to share with the group. These can range from UI layouts, to work flows, or even storyboards of users going about their lives using the product. Anything goes. Everyone will throw those up on the wall, walk through each one, and mark the parts they think are interesting (we used green stickers because everyone loves stickers). A lot of great conversation and collaboration comes from sharing these ideas and it often inspires even more ideas.

Because everyone participated, sketching gave our team an opportunity to know exactly where our clients head was at and the type of solutions they expected us to address. It essentially took the guessing game out of the equation and we were able to hone in on solutions more collaboratively. What’s left was a heat map of the best ideas that we could refer back to later on Day 3. The entire team repeated this process a number of times until all important aspects of the product concerns were addressed.

If for whatever reason members begin to run dry on concepts, it’s perfectly okay to write down a problem instead of a solution. Getting the team talking is what matters here. And no need to worry about being nervous. The whole thing is so fast-paced that it brings out creativity in the most introverted or extroverted of people. Trust the process and trust your ideas.

Day 3: Decide

“Choose the best ideas and hammer out a user story.”

03_Day3

Shockingly, this was one of the more challenging days. Today your team will be facilitating exercises that will start chipping away at the long list of ideas to find the ones that are necessary for the resulting prototype. Leave the bulk of the decision to the clients, but guide them to make reasonable choices. Ultimately the goal is to create a prototype of a minimal viable product that can be tested against users and execution time needs to be considered. For that reason, prepare for a brutal purge of great ideas that aren’t crucial right now. Our own team initially had a really hard time letting go of some of our ideas. It can be difficult to raise your babies up, only to send them off in their infancy and wonder what could have been. Depending on the size of your group, this may take some time and will require a bit of therapy to get there.

Another big challenge here is coming up with a user story for the prototype and then sticking to just that. Ask the team, “what is the most important job this product needs to do”? As designers, we naturally want to throw in all the shiny ideas that make the design “pop” and embellish on its usefulness in multiple scenarios. That kind of thinking has been drilled into us our entire careers. But time constraints should force the team to simplify to one story. The team should walk away with a pretty solid storyboard that reflects the users journey through the product and showcases its best and most important features and benefits. The rest is fluff for another day.

Even though some hearts will be broken from losing favorite ideas, remember that it can always come afterwards as an enhancement or a potential Phase Two. Trust and stick with the simplified version because it generally results in a better user experience anyway.

Day 4: Prototype

“Build something quick and dirty that can be shown to users.”

04_Day4

Emphasis here on “quick and dirty”. This was the one day where I was begging for more time because suddenly things got busy. As a designer, building a rough draft is a mental discipline where you have to train your mind NOT to be a perfectionist. It can be agonizing, especially if the team didn’t narrow down their ideas well enough the day before. The success of Day 4 is entirely dependent on the success of Day 3.

Luckily, we had early conversations with our client about how we would build the prototype (in this case, we used Axure) so I highly recommend doing the same. In addition to that, get the team to set realistic expectations about how rough or polished the prototype will be for user testing. Our client would have loved to see some new branding incorporated into the build but this was far from realistic given the timeframe. Luckily they were familiar with wireframes, but if your client isn’t, it may be wise to have these conversations before the sprint starts.

There are a number of solid prototyping tools today that make the process quick and painless. We chatted extensively about using Axure, Invision, Proto.io or even Keynote. Allow members who will be building the prototype to choose the one they’re most comfortable with because speed is key here. Even if you’re not building the prototype, team members can help out by sketching wires, flows or writing interview questions. Our client provided real world content and copy for our prototype while we did most of the building and design. With that in mind, I think it was especially helpful to have a UX and UI designer on the team. Not only to help out with prototyping but to also ensure strong usability throughout the product.

I also recommend multiple checkpoint breaks to make sure everyone has a chance to share and verify things are correct. This will keep the team focused and give everyone a chance to help out groups or sections that are falling behind. Remember, today’s strength relies on the decisions from Day 3, so plan accordingly and keep it simple. You’ll thank yourself later.

Day 5: Test

“Show the prototype to real humans (in other words, people outside your company) and learn what works and what doesn’t work.”

  sweating

Sit back and know that the team has done their best. It’s in the hands of the users now. This will need to be planned and set up well in advance to the sprint but the important thing to do is schedule testing with real clients and users who would benefit from the product. We scheduled the testing a week before the design sprint with four individuals who were known clients to the industry and had been chosen for their varying skill sets. We prepared a series of questions to ask throughout each stage of the workflow as they progressed through the product. Choose a facilitator that’s not connected to the users and have them ask questions and guide the users. Everyone else, including your client, should take notes on the responses from each of the participants.

My UX Lead, Derek Poppink, made a brilliant analogy during this stage that I thought was spot on. He said that user testing is much like going through the five stages of grief. You never know what will happen but you’re likely going to find a combination of seemingly good and bad reactions from users as well as yourself.

Denial

A user will say something and you’ll just blatantly disagree with them. They think something is stupid and instead of accepting a potential oversight, you assume it’s them.

image

Anger

A user says something and now you’re fuming inside. You constructed an award winning idea that was pure genius, only to have them shut it down. It’s not working and they don’t get it. You hate them.

image

Depression

After a few beats you realize that ideas are getting shut down left and right like wildfire. They don’t appreciate any of your hard work and you’re dying inside. You blew it.

image

Bargaining

After awhile you become numb to the pain and start to realize maybe all you have to do is make a few tweaks and everything will be fine. In fact, maybe it won’t be so bad once you make that small adjustment.

image

Acceptance

Okay, so maybe the feedback made sense and you’re realizing that the changes will actually make it stronger. This wasn’t the unicorn of perfect products you thought it was, but now you know how to make a better one.

image

I love this analogy because ultimately no matter what, it’s just a prototype. It was never going to be the end-all product. In fact, this one has to die in order for the real thing to be reborn. At the end of the day, no matter which phase you go through, hopefully your team comes out feeling excited and rejuvenated. It may even make sense to go through multiple sprints in order to iterate on the one before.

Everyone, including your client and their users, will play a critical part in this creation process regardless of whether you’re dealing with a start-up or a Fortune 500 company. I’ve found that clients want to be more involved. If that’s not the case, feel free to pick the process apart and coordinate specific days with clients and some without them. Do what works well for you and your team. The Google Design Sprint was originally formed as an adaptation of several other processes. Evolve it to fit your needs until you’ve created Your Design Sprint.

Loading Next Article