For the past two years, we have been running design sprints here at Constant Contact. Design sprints are a 5-step process for solving discrete business problems through design and prototyping that end with user testing. Our innovation team works with different areas of the organization in a consultative capacity to facilitate design sprints for many groups in the organization, from Product, to HR and even Finance. Additionally, since the opening of our Innovation Loft and Small Business Innovation Program accelerator in 2014, we run design sprints with the startup teams that are in-residence. To give you a taste, Patrick Solvabarro, CEO of Upward Labs, one of the Innovation Loft’s first startup teams remarked: “Design sprints are like mini science experiments!” We like that statement. It is an experiment with added design and sketching involved, though. Not to mention Post-it notes. Lots of Post-its. Because we love Post-its.
Our version of a design sprint consists of five phases–similar to Google Ventures or our friends at thoughtbot, but it differs slightly… We spend a little more time digging into the problem before we attempt to ideate on a solution. The names may differ for each phase but the overall goal remains the same.
Our design sprint process looks like this:
Define -> Understand -> Ideate -> Build -> Test
This flow is slightly different from Google and thoughtbot’s:
Understand -> Diverge -> Converge -> Prototype -> Test
I’ll detail each to describe them further; we do take time to set the stage beforehand to plan the sprint. I’ll write about preparations in another blog post.
Define: Define the Problem
We sometimes call this “Data Exchange,” as it is about digging into what we know, what we think we know, and what we don’t know. The objective of this phase is to lay out all the information about the topic and identify what knowledge gaps exist. We’ll prioritize those knowledge gaps and seek to gather more information. We seek to extract the information out of our heads, PowerPoint decks and Excel spreadsheets on the wall so everyone can get a grasp of the situation. Sometime this is in the form of questions that we’ll use to interview customers and it almost often includes a request to our business intelligence team for a data pull.
Understand: Understand the Problem
During the Understand phase, we pull together any newfound knowledge, perhaps from the customer interviews or recent data pull, and see if there are any conclusions we can draw (“Understand the problem”). The objective is to refine and reframe the problem we’re trying to solve. Reframing is when you look at a problem in a new way. For example, if I asked you “What is two plus two?” you might state “Four, silly man,” and you’d be correct. If I asked you “What two numbers add up to four,” there are an unlimited number of possibilities. One way to ask the questions gets one type of answer; a reframed version can generate multiple options. Before jumping to the solution, we seek such insights by reframing our problems so we’re pushing the boundaries of where the solutions can go. Not only do we define the problem, but we also define who has it and for what context. With over 600,000 nonprofits and small businesses as our customers, there are many segments where we can focus.
Ideate: Solve for the Problem
Once we’ve identified what the problem is, who has it and in what context, we’ll generate solutions. At this phase, we often bring in other members of the organization who may have nothing to do with this project to offer a fresh perspective and help reduce groupthink. The objective is to generate a quantity over quality of solutions for the identified problem. Once we have produced a number of solutions, we’ll converge to a manageable number of ideas to test with users. Our first design sprint tested three different concepts, and that was quite difficult to pull off. We now limit the number of concepts to a maximum of two, with usually one concept being what gets built and tested.
Build: Create the Solution
With our ideas crunched down and converged into one or two we believe might solve the problem, we’ll spend this phase building a concept prototype to test. We call this an MVC: Minimum Viable Concept, as an homage to the popularized MVP: Minimum Viable Product. Typically what we build is not anything that could be a standalone product; rather they are concept solutions to jobs our customers need to accomplish.
Test: Real Users Try the Solution
This phase is where the rubber hits the road. The preceding days are intense; I remember staying at the office quite late for many build days as we worked to get everything ready. There is nothing like a set of scheduled customer appointments as a forcing function to get your MVC completed.
When testing, we prefer to test with at least five users and never more than ten. During a few design sprints, we tested between 15 and 20 users. Not only was that draining for the team after an already intense week, we also found that after seven or eight users we started hearing similar feedback. We were no longer learning new information about our concept as a possible solution.
Recently, I ran a design sprint with current in-residence startup team Faze-1 and their results were positive, but one big question still remained. The most interesting thing for me was seeing their transition from “He-who-argues-loudest-wins” to that of “our opinions don’t matter, our customers do.” The team emerged far more aligned in the direction of their product than they entered.
When Your Great Idea Fails
In mid-2013, we took an idea from one of our Innovation Jams called “Marketing Smarts.” The premise was what I often call the Clock-Radio product: Take two things and mash them together. That team that came up with the idea had data showing increased usage of mobile technology among small businesses along with additional data showing increased consumption of Constant Contact’s educational content. We have copious articles, blogs, webinars, and other content to help our customers craft their marketing campaigns, so what if we put this into a mobile app? We ran a four-day design sprint with a test of six different customers. We heard nearly the same response from all six users during Test phase: “That looks nice, but I wouldn’t use it.” While we were initially disappointed, we learned that a specialized mobile application as a vehicle for accessing our help content was not the answer. Further, we saved ourselves a ton of designer and developer resources. What if we just went and built that product? We would have spent too much of our valuable designer and developer resources on something customers would not use.
What Happens Next?
After a design sprint, a few things can happen. Usually, they fall into a three categories: it worked, it exploded, or questions remain. I’ll detail how we manage each in a future post. Remember, ‘Life is too short to build something nobody wants‘. Design sprints can help organizations accelerate their learning in order to deliver products and services to market that fulfill customer needs.
Resources to learn more
Design Sprint: A Guidebook To Building Great Products
thoughtbot’s Design Sprint Repository
The Constant Contact Small Business Innovation Loft program application is open for our June 2015 class until March 10, 2015
Please share your experiences with design sprints in the comments section, we’d love to hear how others are using them!
cool stuff
Good and simple Information