15 Ways Your Design Sprint Could End in Failure

Now Design Sprints aren’t easy. Take it from people who have run a fair few, there are an endless list of reasons why a Design Sprint can end in failure. And we’re not talking about getting an opposite result in your experiment, that can be a great thing. We’re talking failure to reach the end or achieve the goals you set out. With a lot of moving parts, combustible elements (or characters) and deadlines, it can be easy for the pressure to cause the Sprint to collapse before you even reach the end of day 1.

However, that doesn’t mean all is lost and you should abandon a 4-5 day design cycle. Preparing for scenarios which can cause your Sprint to derail is key to ensuring your team and your deadlines stay on track.

But what reasons can cause Design Sprint failure? In our experience, a lack of research beforehand, not selecting a varied pool of experts, allowing distractions, failing to map the problem correctly, having too large a storyboard scope, and not testing on your target audience are among some of the reasons we highlight below.

We’ve broken down the causes of Design Sprint failure down to the days they’re likely to make an impact within Jake Knapp’s original Sprint outline:

• Day 0: Pre-Sprint
• Day 1: Map out the journey, determine goals and challenges
• Day 2: Sketch out solutions
• Day 3: Decide on the best solution
• Day 4: Prototyping
• Day 5: Testing

So if you’re looking to see the common causes of Design Sprint failure and how to avoid them, read on.

Sprint Day 0:

Not preparing the environment

The Problem

The old saying goes, “failing to plan is planning to fail”. Having all the Sprint materials on hand is critical to getting the desired results. By not having things like sticky notes, stickers, pens and paper, you may be preventing your team from getting the most out of the experience.

Although you could say everything can be organised by computers running the same process, using computers in the same room reduces person-to-person interaction and opens the door for distractions to creep in.

But it’s not only the materials to actually conduct the Sprint. Timers, snacks and refreshments are needed to help keep people on track and fueled up without having to leave the room or break concentration.

The Solution

Make sure you know the number of people you’re looking to have as part of the Sprint team and plan accordingly. Book a meeting room you know is in a quieter part of the office (you don’t want noisy neighbours), and look at how you can create the best environment, from seating arrangements, to where the sticky notes will go etc. Overestimate the number of materials you have (it’s a good thing to overprepare sometimes!) and make sure the snacks/drinks are healthy ones to prevent burnout or worse, a sugar crash.

Not enlisting the right experts (or too few/many)

The Problem

In Sprint, Jake Knapp compares the varied skillset of your ideal Sprint team to be the equivalent of George Clooney’s Ocean’s Eleven band of thieves; each an expert of their craft and bringing something unique to enable the plan to be executed.

Diversity among roles and departments in your team is critical. Having a team that’s 80% designers or developers is probably not going to work as you wouldn’t have a large enough pool of diverse experiences and insights to draw on. You need people who can fulfill at least one of the following points:

• Has a great understanding of users or target audience through data and/or is a close touch point
• Understands the user journey as it currently stands
• Has a technical understanding of best practice, state of the current issue, and how it can be resolved

The challenge can also be made more difficult if you don’t know how many people to recruit, as too few may leave experts out of the picture, while too many could mean wasted time or clustering around specific solutions due to allegiances.

Beyond all this, making sure you’re able to recruit everyone is vital. If you conduct a Sprint but miss out on using a person who fulfils all previous criteria, your Design Sprint could end in failure due to not accounting for specific data or facts. The worst case scenario is missing the person responsible for the project, as this can mean by the time they do look over the results or are involved, they could have provided some vital direction/information.

The Solution

Based on the objectives you’re looking to hit, enlist the best members of the team for the job. This can be done by understanding the touch points of your customers, who they engage with, who has access to the data that best informs how you could go about this. This typically means asking management-level team members who are well informed and can speak on matters in depth.

Draw conclusions of who are focal points from a technical and problem recognition stand point. E.g. if your HR team are not relevant for your app’s conversion rate optimisation project, don’t invite them along (no offense HR!).

The rule of thumb is typically to recruit less than 10 people, as this will mean you have more detailed conversations, and less time is used generating duplicated ideas, prototypes, etc. This just a guideline though, and as we cover in ‘Failing to map the problem correctly’, we do encourage other experts to drop in at intervals at specified times if they can add something to the conversation.

Sprint Day 1:

No user research at the start

The Problem

Don’t get this confused, it’s critical for existing designs but a team would be unwise to write off the importance of research for a new idea too. When going into a Sprint for a new feature, idea or product, having your hypotheses or knowledge rooted in research is critical. Crit-i-cal.

