Design Sprints.

Design Sprints are co-creation workshops that we use at Mäd to help us and our clients create effective solutions to business problems in record time.

Design Sprints.

We will cover the why, how, and what of a design sprint, and the special twists that we put on it to ensure that they are effective, insightful, and fun! We've run design sprints for companies off all sizes and industries, from a two-person app startup who are just getting started to a multinational 100+ year-old law firm that wants to know what's coming next.

Design Sprints originate from Google's ventures capital arm called Google Ventures, that invests in a variety of startups across the world. However, the found that in the companies that they invested in, getting consensus and moving fast was often a problem. So, they started to iterate on different ways of working, and eventually came up with the Design Sprint framework.

Why Design Sprints?

The reason for doing Design Sprints is simple:

Design Sprints ensure that we build better products, faster.

Typically, to learn more about a particular product or solution for a business problem, the iteration process is:

  1. Idea. You have an idea for a new product, feature, service, or improvement to a business process.
  2. Build. You go and build on this idea and create something that's working and usable for real people.
  3. Launch. You launch this idea to the market and hope that people will use it.
  4. Learn. If your idea is successful and people use it, you observe them using it and gain insights into how you can improve and iterate on your idea.

While this isn't a terrible process, the problem is that it can take a really long time (and lots of money!) to actually learn what you should be focussing on.

At its core, a design sprint takes you as quickly as possible from that "aha" moment, the idea, to actually learning about how it could work with real human beings, in a matter of days. The following image gives you a clear understanding of the shortcut that an effective Design Sprint looks to take.

How Design Sprints Work.

While each Design Sprint is custom tailored for each client, there are many aspects and workshop sessions that are the same across each design sprint:

  • Long Term Goal Setting. Discussing and understanding the long term goals for both the organisation and the project, and how these fit together coherently.
  • Challenges to the Goals. Reviewing and discussing what are the major obstacles to the long term goals.
  • Expert Interviews. Interviews with key stakeholders on the client side to deepen our understanding of the required outcomes of the project.
  • User Journeys. Reviewing the existing key personas that will use the new website, and building their journeys based on the needs they are trying to fulfil and the objectives of Why Innovation.
  • Lightning Demos. Each member in the Design Sprint will find examples that they like around the internet and present on the key ideas and why they chose those examples, and how they might be applicable to the current project.
  • Solution Sketching. Based on the challenges to the goals for the project, everyone works, by themselves, to sketch out key solutions. These are then presented, discussed, and voted on by each member. The key stakeholder on the client side will receive additional voting powers in case of a deadlock.
  • Prototype Building. From the Solution Sketching, the design team build a prototype that uses the most
  • Usability Testing. We run test with real world potential users to gather their feedback. This is so important, it has its own dedicated
  • Reporting. Once the tests are complete, it's important that we organize the key insights and data in an easy to digest format for everyone to take a look at.

A Few Key Concepts.

There are a few key ideas that are worth remembering when planning a design sprint. The most important is not to be judgemental of the quality of the ideas presented.

We have an aptly-named acronym – NAPS+100:

  • No Judgement. Design sprint team members will not judge ideas as they are being presented. There is a specific process for the judgement of ideas based on voting.
  • All Ideas Are Valuable. Regardless of how crazy or useless an idea is, present it! During the design sprint nothing is off the table. We've had design sprints where one crazy idea turned into what would become a regional startup for one of existing corporate clients, which added tens of millions to their revenue.
  • Piggy Back. Feel free to take inspiration from what other organizations are already doing, we are not aiming for 100% originality.
  • Silly Crazy. Remember to have fun, and don't be worried to be perceived as silly, often the best ideas seem ridiculous at first.
  • +100. This stands for quantity. Often, your initial 20-30 ideas are just offloading ideas that you already had in the back of your mind, and it's only after those are finished that the real thinking and creative problem solving kicks in.

A few other important things:

  • Working Alone, Together.
  • Note & Vote.

Design Sprint Sessions Explained.

Below we explain some of more common Design Sprint sessions below.

  • Long Term Goal Setting.
  • Challenges To The Goals.
  • Expert Interviews
  • User Journeys.
  • Lightning Demos.
  • Solution Sketching.
  • Prototype Building.
  • Usability Testing.
  • Reporting.

Frequently Asked Questions.

When to use a Design Sprint?

What is a good challenge for a Design Sprint?
Taken from:
Not every challenge needs to be addressed with a Design Sprint; there are plenty of situations where the Design Sprint is not the right tool to use. A good challenge for a Sprint can range from something broad like, “Define the future vision for my product 5 years out” or “Explore opportunities to better meet the needs of children and technology” to more tightly scoped challenges like, “Improve the onboarding for new users of my mobile app” or “Increase engagement for high volume users of my app”. A Sprint will be most valuable when scoped to the needs of your business and team.

If you don’t have very much user research and are just starting to build an understanding of your customer base it is a good idea to conduct research first. nce you have useful insights to fuel your Sprint, you can begin the planning stage.

Alternatively, if you have a clear product direction and agreed upon feature set, you probably don’t need a Sprint -- you just need dedicated working time for your UX Designer and Developer to create the product. A Design Sprint is best used when you have a set of conjectures or questions that you need to explore to make sure you aren’t investing time building out a full solution based on a hunch.

How many people should be in a Design Sprint?
Ideally, the team should be no bigger than 7. In our Design Sprints we normally have 2-3 people from Mäd and 3-4 from the client side.  This ensures that things move relatively fast, and that the Design Sprint doesn't turn into a conference.

Who should be in a Design Sprint?
The best Design Sprint teams are made up of cross-functional team members

The Key Stakeholder doesn't have time to join the Design Sprint, what should we do?
If possible, it's great to have them come in for an Expert Interview, so they can set the tone and direction for the Design Sprint. If that's not possible, a team member can be sent to interview the Key Stakeholder at their office or via a phone call, to ensure that key inputs and constraints are noted and everyone is aware of them.

What happens after a Design Sprint?

Sample Mäd Design Sprint Schedule.

While the original Google Ventures Design Sprint requires the entire team to participate for five full days, we've made some adjustments to the scheduling based on our client feedback.

The Mäd design sprint requires our clients to work with us for two full days, and the remaining three days are completed either in-house building the prototype or in the field testing it. We find that this gives the optimum balance between client participation and also ensuring that our clients can still manage their usual day to day job responsibilities.