We recently ran an internal Google Design Sprint in order to gather feedback on a mobile game concept. In five days, we created a basic narrative with mood boards and playtested four playable prototypes with our target users.
Here’s how we did it…
Are we really doing this?
Picture this…it’s 10am on Monday morning and Sean (CEO and founder of ConnectFive) comes to the leadership team and says:
“Let’s do a design sprint…on Atomic Pig!”
That’s all we needed to hear. In fact, I was already out of my chair getting ready to round up some team members before he had a chance to fully get it out. Typically we would have done a little prep work the week before to make sure the sprint goes as smooth as possible, but we’ve been waiting for the green light to work on this game concept for over a year and I wanted to get started before he changed his mind.
So here we go!
Day 1 – Setting the Stage, Understanding the Problem & Choosing a Target
The whole purpose of day 1 in a design sprint is to form a cohesive team and get everyone on the same page about the challenge we are trying to solve. So first, we took over the big conference room in the office and made sure to book it for the entire week. This allowed us to lock in a location where we could all work together, focus on what we were trying to accomplish and not worry about getting disturbed by anyone else in the office.
Once that was done, we all discussed how each of us could best contribute to this effort and assigned very specific roles to the team members:
Sean – Vision/Decider
Grant – Prototyping
Nick – Story
Justin – PM
Brenton – Production Art
Eui – Research
Mat W. & Matt A. – Sprint Facilitation
For us, this was an important step. Clearly understanding team member roles upfront helped everyone stay focused as the week progressed as well as made it clear who was responsible for specific decisions when questions came up.
After we agreed upon each role, we needed to align around the problem we were going to solve. In this case, we knew our long term goal was to create a great mobile game, but that was a pretty big challenge to take on in a week so we needed to get more specific.
In order to help us focus and get aligned on a more specific challenge to take on, we worked through a few design activities as a team.
First we created a Proto-Persona we named “Sid Casual”. This document outlined what types of games we think he likes to play, hypothesized his motivations for playing and captured some general thoughts on how he might be introduced to new games. Even though this Proto-Persona wasn’t built upon actual research, this helped the team get on the same page of who we thought our typical user might be and created a foundation we could work off of when making user-centered decisions on design and development direction.
Next we made a flow chart of the different phases Sid might experience with our game at a pretty high level. To help facilitate this, we decided to utilize a user experience design tool called a Customer Journey Map. We were pretty familiar with using this tool and it’s techniques when designing with our clients and thought it might work well in this case too.
The Customer Journey we created included how players might become aware of Atomic Pig, what steps might be included when downloading it, the basic game play interactions and finally how the game might be shared with other players. This was a pretty high level journey, but once we had this outlined we discussed and voted on specific areas of opportunities within it and how we might be able to address them. At first it seemed pretty overwhelming, but once we got it all documented and started to talk through areas we thought had the most risk, we were able to quickly figure out what challenge the team wanted to focus on for this first sprint.
Day 1 lesson learned:
Impromptu design sprints can be really exciting and motivational to the team, but having a few days to prep makes the sprint more productive.
Day 2 – Focusing on Solutions
Day 2 was all about group brainstorming and narrowing down potential solutions we wanted to get feedback on.
Since we don’t typically design games, we wanted to start the day by getting some inspiration. In order to do this, we had a few team members facilitate some lighting demos on games that could be in the same game genre as our Atomic Pig game. This was a great exercise for our group since it allowed all of us to quickly get familiar with a lot of different games, capture what we liked/didn’t like and then get some inspiration before diving into generating our own ideas.
Once we finished up with the demos, everyone used the rest of the day to sketch out rough ideas and refine them until we identified aspects of each we thought were the best to move forward with. In order to refine the ideas, we utilized a few excellent activities suggested by the Google Design Sprint checkoff list. For us, these activities were a perfect blend of focused collaboration and individual exploration time.
Reflecting back, day 2 was pretty exhausting. We always work hard, and most days it seems we are moving at the speed of light, but the collaborative activities were like rocket fuel. The amount of creative and critical thinking brain power we used on day 2 was equivalent to a typical week for us. The amazing part was not only did we increase the velocity of producing ideas, we also increased the quality.
Day 2 lesson learned:
Including all team members, not just designers, during the idea exploration and sketching activities can give higher quality solutions to choose from.
Day 3 – Decision Time
Our goal for day 3 was to take all the solutions from the day before and figure out which ones had the best chance of achieving our long term goal of having a fun and successful mobile game. For us that’s easier said than done. We had a ton of excellent ideas and spent the majority of the morning debating (respectfully) which solutions around game play, story and imagery were the strongest and ultimately should move forward.
Since the design sprint advocates having all key team members together, we quickly leveraged Sean (our decider) to make the tough decisions and figure out which concepts to move forward with. He pointed out some commonalities in the solutions that we didn’t originally consider and combined some we wanted to get feedback on. After that, we spent the rest of the day aligning what our deliverables needed to be for testing on Friday and formulating a plan with the participants we’ve recruited.
Day 3 lesson learned:
It’s important to leverage your “decider” as soon as possible in order to narrow down decisions. The sprint goes pretty fast and spending time debating tiny details quickly kills productivity.
Day 4 – Prototyping
Here’s where it all comes together.
At the start of this sprint we knew we were going to need to build at least one prototype of a game concept, but yesterday we decided to move forward with four different game concepts to prototype. Now this might not seem like a big deal if you haven’t developed games before. But for those that have, this seems absolutely impossible.
Fortunately, we anticipated this day coming and had previously spent some time talking about how we could quickly “fake” different game concepts in order to get feedback. We ultimately decided to use a game development platform and Unity was the best option since most of us were familiar with it and knew it had a robust resource center we could utilize.
We grabbed a few editable game demos that fit our concepts and then split into groups to tackle the rest of the work we had to get done. Some of us started working on fleshing out the game narrative and environmental mood boards while others helped define and develop the game mechanics. We had a lot to do, but the small checklists we created for each deliverable helped us prioritize and stay on task.
Day 4 lesson learned:
You don’t have to build something from scratch in order to gather feedback on an idea. Think outside the box and utilize whatever you can in order to get feedback as fast as possible.
Day 5 – User Testing
Day 5 is finally here!
We were all excited, and a little nervous, about gathering feedback on everything we have been working on over the last few days. But we were ready to go!
In order to set ourselves up for success, we were planning and prepping all throughout the week. We started recruiting participants on Tuesday and as the design started to solidify, we updated and refined the interview guide every day. We also we ran a few practice interviews internally to make sure the facilitators felt comfortable with the questions and all the materials.
Even though we had a dedicated researcher on our team, it was important to us to have everyone participate in the feedback sessions. This was a great opportunity for some to learn new skills as well as hear firsthand what concepts resonated with our participants.
As the day progressed, it started to become pretty clear which concepts people enjoyed the most. Other ideas fell short and some totally flopped, but this is why you test!
Day 5 lesson learned:
Getting feedback before spending a lot of time developing is the best way to make informed design and development decisions.
Was the Sprint a success?
Yes. Absolutely. Following the Google Design Sprint process was an amazing way to quickly iterate through a pretty big design challenge and gather actionable insights. We all thought it was a complete success and are planning on doing another one soon.
What would you do differently next time?
Have more prep time to set the stage and narrow the focus of the sprint. We didn’t give the team much warning, there were too many goals at first, and it could have been focused on just one part instead of multiple; art, story, game mechanics, or type of game.
Sprint conducted by:
ConnectFive is a research and design company focused on helping clients deliver experiences that are meaningful for users and effective for business. Along with our hands-on consultation services, we also facilitate design and development workshops for those wanting to learn and utilize lean practices and methodologies.
Resources we used:
Product design manager @Handrailux Sometimes I have ideas...other times I am brilliantly late to the party