Admittedly, your team of experts will hopefully be bringing their own research to the table, but what’s key is that this expertise is quantifiable or based in common qualitative feedback rather than gut feeling. Putting forward judgements or issues routed in best guesses or anecdotal evidence can be problematic and lead to a slowing of progress, or worse, going in the wrong direction.

This goes without saying for existing features/products. With the success of Design Sprints being rooted in solving problems quickly, if for digital products you aren’t utilising heatmaps, analytics or interviews to make your business case, your Sprint could be heading for failure early.

The Solution

Harness the user research in your organisation or look to conduct fresh research. Depending on the problem, you can talk to your customer service team, marketing team, sales team, and pull through data on areas like bounce rates, conversions, user experience, and general user issues. Collate items like heatmaps and recordings and quantify those sessions to get the best picture of the issues facing your company.

For new products, look at a combination of surveys, interviews and secondary research to support why you’re looking to build this product, app or feature.

At the end of the day, spending x on research is way better than spending tens of thousands more on developing an untested concept that falls short.

Not investing in the process

The Problem

For some people, a Design Sprint might be a process they didn’t want to use, and by being part of the process they underdeliver or demonstrate a lack involvement because they aren’t invested.

Another way this can manifest is in team members who don’t respect the roles given. In Sprint, the team are either ‘experts’ or ‘The Decider’, the latter having the final say on what ideas and challenges remain the focus of the Sprint. If say the most senior member of the organisation does not buy into the Sprint process entirely, things can devolve quickly, with other team members recognising the lack of seriousness and following their lead.

Alternatively, it could be an unwillingness to make yourself unavailable for the days required. This can be difficult for those who are without other team members to pick up the slack or are constantly in demand to answer questions, meaning they may never be fully into the process.

The Solution

Before agreeing to take a Sprint approach, make sure your team are all aware of what it entails. Concentration, out of offices going on, and limited phone use. But also acknowledge that this is being done so you can solve big problems fast, which will be a huge benefit the entire company if done right. Aligning everyone before hand can mean less fuss in the process and an understanding of your shared objective.

Failing to map the problem correctly

The Problem

Mapping the end user and stakeholders process is one of the core tasks on day 1 of a Design Sprint, and done wrong, is one of the main reasons for failure. By not being able to clearly outline how your customers interact with you, your intermediaries or other essential parties to the service provided, you won’t have access to a full and constantly visible representation of the process you’re looking to improve or innovate on.

The Solution

Typically, selecting the right experts can remedy this situation in most cases. If you’re still having doubts about your map or have gaps in your knowledge, we recommend inviting other team members with unique insights in to verify the map by the end of day 1. They don’t have to officially be part of the team, but by giving them a chance to oversee the map, they could spot other relevant stakeholders or offer alternative views on the map that will be beneficial when forming solutions on day 2.

Distractions!

The Problem

Phones, tablets, smart watches, you name it, it’s all a possible distraction from the task at hand. The hard deadlines we use in Design Sprints mean that time needs to be used as efficiently as possible, and distractions can cause the experts to delay responses or focus elsewhere.

This can be especially difficult for experts who are consulted frequently or a common touch point for customers or employees, meaning they can be more difficult to detach from the regular work pattern.

Distractions can have an adverse affect in other Sprint formats, e.g. remote Sprints, as people have to engage over technology and aren’t in the room to be engaged in-person (now we’re not saying Design Sprints that aren’t in-person don’t work because they certainly can, find out how to organise remote design sprints without distractions in our post here).

The Solution

Having physical indicators of time remaining for tasks is key here, as if you have timers and clocks in the environment it will create a sense of urgency to tackle tasks quicker. That can often be enough to keep phones in their pockets.

At PixelTree, we use a no phone policy (minus in the breaks and at the lightning demo stage on day 2) to prevent people being tempted and to set an out of office to prevent persistent emails.

One core thing you should implement to minimise distractions though is to create breaks at regularly scheduled intervals. If you allow your team to know that a break is coming at x time, they can put all their effort in knowing they can relax a bit later on. It also allows the team to re-charge their batteries as a Sprint itself can require a lot of focus.

Sprint Day 2:

Not choosing the right problem to solve

The Problem

The book Sprint outlines this as arguably the biggest reason behind design sprint failure, and for good reason. If you choose to the wrong problem on day 2, you will be left creating solutions, developing a prototype, and conduct testing on something that isn’t make-or-break or may be even as important as something else.

The big issue here is opportunity cost. You’ve put your time into ‘a’ when it could have been on ‘b’, and arguably your team of experts will probably not thank you for using their time this way. The best thing to do is have ‘The Decider’ not only be considerate and analytical, but also give them ample time and space to make the big decision.

