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, they 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 organization 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.
  
  Solution sketching could be a blank canvas but to help with visualization, we prefer using UI templates with a phone or a laptop mockup. We've created our own Mäd branded UI template for that additional personalized feel.

• 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 – MÄDS100+:

• M: Mad/Crazy. Thinking outside the box is encouraged, sometimes to create amazing ideas you need to explore the outright whacky!
• Ä: All ideas are welcome. Going in to the task with an open-mind is ideal, ensure everyone-no matter their profession, seniority, experience-knows that they can suggest any idea (even if it’s unconventional or misaligned with what others are thinking).
• D: Design from Leaders. There’s no need to always reinvent the wheel. Sometimes piggybacking from the success from others makes the most sense, i.e. learn from the best and get inspired to improve upon it or take proven (and tested) elements into your consideration.
• S: Safe Space. If crazy ideas are encouraged, all ideas are welcomed, and copying from the best is deemed acceptable, then we need to reaffirm that there’s no judgement on any ideas. To help team members feel comfortable with the task, and therefore produce more (and potentially better) ideas, ensure that everyone knows they’re in a safe space to suggest whatever comes to mind.
• 100+ : Quantity produces quality. Common ideas are often shared, and it’s not as difficult as you think to come up with 100 basic ideas on any given topic. Once we get past the first 100 ideas, we start getting into really unconventional territory - which can be where so many brilliant novel ideas come from. If you’re able to push yourself to go beyond the common-sense ideas, who knows, you might stumble on to the next big breakthrough!

A few other important things:

• Working Alone, Together. Tried and tested, we find working alone, together to be the best of both world. We can work on refining our own ideas and only bounce ideas off each other only when we feel like it.
• Note & Vote. This goes back to our belief that all ideas are valuables. To give everyone (not just the most respected person in the room) a level playing field in voicing and voting on what they thing is best.

Frequently Asked Questions.

What is a good challenge for a Design Sprint?
Like a Swiss army knife, a Design Sprint has many intended uses and is something that you can definitely play around with creatively. However, it is just one out of many tools out there. Here are some examples of the different types of projects that may benefit from a Design Sprint:

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”

Other than its Swiss army knife nature, its ability to accommodate different business needs allows for that special tailor-made approach to problem solving. This is why we rave about the Design Sprint so much.

To make the most out of our Design Sprint session, we like to incorporate user research pre-Design Sprint. Not only do insights gained from a user research serve as a starting point of discussion for us to build on during the Design Sprint session, understanding your customer base is also one of the most important safety measures one can take, especially when starting out.

All the talking about the many uses of a Design Sprint, you may be wondering 'when is it not necessary?'. A good way to think of it is, a Design Sprint is best used in the exploration stage, meaning when you don't have a defined direction yet. Therefore, if you already know exactly what you want i.e. direction, feature etc., this is when we would say it's more relevant to look to a dedicated UX designer / developer and start building your product.

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 to ensure we have a well-rounded solution to the project at hand.

From Mäd, we typically include a UX designer, a Developer, a User Researcher, a Product Manager, a Content Strategist or others depending on the types of projects and the solutions required.

From the client side, it's important that any stakeholder or key decision maker can join. At the end of the day, we need approval or sign-off on some of the solutions proposed during the Design Sprint. However, we understand that stakeholders are busy people and we accommodate to this by arranging a 'check in' time for decision-makers to review decisions at important moments throughout the Sprint.

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?
After pouring all the hard work into the Design Sprint, it's natural to want to know what's next. However, just like how every business need is different, every design sprint is also different.

It generally depends on two factors:

1. The type of challenge the Design Sprint was used for.
2. The outcome of the Design Sprint session.

Below is an idea of what you can expect more or less:

• Prototype. Based on the feedback received during the sprint session, we begin what we call a "dirty prototype" that clients can use on a real device.
• Test. (Test. Test. Test.) We can't stress this enough. Testing is what allows us to know what works and what doesn't work before we invest further into something that might be completely off from what we want.
• Revise and Adapt. As its name suggests, the "dirty prototype" is only a rough sketch; it usually takes a couple of tries to get it right, but this is all normal. Therefore, depending how well it's received during the test stage, we generally will begin to revise and adapt parts of the prototypes accordingly.

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.

Resources.

• Mäd Design Sprint Rules.
• Sprint Book by Jake Knapp.
• Design Sprint FAQ.
• Google Ventures Design Sprint Overview Video.