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.
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:
- Idea. You have an idea for a new product, feature, service, or improvement to a business process.
- Build. You go and build on this idea and create something that's working and usable for real people.
- Launch. You launch this idea to the market and hope that people will use it.
- 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.
- 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. Trailed 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:
- The type of challenge the Design Sprint was used for.
- 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.
Request a Proposal.
If you would like to #workwithmad then send us an email at firstname.lastname@example.org and let's Make It Happen.™