The Solution

By the time you have generated the challenges your new product, feature or experience faces and placed them on your journey map, you should be able to see a clear outlier. The most important, make-or-break risk you need to answer.

As a Sprint is about testing big ideas fast, you should focus on the riskiest question you need answering. That way you can end your week long Sprint with priceless insights to takeaway.

Not listening to The Decider (or each other!)

The Problem

This is a big one. Within a hierarchical team, the person selected as ‘The Decider’ would ideally be someone with significant power (e.g. the CEO) or someone who has been appointed with the power to make on the project. But what if the expert team don’t agree with (or respect the decision of) ‘The Decider’? What then?

This would likely result in a longer 1st and 2nd day, forcing the team through various back-and-forth, not only creating uncomfortable conflict, but likely weakening the confidence of ‘The Decider’.

The Solution

As mentioned, you could make the decision-maker someone very senior and well respected which by default, may mean less descension when it comes to making the big calls. For those appointed as ‘The Decider’ they should clearly presented as the decision-maker by upper management and have their opinions respected. In our experience, if all ideas are fleshed out and well thought out discussion on points has been made, team members should all be pointing in one direction.

Rushing or dragging

The Problem

If there’s one thing the movie Whiplash (aside from J K Simmons in another life being the teacher from hell), is that you need to recognise when you’re rushing or dragging. In the Sprint context, we’re talking about moving too fast or too slow to the detriment of the process.

Out of the two, it’s arguably worst to be rushing in this sense, leading to unexplored ideas, an increased probability of incorrect user journeys, or limited insights from the experts on the challenges they face. This means the Design Sprint can end in failure very early in the process. This is while dragging could be characterised as being too slow, bringing the Sprint down to a walk and closing the window on getting work done in a week.

The Solution

Structuring the day is key here. With the Sprint framework, you can create a layout of how the day will proceed and have your Facilitator make sure you stay on track. This can mean extending problem-solving or ideation time to a fixed time to prevent going too fast.

What if it’s not being too fast that is the problem? For those slowing down, using a timer for each section can help motivate action and get the team moving. What the facilitator should note though is that the day structure doesn’t need to be a hard rule. You can give more time if you’re on the edge of a breakthrough and rigid time structures shouldn’t hold back your best ideas. A balance is needed.

Sprint Day 3:

Imbalanced voting for solutions or bias

The Problem

You’ve identified your problems, and you’ve created a whole host of solutions. What now? More voting, but this time, on what your prototyped solution will look and operate like.

What might be noticeable at this stage is strategic voting. People are voting a specific way due to their working relationships with others, how it will help their department in particular, or just because one persons solution has significant authority and they’d like to conform. This can lead to skewed voting that’s not focused on the customer.

The Solution

Anonymous voting is a good option for preventing bias in voting. If each expert can’t see what the other has voted on, they can’t copy another’s behaviour. They can only focus on what they want most.

Another solution to this problem is to continually reinforce individual thinking. Promoting divergent thinking at the start can help when formulating unique ideas and also reduce voting based on group dynamics as they’ll feel confident to put their view forward.

Storyboarding something too large in scope

The Problem

Once the team have decided on the solution to go with, it’s time to storyboard out how they envision the feature/app/website working to solve the problem. At this stage, we decide on the screens that need to be part of our prototype.

Here’s the challenge, how many screens are too many? It’s very easy to over create screens, create a lot of fluffy pages that don’t need to be there, or create something so complex that it can’t be achieved in one day of prototyping. This can upset the flow going into the final days of the Sprint and possibly push the Sprint over its intended week.

The Solution

Keeping expectations in check is the name of the game. If you’re thinking of prototyping every single page, you’ll need more than a week! The Facilitator should remind the team to stay focused on the screens that are essential to testing your concept. E.g. If I’m testing a new checkout I may need to have a shopping item page, basket, personal/delivery/payment details, apply coupon screen etc. as a minimum.

Anything outside of being essential should remain on the cutting room floor to save your design team time the next day.

Sprint Day 4:

Lack of prototyping preparation

The Problem

Because Sprints are pressurised to deliver ideas and solutions as soon as possible, losing time at different stages can add up quickly and disrupt planned stages like user testing. This can happen at any stage in the process, but one of these times can be at the prototyping phase.

Once the ideas and solutions are handed off to the designers and engineers, it’s up to them to deliver on the groups vision and develop a working prototype to be used in the testing phase.

If assets are missing e.g. colours/imagery/fonts or it’s overly complex to create as result of an badly defined scope, designs can drag on or be delayed, missing intended deadlines.

The Solution

