Getting Started

When your organization is looking to do ideation and brainstorming of ideas and initiatives based on your company’s vision and goals, you may want to consider lean canvas and other brainstorming techniques, which you can read about here:

However, your business is past this stage and is looking to figure out what Epics and Features to consider for next quarter, release, etc., then you may want to consider Design Sprints.

What are Design Sprints?

Traditional product development and design processes can be slow, wasteful, and motivation-sapping as your team takes an idea from its hatching through its realization, only to discard their efforts when the product wasn’t a fit to the market.
In contrast, the Design Sprint compresses product development into structured, week-long cycles of brainstorming, prototyping, and testing. It’s a process that answers critical business in short periods: at the end of each five-day cycle, the team has the benefit of immediate feedback on their solution without having made costly commitments to research or production.
The process combines 6 stages:

  • Understand
  • Define
  • Diverge
  • Decide
  • Prototype
  • Validate

This mini toolkit for creating a user experience is practical for when your team has already done foundational research and has reached the point where they need to be focused on a specific mission, or to be more precise – a specific challenge that needs a solution.
The method includes stages of a large UX process such as user interviews, user testing, and user research. These stages help us to summarize our findings about participants accurately and usefully.
In just a week, using time-tested market strategies, behavioral science, design thinking, your team can shortcut the path from idea to learning from customers; from mapping out the problem to be solved to testing with customers:
On Monday, the team identifies large, long-term goals, maps a strategy to tackle the challenge, and selects a chunk of the problem to tackle over the week. On Tuesday, the team focuses on solving the problem, examining old ideas and generating new ones (while also recruiting customers to test your ideas on Friday). On Wednesday, the team will decide on which solutions to move forward with. Thursday, the team creates a prototype of the solution and on Friday, customers can give feedback on the solution.

design sprint schedule

Prior to the Design Sprint

The success of your Sprint depends upon thorough preparation:
To get the best perspective on the challenge, it’s crucial to recruit a group of 8 participants from different aspects of the company: business, marketing, technology, product and design. It’s a great practice to request the team leader to provide the email of each participant and send them an introduction email. The email is a way to build up to the workshop, to get everyone excited and thinking about the topic beforehand.
Prepare a brief document prior to the workshop to create an introduction of the challenge. The brief should include a short paragraph that specifies the current challenge, the deliverables we would like to get by the end of the process, a vision of what a success outcome will look like and the initial milestones of the production process.
Lastly, make sure the logistics are prepared: find a suitable location where participants can attend comfortably, ensure that any necessary equipment or supplies are available (and working properly), and put together an agenda to keep the Sprint moving smoothly.
Here’s what you will need to run a design sprint:

  • Sharpies
  • Sticky notes
  • Voting dots stickers
  • A4 paper
  • Erasable marker
  • Pencils
  • Notebooks
  • Whiteboard
  • Colored paper

1. Understand

At the beginning of the day, start by clarifying the challenge statement, for example:“Re-design the product’s navigation.”To further understand the business and marketing opportunities of the challenge, the company’s VP of product delivers a 5-minute pitch, with another 5-minute pitch from the development team leader to understand the technological capabilities, and finally a 5-minute review of user feedback and competitors from the product manager.
During this 5 minutes roundtable talk of each aspect, the team writes down their notes using the “How Might We” technique; this approach ensures that the team asks the right questions and helps us find innovative answers. For example, “How might we help our users to find content they’re interested in?” and “How might we make the navigation fun and intuitive for our users?” – These questions motivate us to push the boundaries forward in terms of the user experience we want to achieve and to find new technological solutions.

2. Define

Once we understand the challenge and its components, we proceed to define the initial strategy of the solution that we’re looking for.
Start with the user: create various personas that describe the product’s users, and a journey map from when the users first discovered the product until they became “power users”. Then, a user statement which is a simple sentence that describes the user’s characteristics, needs, motivations and what they value the most.
Next, create the design principles list: adjectives that you want your users to use when describing your product.
Lastly, create the “First Tweet” – this is a visioning exercise of creating the company’s first tweet after the publicity of the solution within the Twitter limitation of 280 characters (but shorter is better; try to do it in the original limit of 140 characters!). The best guidance is to tell the group to imagine that it’s time to launch the feature and ask them “What is the first announcing tweet you will send out?”You can give the team a reference of a real tweet used to publish other company’s launches, such as Google’s tweet announcing their “OnHub” router –a real example may inspire your team to open their minds.

3. Diverge

Often, we choose to act on the first solution that comes to mind; while this can sometimes be the best solution it usually isn’t. The Diverge stage of brainstorming solutions is where the fun begins!
Once the challenge is understood and the strategy defined, we can start throwing out ideas. A technique you can use is called “Crazy 8-in-5”: each individual creates a quick sketch of eight potential UI solutions in five minutes. The purpose of this activity is to generate many ways of solving the challenge whether they’re realistic or not.

4. Decide

After sketching their solutions, each team member shares their ideas on a whiteboard, the group talks about them, and then the group votes on their favorite solutions using dot stickers. Voting this way gives a clear picture of the group’s preferences.
But how to choose one idea to prototype? Using the “Risk vs. Reward” scale, we took each popular solution and positioned it in a matrix of the risks vs. the value – It revealed what’s easy to do and important for users so we could decide which one to prototype.

5. Prototype

A prototype allows you to test ideas with customers while conserving your time, money, and other resources. Using the prototype, you can try to predict the success and failure potential of the chosen solution in a short time.
The prototype should be as close to the finished product and as polished as possible so it can be clear and easy to test with actual users to receive accurate feedback.
One team we know separated into small groups to start prototyping on paper and they also used Pop mobile app to generate transitions and links between screens. Their prototype had the look of a real interactive product. Later the company’s designer finalized the sketches into a clean wireframes using Photoshop and created the final version of the prototype using In Vision.

6. Validate

The most important question is “How do we know if we did a good job?”

In order to answer this question, we introduce the context and use the prototype to test with different users, and ask users questions that will help us discover whether we were successful at solving their problems in a way they will pay for. But validation doesn’t end there:

The validation stage also requires the technology team to review the solution and figure out its complexity; how much time it will take to develop and whether the team can support this kind of solution in their framework.

Last but not least –stakeholder validation. This layer of review is essential for the sprint to succeed. Usually, the stakeholders are the people who are funding and managing the company; therefore they can point out other crucial perspectives and make the final validation.

What to do once the design sprint is completed?

At that stage, it’s up to the design sprint leaders to monitor the progress of development. To be a sort of aid to the product managers, and be there if the development team has doubts or questions about the solution.