The 3-Hour Design Sprint

If you’re working in business, IT, product development or marketing and haven’t been living under a rock for the past year, you will have heard of design thinking and of one of its practical applications, design sprints. We recently tried the condensed 3-hour version of the design sprint and I want to share our insights from this with you. If you have been living under a rock, firstly, I am very sorry. And secondly, don’t worry, I will explain the basic principles as we go along.

Design sprints were originally developed at the California-based design company IDEO and the University of Stanford and were later refined and made popular by the team at Google Ventures. The basic idea is to gather a representative focus group of people representing different viewpoints for an extended brainstorming and assessment session, with the goal of developing a brand concept, a product, a prototype or similar things. Depending on what you are looking to develop in or gain from the sprint, it can be a process of up to several weeks. However, it doesn’t necessarily take that long. Several streamlined versions exist, that can give you similar results in five days or even three hours.

We recently decided to put Google’s brand design-sprint to the test, with a time-frame of three hours and five participants. We got together two developers, one person from marketing (hint: me), one person from sales and one independent moderator. Our goal was to create a marketing and sales concept for a product. We didn’t exactly need to develop a brand, since we had previously talked about the product — a logo and rough brand design existed and we all had a general idea of what it was going to do (more on why that’s a good as well as a bad thing later).

The Plan

The product we wanted to create and develop a sales and marketing strategy for was the ‘Job-Botler’, which is a specialized chatbot for companies. As the name might tell you, it can lead jobseekers through the application process and field applications for companies, preselecting top applicants according to defined key criteria.

We started by levelling the playing field, so to speak, with the moderator explaining the goals we were to achieve in the three hours. These goals were set by the product owner, in this case one of our CEOs, who was not present during the sprint. The reason for this is that the participants tend to censor themselves more when the product owner takes part in the design sprint. Therefore, it is recommended to involve him or her only at the very beginning and at the very end when the results are presented to them.

The Process

After the introduction, we spent the first half hour writing down answers to a number of predefined questions. We were asked to fill sticky notes with things that we associated with the brand or product, things that we wanted others (customers and users) to associate with it, the top technological challenges from our point of view, possible customers and users as well as goals we wanted the product to achieve in, say, five years from now. We then sorted the notes, sticking them on the sheet with the corresponding question. We clustered the answers where appropriate and then quickly (because, seriously, three hours isn’t a whole lot of time) moved on to our next step.

This already helped us gauge several likely directions or points of focus. In the second half-hour we narrowed down this focus, helping us to decide which issues we were going to discuss further in this sprint. Each of us got five votes we could use on the most important issues, the things we thought needed our immediate attention. Whatever came up highest, of course, would be discussed further. Things that didn’t get any votes at all were going to be left for future sprints or meetings. And that was our first hour done. One down, two to go.

The Second Hour

The idea for the second hour was the most straightforward, but also the most gruelling. It was discussion time. We talked about the topics which got the most votes (or really, any votes at all, because we kept the number of total votes low on purpose so we could discuss everything we deemed important). The aim of our discussion was to boil our ideas down to our top goals (e.g. how can we overcome the technical challenges we are facing, how can we ensure top usability, how will we market and sell the product, who are we going to sell it to and who is ultimately going to use it?) and then define measures to reach these goals. It was a lively discussion and because everyone had already come into the meeting with some idea of the product and the direction it was going to go in, it was not always plain sailing. We managed to reach a consensus in the end, but boy, were we spent. Luckily, we had a short break scheduled to get our energy back up and then it was one more hour to go.

The Third Hour

In the third hour we extracted concrete to-dos from the measures we had decided on. In our case, we were going to make a rough prototype, so we could start showing the product to a few potential clients. Obviously, the developers were going to take care of this. We had also defined that we wanted to usability-test our product, before we did any substantial development, just to make sure we weren’t going to head in a completely wrong direction with it. Of course, this would also take some preparation, which we made a start on in our remaining time.