Prepare in advance. That’s the main takeaway! Ahead of conducting a Sprint, you should make your team aware that you’ll require time on the Thursday for prototype building. If they are missing specific assets or need access to specialised software, make sure they have these before the week begins so they can hit the ground running.

For the sake of translating the findings and vision from the Sprint team, a member of the design team is HIGHLY recommended to be part of the Sprint to help direct the designers on the day (see day 1, selecting the right team).

Not using the right tools

The Problem

For companies with established design teams, this area shouldn’t be a problem. You have the internal expertise to identify what tools you need to make an interactive prototype. But for smaller companies where there’s a lot of job overlap or new enterprises, you can get to this stage and realise you may not know the tools to use for the task.

A lack of familiarity with the tools can mean progress can slow due to unfamiliarity or even a lack of confidence to start building.

The Solution

In terms of solutions we love for prototyping, we always recommend tools like Figma and Adobe XD, though if you’re conscious of cost, we’d suggest Figma for their free tier. If you doing the designing yourself from scratch, familiarise yourself with how the software operates. Check out beginner YouTube tutorials on everything from dedicated button design videos, to full-on masterclasses. Practice will make the real thing so much easier.

If you feel prototype building might be a bit out of your wheelhouse, hiring a designer or a design team can be equally useful. By handing your concepts over with a set timeframe, the designer should be able to bring your solution to life. Please be aware though that you will need to provide a detailed brief and context to what you’re trying to achieve. In the best case scenario, you can hire out their time and have whoever your lead of design is to collaborate with them for the day to make sure they’re hitting the brief.

Day 5:

Not getting the right users in for testing

The Problem

The purpose of running a Design Sprint is to test a concept and validate a solution with real data, defying the traditionally slow design process and returning competitive advantage to the company. The testing stage presents a new set of challenges though, and it starts off with who’s testing. Who are your target audience and how do you get them involved?

Without you target audience or end user at the other end of your prototype testing, you’re collecting untargeted and possibly irrelevant data in return for your hard work earlier in the week.

The Solution

Through knowing your own companies stakeholders and the mapping stage on day 1, you will already be familiar with who you need to test this prototype on. Whether it be after narrowing down your target on day 1 or day 2, it should be apparent who you’ll be targeting before hand e.g. this app is being used by audio technicians so we need audio technicians, and you can start recruiting early.

Sourcing this audience is also more straight forward than ever with the advances in video calls and screen recording. By contacting existing users, inviting users within your social networks/in social groups, interviewing staff (if an in-company experience) or recruiting those who fit your criteria through sites like UserTesting, you can be assured that your audience is out there.

If working with a third party company to assist you with the Sprint, they should be able to recruit and organise user testing based on your mapping decision and data you’ve provided ahead of time. By informing the team early of your requirements, they should be able to recruit a sample of your audience in good time.

Failure to plan your Design Sprint’s testing phase

The Problem

On day 5 of a Sprint, you should be ready to collect feedback on your prototype and on your hypotheses. Is your new onboarding process easier to understand than the last? Can users see your up-selling options more clearly?

This is where you can trip at the last hurdle and result in Design Sprint failure late in the game. The concerns you have to tackle here are:

• Creating questions that deliver meaningful insights
• Knowing how you will conduct tests (e.g. are they testing this one journey path? Are you conducting A/B Tests or Multi-Variates)
• Establishing how you will collect data (e.g. you may interview the users, but should you consider recording their screens to assess user journeys too?)

The Solution

Time heals all and in this case can remedy many of these issues. For the line of questioning, set time aside on day 4 (while the design team are prototyping) to develop questions that can either validate or invalidate your chosen solution. This could centre around how usable the process is, is it easy to navigate, can you achieve a desired goal easy enough. All of these details can influence where you take your design next. Make sure to pair this with open ended questions to get fresh unprompted insights that you may not have considered.

In most Design Sprints, you will often create a single prototype so the opportunity for A/B or multivariate testing is limited. However, if you’ve chosen multiple short solutions, it’s possible to conduct more robust testing methods on other variations, just factor that into your line of questioning and the timing you attribute to each tester.

Reaching the data recording stage, you can adopt a few different methods or even pair them together. We love user interviews and screensharing to show a live demonstration of how users interact with an application or experience as it gives real time insights and shows behaviours you may not see in a questionnaire. But don’t rule out focus groups, in-person interviews and other qualitative methods which can be very effective in validating your solution.

Looking to avoid Design Sprint failure?

The team at PixelTree are here to help! We’ve run Design Sprints to develop new features, ideas and apps for clients large and small. Find out more about how we run our Sprints on our Design Sprints page.