The Brave New World of Design Sprints
“When you participate in a sprint, you either win, or you learn.” #
–Cordell Ratzlaff, Google UX
I’ve had the terrific opportunity to organize and facilitate two product design sprints so far this year. These are focused design thinking sessions that bring together cross-functional teams to thoroughly understand a problem or challenge and ideate on potential solutions in a specific, rigorous way, yielding what I call “informed starting points”.
These informed starting points, or hypotheses/assumptions, are design artifacts that are then synthesized and turned into working prototypes for testing and validation with customers.
Design thinking is not new to designers, but it is relatively new in the context of business and product strategy. Based on IDEO’s design thinking methods, Lean principles as well as Agile techniques, design sprints were pioneered at Google Ventures a few years back as a way to help startups validate a product idea in the market quickly and cheaply before investing in development.
Design sprints have gained traction in the UX and digital product design communities, with firms such as thoughtbot adopting the methodology and applying it to their own client work. Quite a few articles on design sprints have been published over the last couple of years, and I’ve just learned of an O’Reilly book on the topic scheduled to be released later this month.
Design sprints in the enterprise: an evolving process #
Having participated in design sprints during my accelerated learning program at Metis last year, I knew it was something I wanted to bring back to my current project, a redesign of an existing benchmark testing and reporting platform for educational institutions.
However, most if not all of my personal experience and research has typically yielded insights from the startup perspective; very little has been published about conducting design sprints in larger corporate environments. More companies responsible for legacy software are starting to utilize the methodology in their development process, but I’ve yet to come across substantial documentation or specific examples of design sprints in larger corporate environments.
The good news is these techniques can be applied to improving existing software just as well as developing something from scratch, so hopefully a larger number of enterprise design sprint facilitators and participants will begin sharing their experiences more broadly.
Jumping in #
The lack of precedents for conducting design sprints in the enterprise ultimately didn’t discourage me from planning and conducting our team’s first sprint earlier this year and, just this past week, our second one. We had to start somewhere, and in each case, the experience and learnings more than made the effort worthwhile. Nevertheless, there were notable differences in scope, activities, and outcomes between the first and the second sprints.
For our first ever sprint, because the concept of a design sprint was completely new to the majority of participants, I spent time providing background and context ahead of the event. In addition to an agenda, I put together and shared a presentation that provided definition, outlined typical roles and activities, and discussed possible outcomes following user testing of what we were to produce.
The background did help provide a basis for the event, though I’m not sure it was enough for everyone to fully understand exactly what they were going to be involved in and expected to do.
In terms of scope, we had only two days with the full team at our disposal, so our process had to somehow be extremely condensed; there would need to be relatively few activities, and making the digital prototype and conducting user testing would have to be done separately, albeit as quickly after the two days as possible.
We decided to dedicate one full day each to both defining the challenge and exploring solutions for two distinct, but interrelated, aspects of our current product. This meant we would work to have “informed starting points” in hand by the end of each day for two separate challenges. Quite ambitious for a first design sprint!
We were able to pull together a truly cross-functional group of 14 that included product stakeholders, engineers, curriculum specialists and consultants, as well as representatives from sales and operations. Although the group was larger than recommended for such an intense and rigorous process, it was necessary in order to introduce as many members of the broader team to this type of work and gain a collective understanding of the benefits.
Our inaugural design sprint activities #
I started us off with an icebreaker sketching activity: I asked participants to draw themselves on 8.5 x 11 sheets of paper using black markers. The catch was that they had to do it in two minutes. I then asked each person to share their drawing with the team and point out one great thing about themselves.
This was a fun way to start off the day with an engaging task that turned into a conversation about the benefits of freehand sketching and of seeing things from different perspectives. Some sketches were quite simple, while others turned out quite elaborate. It was also interesting to see what each team member chose to point out about themselves.
Following the icebreaker exercise, and in lieu of sketching out a user story diagram (Google’s recommendation) since our scope was so broad, we engaged in a brainstorming session around which “jobs-to-be-done” we wanted the sprint to attempt to solve for the specific aspect of the product.
Jobs To Be Done is a framework for determining customer motivations, where the product is thought of as being “hired” to fulfill a specific customer need. It’s definitely an effective way of understanding what drives someone to want to use a product. It was helpful in this instance as well, but in retrospect, we might have been better served by simply delving into current challenges and existing pain points.
A next planned exercise involving a design audit of competitor websites was scrapped due to time constraints, so we went straight to ideation and sketching. (Again, super ambitious!) I provided some food for thought and encouraged the team to adopt a beginner’s mindset to create more possibilities for solutions, a concept known as shoshin in Zen Buddhism.
We started out with mind mapping, an individual brainstorming activity. Mind mapping traditionally involves drawing a center or focal point in your thinking and branching out into connected associations of varying degrees, literally creating a map of your thoughts. It’s a fairly structured brainstorming technique, so I was surprised that Google’s definition was much more open-ended, referring to mind mapping as “writing down everything in your head with no specific formatting”.
I did my best to provide instructions, but in sticking with Google’s vaguer definition, noticed that at least half the participants had a hard time understanding exactly what to do. Many wound up jotting down terms or thoughts in lists, which of course is also acceptable, but not really a mind map per se.
We then jumped into Crazy Eights, a rapid-fire sketching technique where participants are asked to draw 8 ideas (or parts of ideas) in individual panels on a single sheet of paper in just 5 minutes. The idea here is to take advantage of the short bursts of time (and the pressure) to produce as many individual ideas as possible.
I have to admit it was fun to gently push participants to move to the next panel every 40 seconds—the looks of shock and bewilderment from some of the team members were priceless! I kept the exercise flexible, encouraging everyone to sketch or write down separate thoughts or solutions as best as they could, as long as they started fresh when it was time to move to the next panel.
Despite my best attempts at providing direction, and in general, it was still a challenge for much of the team to understand exactly what the exercise entailed and to transition into drawing out actual interface components. In a way, it felt like they were being asked to do too much with too little.
After getting through two rounds of Crazy Eights as best we could, we moved into some storyboarding. Here the team broke out into three groups and shared their individual ideas with each other, working to combine them into a single, evolved sketch of a possible solution on easel pads. Of the three groups, two came up with sketches involving more defined interface components, while the third put ideas down in a looser format. Each team then presented their combined sketches to the group and elaborated on their thinking, and we concluded day 1 with these presentations.
During Day 2, our jobs-to-be-done conversation on our new topic rapidly turned into a much larger discussion, resulting in a complete change of agenda. We spent the majority of our time jointly looking through the current product interface and debating challenges and considerations rather than ideating on new solutions.
It was a little tough to pivot so much in a single day, but proved necessary. Of course, as productive as our conversations were, it became impossible to produce a second artifact for testing purposes at the end of Day 2.
Despite the stumbles, we received a lot of positive feedback on our first design sprint from our team’s participants, and were able to yield several starting points for prototyping. I knew that moving into the design phase I’d need to do a bit more work to synthesize all of the thinking and formulate the UI, but this felt like a good first stab and a starting point on which we could build.
Shortly after the sprint, we shared a full summary of our activities, action steps, and topics for future consideration with the broader business unit. This also helped promote a wider understanding around the benefits of this new way of working. Even while drafting the summary of our first sprint, I already had a pretty good idea of what we wanted to do differently the next time. Among the takeaways:
Narrow the scope and allocate adequate time for understanding and solving the problem. We attempted to do far too much, and it became obvious pretty quickly. Not only was our scope too broad, we thought we could define our challenge and come up with hypotheses to test all in the same day. In retrospect, it turned out to be one of those “what were we thinking?” moments, but that wasn’t as clear until we actually started to move through the activities.
Define the problem properly (and the right one at that). Day 2 turned into a different conversation partly because we went in with vague perceptions—and differing opinions—of what the problem actually was. Naturally, this made it impossible to move into a solutions phase. Part of the problem was incomplete research (see below), which made it difficult to reach consensus.
Provide more opportunities for individual brainstorming and more specific direction around sketching. No matter what designers or books might preach about how easy sketching is, in practice, if someone is not used to doing it, they’re likely not going to get the hang of it right away. We had participants who never got past bulleted lists or sentences, which of course is perfectly acceptable. But in trying to yield an actual design artifact, expecting that someone with no background or training will magically understand what it means to convey ideas and thoughts visually on paper feels naive, presumptuous, or both. Since sketching is rough by nature and does not require artistic ability, we know that aversion to sketching is usually due to perceived vs. actual skill. So if you have a group brand new to design sprints and sketching, including other activities in your agenda around the act of drawing might be useful. You could even do a short workshop on drawing UI components—how to sketch out simple buttons, menus, links and so on.
Make sure you have enough research on hand for the problem you are trying to solve. We had conducted a lot of customer discovery in the months preceding our first design sprint, and thought we had more specific takeaways heading into the sprint than was the case. It turned out all right in the long run as we conducted additional targeted research post-sprint and were still able to yield a prototype, but there were times where we could have benefited from calling up specific findings when certain topics or differences of opinion came into question (particularly during Day 2). In that sense, and despite our existing research, one of our main takeaways from the second day was that we actually needed not only more research, but more specific research.
Our second design sprint: Putting learnings into practice #
Armed with the invaluable takeaways from our first sprint, and having built, tested and validated aspects of our very first prototype, I started to organize our second sprint. This time, our product owner and I made sure we were very specific in defining the problem we were going to explore solving. We’d already gotten lots of customer feedback validating the need for an optimized solution to the particular problem we wanted to tackle and were aware of the challenges and pain points, all of which were backed up by research. We also made sure to allocate one full day to understanding the problem, one full day to exploring solutions, and a third to honing in on a direction as a team.
I also deliberately expanded our range of exercises (or “games”) and spent a lot of time thinking through the flow of activities for this sprint. I wanted to see how I could guide the team through individual and group exercises in a logical way that could naturally lead into tangible ideas for testing, as well as consensus around those ideas.
After our first sprint, I felt the activities defined in Google’s documentation were too limiting in practice for our specific needs. I knew there were other good resources out there for engaging teams in exploring design problems and solutions, both individually and in small groups.
A great example is the terrific book Universal Methods of Design. This book was published just three years ago but contains a wide range of tested methodologies from a variety of fields dating as far back as the 1960s, as well as excellent references and background on each technique. I utilized a fantastic team activity called a Design Charrette, or Parallel Prototyping, that I read about in this book. (I also highly recommend the book’s “companion”, Universal Principles of Design, first published in 2003 and currently in its second edition).
Another fantastic resource was The New York Times Product Discovery Activity Guide, which became available just at the right time for our needs. This excellent playbook is a comprehensive, thoughtful curation of over 70 research and design techniques with clear application steps, practical information, as well as links for further reference.
Developed internally for NYT’s product development teams as a part of a recent product discovery pilot program, the playbook has recently been released to the public so that other organizations may benefit. Al Ming, NYT’s senior director of product architecture and a Lean UX evangelist, was one of the driving forces behind the project. Al recently visited the Kaplan offices for a great discussion with our product teams around the challenges in applying Lean techniques in enterprise environments.
What makes the guide so helpful in my view—apart from the fact that the techniques culled are from some of the brightest minds in the product development industry—is that they are broken out into thematic, color-coded sections depending on the kind of problem in need of a solution. This makes total sense given that different problems require different types of engagement to reach a solution or outcome. This organization made it super easy to flip to the appropriate section of the guide depending on what kind of activity I was looking to engage the team in.
Here’s a great writeup from Al on the playbook. It’s an evolving initiative, and the team is open to feedback on ways they can make it even better which is wonderful!
Design Sprint 2, Day 1 #
Having made sure we dedicated an entire day to understanding the problem, and with a second, slightly smaller cross-functional team of participants from our first sprint plus new members with topical expertise, we kicked off the day with a simple activity called Draw the Problem.
Team members were asked to individually write out a list of items on a sheet of paper helping to explain the problem they were here to solve. After a few minutes, and based on their lists, I asked them to draw a simple picture of the problem on another sheet as they would explain it to a colleague. This uncomplicated way of defining the challenge was a good way to frame our thinking early and in a straightforward way.
After drawing the problem, I guided the team through an exercise called The Five Whys, which helped us get closer to the root cause of our problem by drilling down below the surface. It took a couple of passes to get a final synthesized list of “whys” everyone agreed on, but the clarity achieved by the result was striking and really helped us see the bigger picture.
In the afternoon we moved to our next activity, Post the Path, where individual team members were asked to write out all the steps as they knew them of the current process for the challenge we were tackling, numbering each step. We then posted all of our steps 1, 2, 3 and so forth and analyzed each one, looking for areas of shared understanding as well as areas of confusion or misunderstanding.
For a process as intricate as the one we were looking to improve during this sprint, this was a really good exercise, made even more interesting by the varying levels of expertise around the current process.
We spent the bulk of the afternoon engaging in a SWOT Analysis game around our challenge. The SWOT Analysis, or Matrix, is an established technique used to evaluate the strengths, weaknesses, opportunities and threats involved in a project or in a business venture. We found it perfectly adaptable to the design challenge at hand, and were able to articulate information in each category that made us better understand and agree on our inherent advantages and disadvantages.
Our full first day concluded with a game called Challenge Cards. We broke the group into two teams; the “solution team” silently brainstormed potential features or aspects related to solutions for our problem, while the “challenge team” silently brainstormed potential problems or challenges. Each wrote their scenarios or ideas on index cards, one problem or solution per card.
We started the game by having the challenge team choose a card from the deck and play it on the table, describing a real-life scenario where the issue might come up. The solution team then had to pick a card from their deck that addressed the challenge. If the solution team had an appropriate card on hand, they got a point; if they didn’t, the challenge team got the point and the two teams worked to design a card together that addressed that challenge. Fun!
The entire group seemed to really enjoy this activity, and we kept score (at least in the beginning) which added a competitive angle to the game and kept energy levels high, even at the end of a long day. It also served as a natural segue into the next day’s focus on exploring solutions.
The only glitch we ran into was that we ran out of time and had to continue the game the following day, but the nature of this activity and its focus on solutions allowed us to pick up almost seamlessly.
Design Sprint 2, Day 2 #
After finishing our spirited round of Challenge Cards, it was time to move into the pure ideation phase, starting with another stab at mind maps. This time, I bypassed Google’s vague description and provided more specific direction on how to draw a mind map. I asked participants to think of a focus question or other central theme relating to our problem, draw that in the middle of their sheet, and start drawing simply-labeled extensions outward from the center of the map. The closer a term is to the center, the more important it is. I also put up examples of mind maps on our projector screen having to do with similar topics for reference.
Although some team members still found it difficult, the more specific instructions and examples of ways to create free-flow associations in a non-linear way provided some much-needed definition around mind mapping and yielded better results.
For our rapid sketching exercise, also conducted individually, I decided to try an alternative to Crazy Eights. I felt it was just a bit too rapid the first time and thought it might be too confining given the complexity of our topic.
Instead, I tried out a similar exercise called 6-8-5 Sketching, where participants were asked to come up with 6 to 8 ideas in 5 minutes. There was no set time during which to move to the next sketch; the goal was to work through as many sketches as possible within the 5-minute time limit. Everyone then shared parts or all of their sketches.
Six to 8 ideas in five minutes felt like a more sustainable pace at which to work that kept the rapid-fire nature of the activity intact. We only managed one round, but as this version seemed to go over much better overall, I’ll probably continue to use it over Crazy Eights unless we’re ideating on a very specific design/UI problem.
After lunch, we dove into the Design Charrette (or Parallel Prototyping) game. This exercise is designed to generate solutions regarding specific interface components through a rotating small groups format that inspires continuous cross-pollination and flow of ideas. I was a bit nervous that we might not have enough physical space for the activity to flow well, but it thankfully didn’t turn out to be an issue.
We broke the team up into four groups of 3 around our large rectangular meeting table. We then gave the groups 10 minutes to sketch out a user interface of a proposed solution that also leveraged each participant’s individual brainstorming ideas (from the Mind Mapping and 6-8-5 games). After 10 minutes, two people from each group were asked to move to the next group in a clockwise order, while the third person remained. The two moving members were asked to bring the best ideas forward from their previous group to their next one. We did four rounds, so that each original team re-formed in the end.
The first time I prompted team members to move to the next group was a bit chaotic, but by the third round everyone had it down. Towards the end it became tougher to ask people to move, as everyone looked very much “into” their conversations, and I felt badly about interrupting the flow of ideas! At the end of the four rounds, each team put up and presented the results of their collaboration.
The game went over really well. As soon as it wrapped up, team members were commenting on how fun it was and how the format made for a truly dynamic flow of ideas. Even more exciting, this exercise felt like a turning point in the sprint; although the other activities had also gone reasonably well, this was the point where I felt team members really started to “get it”.
After our fast-paced parallel prototyping work, I asked the four groups to stay together to work through our last activity, Storyboarding, an activity that allows time for small groups to create more concrete user story diagrams. I asked our four teams to take all of the ideas generated during the Design Charrette and sketch out an actual user interface showing how a user would move through the experience.
At this point a couple of teams branched out into adjoining conference rooms for some more space to think and work through their synthesized sketches. It was very inspiring to see everyone’s ideas starting to crystallize into tangible directions, and I spent time with two of groups as they worked on their artifacts.
We rounded out the day with in-depth presentations of everyone’s interface designs, with time for questions. All in all a highly-productive day, but also a tiring one. I’m glad I scheduled the final focus of our sprint, honing in on a direction, on the third day and didn’t try to squeeze it in on Day 2.
Design Sprint 2, Day 3 #
I’d planned a half day for the third and final day of our sprint, but we wound up wrapping earlier. The morning was spent on quiet reflection of our four artifacts and dot voting on the directions or aspects of the UIs the team thought were most valuable. We had some nice consensus around a breakthrough idea that emerged from the previous day’s Design Charrette and good clarity on the direction to pursue. We even had some unplanned time for conversations on a couple of side topics related to our sprint challenge, which was a nice extra.
Overall, I was really happy with how the iterations we made between the first and second sprints turned out. It’s clear that although design sprints will always take thoughtful planning and organization, the intense but rewarding process will always inherently yield ideas for how to do things differently the next time.
A final takeaway: There are no hard and fast rules for design sprints. The most important thing is making sure you’ve allocated ample time for understanding the problem, exploring solutions both individually and as a team, and allowing time for discussion of ideas and possible points of convergence.
Of course, these activities need to be closely followed by the creation of a prototype representing the team’s work and points of consensus that can be put in front of real customers. I’ll talk about that in a future blog post.