As a first step, we decided to focus on the usability for the potential end users as opposed to companies we could sell the product to. Our reasoning being that most customers would have similar needs in terms of function, since the application process wouldn’t differ greatly from company to company. Of course, functionality would be an issue later, but we decided to stick to a basic set of functions (which we defined) that could be expanded in the future. Thus, we set about creating a rough group of personas by defining potential use cases (e.g. someone looking for a specific job at a specific company, someone just browsing available jobs, someone applying for an internship and people from different experience and academic levels). Working out the actual detailed personas was one of the to-dos for later. Those personas, together with their sample conversations, which were also to be created, would be the basis for our usability tests and, as an added bonus, would also help the developers with their prototype.

The Outcome

When the three hours were over, we left the room with mixed feelings. The ideas we had gathered were good and we were pretty confident in the direction we were taking. But we felt physically and emotionally drained — it all felt a bit rushed. That’s not to say that the concept we came up with felt slapped together. I’m pretty sure that we would have come up with a similar plan even if we had taken much longer, but it wasn’t exactly a satisfying experience.

So Three-Hour Design Sprint Yes or No?

Yes, definitely. However, be sure that you are clear on what you want to achieve in these three hours and make sure your goals are not too ambitious. As you may notice, our (yes, rather ambitious) goal was to define a sales and marketing strategy — we didn’t. But we did successfully define a way of moving forward and set the direction we were going to go in. And it only took us three hours (or 15, cumulatively). If we had not tried the three-hour sprint, we probably would have done it in the same time, in terms of the total hours spent, but it would have dragged on for weeks. We are very much a project-based company and don’t usually do product development, so this way of doing things allowed us to streamline our decision-making and to move on to the next step much faster than we would have.

But hold on there, it’s not all sunshine and daisies, unfortunately — there are cons to this as well. As I said, we all had a rough idea going in. As it turned out, these ideas differed quite a bit and that complicated matters as far as the discussion goes. Nobody felt that their ideas were completely reflected and what we came up with is a compromise, a sort of middle ground everyone is reasonably happy with. Now, while that’s by no means a bad thing, it doesn’t greatly differ from what usually comes out of normal strategy meetings and discussions. Our design sprint didn’t produce any brilliant ideas and I don’t think a three-hour sprint ever will. However, if you have a straightforward goal that’s more on the conservative side, like building a basic brand concept or defining the next steps you should take in your product development, it can be a good way to get you going quickly and with minimal effort. I wouldn’t necessarily recommend it for making huge important decisions that will have an impact or will set the course for years to come, since (due to the time constraint and relatively low number of people) you have the potential of going really wrong here as well.

All in all, the three-hour design sprint is a concept that doesn’t work for every purpose and it’s a concept that doesn’t work for everyone. It takes a pretty open-minded group of people who can master discussions with diplomacy and with the attitude that every issue needs to be heard, but not every detail needs to be discussed. Otherwise, three hours are not going to cut it. More complex issues and more diverse groups with set views would probably benefit from a longer design sprint that offers more opportunity to incorporate every angle and point of view.

The concept of the design sprint as such is definitely a good and efficient way of coming up with an idea, a brand, a strategy or a prototype — even an entire product. If you are looking to develop one of these in the near future, I can only recommend you give the concept a try. If you’re interested, you can find some further reading on this below.

Further Resources

Book: Sprint by Jake Knapp (Google Ventures)

Design Sprint Kit — useful resources (Google)

Blog: Design sprint: a checklist for facilitators in big companies by Martina Moreira (uxdesign.cc)

Video: How Design Sprints are Flexing for Success by Kai Haley (Google Developers)

Video Playlist: Sprint by Google Ventures

The CodeFlügel blog — news, tests and how-tos about the latest technology trends. Focus on Augmented Reality and Virtual Reality & some other more nerdy stuff.