Why Might a Team Consider Conducting a Design Sprint?

Companies with design departments all practice different ways of creating new designs and products. Some incrementally design the foundation of an idea over several weeks and get to developing after validating a few screens, while others get to crunching code as soon as possible. There’s pros and cons to every method, and some methods are better in scenarios than others, but one method that continues to stand out is the Design Sprint, a five-day race from problem definition to testing a realistic prototype of the solution.

So, why might a team consider conducting a design sprint? The format of a Design Sprint is perfect for helping teams answer huge organisational or product questions, while also providing a straight-forward framework for driving cost and time efficiencies in your product development cycle.

Keep reading to find out more about the scenarios that are best suited for using a Design Sprint and how to efficiently conduct a Design Sprint in your business.

Why Consider Conducting a Design Sprint?

Launching an entirely new product to your portfolio is a risky proposition. You might consider conducting a Design Sprint if the product or feature is of medium or high risk.  

Whether you are a part of a start-up, or working in a department for a global company, more often than not, countless hours and funding go into building a core idea from the ground up. This is usually to try and mitigate risk, ask questions about viability, and pick out the best path(s) forward during the product development cycle.

This doesn’t stop good ideas on paper falling short though. New product launches, accompanying products (e.g. a complementary app for a video game) and innovative features all run the risk of falling flat in the hands of users if they don’t meet user expectations, don’t provide additional value, or simply have bugs that sour your launch.

There are thousands of ideas that were far ahead of their time, but ended up being too early for the market in one way or another (anyone remember Nintendo’s Power Glove?) resulting in high sunk costs, unhappy investors, and failed companies (in fact, 95% of new products fail). That’s why it’s important that teams actively try to de-risk product development and build in steps that verify the ideas you proceed with are useful, timely and solve a core user problem.

Why Design Sprints Work for Businesses

Design Sprints work for businesses in two ways: they help internal teams work more efficiently and they also help the business run smoother. 

Benefits Team Productivity

Design sprints are designed to be iterative; they enable teams to:

  • Test run new concepts
  • Evaluate specific ideas
  • Start fresh in very little time
  • Allow multiple ideas to be evaluated quickly to find the best idea for the target audience
  • Fewer tweaks to the user interface post-launch, less ironing out bugs, and more confidence from Product Leaders that it will have a positive impact.  

The premise of prototyping and gathering user feedback is invaluable to companies when the stakes are high. Afterall, going to development without getting proof of concept or feedback from your end user is leaving your product or feature’s success to chance after all the investment and time has been put in. You don’t want to be starting again from the drawing board after the product has been launched.

With a condensed design cycle built into the 5-day sprint, Design Sprints empower teams to gather feedback before the higher cost activities come into play (development and marketing). This enables Product Manager’s to reduce the risk of failure by using real user insights to verify if you’re on the right track or not early, giving teams more flexibility and opportunities to explore their concepts further.   

Benefits to the Business

If you’ve ever asked yourself the question. “Design Sprints are about working with limited time and under pressure, won’t I just make those same mistakes?” 

In short, no. Although there’s a target of turnaround within a week, the time-based setting, presence of other experts/stakeholders, and the awareness that you’re gathering feedback can increase your chances of success further down the funnel. It’s a long-term gain from an intense short-term experiment.   

Design Sprints are designed to:

  • Create efficiencies and reduce wasted motion throughout the entire process
  • Only focus on design thinking and creating a UX approved interface
  • Reduce costs so you can replicate the process until you have a desired result before committing to development on the idea. This is especially important when you consider 50%-70% of an app’s costs is in development.

As a framework with distinct stages, Sprints also allow teams to recruit only the team members required to condense work into as little as a week. This creates savings in the long term by reducing waste from unproductive meetings that would have otherwise been used and focusing teams on tackling tasks without distractions.

Benefits of a Design Sprint Phase

A Design Sprint needs to be structured correctly in order for you to get the most out of the process. Below we have detailed some of the main benefits of a Design Sprint to make sure yours can be as effective as possible.

Why might you consider a Design Sprint? How are Design Sprints set up to achieve this?
To save time 5 day turnarounds for user feedback on big concepts to answer pressing questions. 

Says “no” to repetitive meetings, low engagement, and slow decision making.

To save resources/reduce cost As the entire process is packed into a week, companies can save on resources spent (which would otherwise be months of paid meetings and back and forth) and the cost of bringing an idea to market.
When the product is a risk

Having access to user feedback early in the product development cycle means you have the data to back up or contradict your concepts.

This helps decide whether an idea is worth pursuing or if it would be wiser spending your budget elsewhere.

To gain clarity on where to start

A lot of time can be spent pitching ideas when the problem may not be fully understood or fleshed out.

Sprints are set up in a way that bring the team together, harnessing each other’s expertise and allow for critical analysis on potential problems before ideation, creating consensus on where to start and what avenues you have to resolve it.

Design Sprint Benefits on Budget and Resources

Whether you’re a start-up or the product team of a household brand, we all have budgets. Size varies of course, but they are almost always finite, and these budgets often underline your activities and narrow your options for any given action, whether that’s how much money you can spend designing, to your budget building the digital architecture at the development phase.

Budgets also come with expectations. You have bosses or shareholders that need to be impressed and feel confident that the resources provided are being used responsibly and are expecting results from wise budget management. 

The issue is traditional, non-agile product development can be exceedingly wasteful in terms of resources, from unnecessary meetings to poor quality control all resulting in delays and increasing costs due to not planning resource allocation correctly.

 If You Have Limited Time 

Time is a constant factor for companies and their employees. Whether it’s a race against time to launch a product ahead of a competitor or internal deadlines which expect product development progress, time can influence the goals companies and their teams have. 

But the pressure of time can also lead to rash decisions and corner cutting. Product Leaders under pressure may sign off on development for designs or concepts without considering others due to internal deadlines. Rushes in the product development cycle also leave the product open for errors; limited testing, shoddy code, and ill thought-out designs can all leave your launch feeling underwhelming to users.

In short, time pressures without a structure or support plan in place can force mistakes which ultimately dampen your launch before it’s even been developed. 

Design Sprints have the benefit of time savings, compared to simply conducting meetings in a Sprint’s place. One study suggests that 71% are considered to be unproductive, while Bain and Company report that 2/3’s of meetings end before an important decision is even made.

If You Don’t Know Where to Start or What the Best Idea is

Taking the first step is usually the hardest one. You may know customers aren’t responding well to an out-of-date interface or you need to produce a new product to catch up with competitive pressures. But even if you know the threats, you don’t necessarily know what the biggest problem causing these issues is or what the best idea to tackle the problem could be.

This could result in multiple meetings (see issues with general meetings in the previous section), brainstorms, and the creation of specifications and technical documents. All the while, key decision-makers may be absent and not be able to present their case for an alternative, and possibly better, solution entirely.  

This confusion can last for months, creating a strategic brain freeze without any path forward, compounding both time and resource concerns in the process.

Example of De-Risking Launch via a Design Sprint – Facebook

Facebook used a Design Sprint to improve their news feed’s user experience. This resulted in the cleaner, more streamlined interface we still use today.

Changing an interface wasn’t a riskless proposition though. With a base of 2 billion users, changing the interface would need to be done thoughtfully to not only improve upon the existing experience but to also feel familiar and retain usability for everyday users.

Example of Trialling Multiple Ideas via a Design Sprint – Slack

Popular team communication platform Slack ran a Design Sprint to coincide with their strategy to appeal to a broader audience of businesses beyond tech companies. 

This meant describing Slack’s value proposition on the website in a way that described the benefits for teams in a way that could be easily understood across all sectors and tech competencies. This ultimately included options like a video explanation video and even an interactive guided tour.

The Process of Conducting a Design Sprint

There is a lot of preparation that goes into running a successful Design Sprint. 

Check out our previous post on how you can prepare your team and working environment ahead of a Sprint at the bottom of this post.

Once all preparation has been completed on your Design Sprint, we would expect it to look like this:

Day 1 – Problem Recognition

On Monday, we define the long term goal that the team has identified. For example, this could be wanting to retain more customers, increase revenues, increase active users etc. 

With this in mind, the team would then list questions that need to be answered to achieve that goal. This could be framed as “how might we…” (e.g. how might we increase user engagement to keep customer returning), ask what needs to happen to make the long term goal a reality, or what needs to be true to achieve that goal. 

The customer journey can then be mapped out, listing different actors, e.g. retailer, manufacturer and customer, and experts in your team can then embed their unique insights to bring to life how customers feel and what’s going on at each stage.

Voting is then conducted on the most pressing question in relation to the long term goal and the part of the journey map the team will focus on. 

Day 2 – Ideation

With confirmation of our target on the previous day, the team will now work towards sketching out as many solutions as possible. This can include the use of lightning demos (short demos of existing solutions) for inspiration on possible features and the option to divide your team to tackle parts of the big problem.

By the end of the day, you should have a mass of viable concepts to decide on during Wednesday’s Sprint.

Day 3 – Decision Making and Storyboarding

Voting will now narrow down the ideas presented and allow for praise, questions and concerns to be identified against remaining solutions. Solutions post-vote will be built out further via storyboards, creating all of the screens the end user will encounter during the user testing phase on day 5. 

Final voting to determine the solution(s) that will be built on day 4.

Day 4 – Prototyping

The designers in the team will now set out to build a realistic prototype based on the storyboard(s) from day 3. This involves selecting the right tools, building screens and interactions, and ultimately stitching the experience together. 

Trial runs should be conducted by the end of the day to make sure all functionality operates as expected. 

Day 5 – User Feedback

If you’ve read our post on organising a Design Sprint (see related posts at the bottom of this section), you’ll have already scheduled 5 people from your target audience to test your prototype on Friday.

We recommend for digital experiences in particular to run a screen share over the prototype, allowing you to interact with the tester and give them tasks to gauge usability and user sentiment throughout. 

Record the answers given and at the end of the day analyse the data for common themes, any issues identified, and areas the user reacted positively to. 

From here, you can then determine if you should continue with the concept as it is, refine the prototype based on the user feedback and test again, or conduct a fresh Design Sprint with another concept from the week.

Get your FREE Design Sprint Guide

Download our FREE guide on running a 4-day Design Sprint complete with stages, tasks and common pitfalls.

Download the guide

Design Sprints with PixelTree Media

With over 6 years delivering Design Sprints for everyone from innovative start-ups to household brands, PixelTree can help deliver the UX expertise for a successful week’s Sprint. Check out our Design Sprint page and our associated FAQs here.

Working from home more often now? Remote Sprints could be the answer. Collaborate with us for an intense (virtual) week over Miro! Check out our link for our Remote Design Sprints here.