Every mistake that could make your Design Sprint fail

This article covers 14 areas that go wrong during workshops. We made a few of these mistakes, and we barely avoided some. In some cases, sceptical participants warned us about things that can go wrong.

Only a handful are speculative. Having such tangible examples, and as many as 14 of them, you can do two things.

You can use this article to talk yourself and others out of a Design Sprint. I mean, more than a dozen fairly common mistakes in a process that claims to de-risk projects? Sounds risky to me!

Or you can use these to prepare yourself for the Design Sprint. A participant that can sense when things could go wrong is the most valuable thing a facilitator can ask for. You can be that person. Let’s find out how.

Getting hung up on “trust the process”

“Trust the process” is the cornerstone of the Design Sprint. You can’t make it without that mindset. But this doesn’t mean the team has to be in the dark about what happens and why.

This is a mistake that we’ve made for the first few workshops. I wouldn’t say it came back to bite us – but we could’ve done better with a different approach.

We were oblivious to it until one decision maker pointed out that the team felt lost. The fast-paced workshops discourage people from raising concerns, so nobody spoke up. We didn’t pick up on it either. Shame on us.

Once we introduced a short session explaining (almost) every exercise in advance, the workshops became much smoother. We had fewer questions and confused faces.

Some facilitators are against such introductions, claiming they introduce bias. We get that, and it was part of the reason we didn’t see the issue. With each question and complaint, we assumed the problem was with our explanation of specific exercises. In reality, the issue was a lack of context. Problem solved.

If you’d like us to talk about how we introduce the Design Sprint to new teams now, let us know on Twitter.

Not trusting the process

You saw that coming, didn’t you? This phrase is the cornerstone of workshops, as mentioned. Once you know enough about the exercises, try not to question them. It will be easier with a skilled facilitator, but your contribution is vital.

Take notes when asked to. Don’t worry if it’s silly, getting these things out of the way is part of the process.

Cut the discussion short when asked to. And, especially in remote workshops, make sure all your other devices and notifications are off. It hurts your output, and trust me – others can see when you’re distracted. This can quickly influence the entire team.

Solving a problem that is too broad

You can reach your financial goals in so many ways. That’s not a problem the Design Sprint can solve. You’d learn this the hard way during one of the exercises which maps the user journey through your business.

Can you imagine what it looks like with such a broad problem? The map starts with a list of actors, or user personas. It’s usually a couple, maybe a few actors. What would it look like for a broad problem?

You can improve financials by raising capital with investors, making budget cuts, hiring for sales, marketing or the product department, running user tests or focus groups… The list goes on and on.

This would create dozens of users, all with unique journeys and the map would look like this meme:

If you’re struggling to narrow it down, start with something like the 1-hour Lightning Decision Jam.

Solutions that are too obvious

I mentioned how you should trust the process to get the obvious ideas out of the way, and this is why.

Obvious ideas don’t need a 5-day Design Sprint that involves your team for two days of workshops. You can list them all in one meeting, two hours tops.

The structure of these workshops brings the best ideas out of the team. If you’re sticking to the proverbial box, you’re still contributing. But if everyone does it, you’re wasting your time.

There is nothing that you can do wrong during the Design Sprint. Your “impossible” idea is better than playing it safe. Allow yourself to go wild and share as many thoughts as you can – just make sure they’re appropriate!

Prototyping solutions that are not feasible

This is usually the facilitator’s fault for not involving the right people in the workshops, but it helps to be aware when it happens to you as a participant.

Your crazy ideas need to see the light of day during the Design Sprint. They just aren’t the best as the “final” concept.

Bold ideas are useless if you can’t execute them. Most of them are possible, but some will be out of your budget/capabilities/you name it.

When it’s time to narrow down your “winning” solutions, make sure you know if they’re feasible.

Going in with a blank slate

The Design Sprint is an innovation process but it’s not a magic wand. Hell, even in some fantasy stories “magic” doesn’t come from thin air. Just see The Witcher on Netflix!

Likewise, workshops will be a painful process if you’ve never thought about the problem at hand before. Giving it some thought is necessary, even if just to weed out the basic ideas we’ve covered before.

At the very least, talk about it briefly as a team. We do it during individual interviews with the stakeholders, so if your facilitator skips that step, do it behind their back. Mention the things that you’ve tried, what worked, what didn’t.

For more complex problems, we suggest unmoderated user tests and a bit of research. If you go for these, every participant should have access to the data.

And in some cases, you may find out that you’re trying to solve the wrong problem.

Assembling the wrong team

We have another article about how to assemble the A-team for your Design Sprint. But what happens when you don’t?

As mentioned before, a lack of engineers in the workshops means you can end up with a solution that is impossible or way out of budget. This renders the entire process useless.

There are also a few mistakes that lead to bland ideas and introduce bias:

• Not having anyone from a department with a stake in the problem and/or solution
• A “perfect” team but with an imbalanced composition, e.g. three marketers for one person from every other department
• A team that is too small or too big – the general recommendation is 4-8 experts

Decision maker issues

This can be a handful, but let’s focus on the common ones.

First, an indecisive decision maker. Yes, this is a team effort. We even tell the decision maker that they can discuss with a team when making a crucial decision. But this doesn’t mean “giving the team the power to decide”, and that often happens.

Another example of this is decision makers appointing their “seconds”, and on some exercises saying that they can’t decide and John Doe will do it instead. That’s a huge “NOPE”.

Second, the rebel decision maker. It’s rare. We have only encountered one, and with the help of the team, we’ve managed to convert them. But when someone is obsessed with their own ideas, it can be really discouraging for the team.

Finally, the absent decision maker.

“I need to take this call.”

“I just got an urgent email.”

Sure, there are ways to incorporate a decision maker that is in and out of the workshops. But this has to be agreed upfront and planned carefully – and it’s always a compromise. You won’t get the same results as with a fully engaged DM.

Introducing bias

There are a few things that are harder when doing the workshops in person. The first that comes to mind is voting. You can’t avoid people seeing how others are voting – you can look straight at them and copy their votes.

We solve it by highlighting how important it is to go against the grain, and what are the benefits. It’s a bit counter-intuitive when we just warned you against “rebel decision makers”, but it’s a better trait for a team member than for a decision maker.

In any environment, it’s also tricky to discourage “sly” voting. This is usually accompanied by the person saying “well, I would vote on this but I know it has enough votes already so I’ll vote on the other thing”.

It’s not the end of the world, but you should vote irrespective of what others choose. If you have four votes and a two ideas that are equally important, vote twice on each. Don’t go 3+1 just to skew the results.

Prototyping something that can’t be done in a day

…or, making it way too detailed. Design Sprint prototypes should be low-fidelity. They can be as simple as black-and-white wireframes, but making it a bit more approachable can help.

How to avoid large prototypes, you ask?

It will come directly from solving some of the previous issues: having a narrow challenge and including engineers in the workshop team.

Stakeholder expectations play a big role as well. You won’t get a ready-made product from just five days of work and a single day of prototyping. Prepare for a low-fidelity sketch, or a basic prototype if your solution isn’t a digital product.

Recruiting the wrong testers

This one isn’t related to the workshop team, but it’s even more dangerous. Testing is a complex subject and many things can go wrong. Recruiting the wrong audience is the first of them.

We’d go as far as to say that if you can’t get the right testers, it’s better to not test at all. And if you know it way ahead of the workshops, it’s better to just not use the Design Sprint. The goal is to get a prototype validated with the target audience, so going through the process is pointless if you remove the outcome.

Make sure you know the audience way ahead of schedule, secure a budget for user tests and make sure you have access to platforms that can recruit from your target audience.

But fear not – it’s not as hard to find those people as you may think. We even succeeded at finding preclinical cancer model researchers. What a mouthful. 🤯

Common testing mistakes

We’ve said there are many, so let’s go through a few.

1. Asking the wrong questions – don’t ask yes/no questions, and don’t be suggestive in your phrasing.
2. Asking for all answers – you’ll have a list of questions ahead of the tests, and that’s perfect. But don’t look to ask them all. You should be able to answer most of them simply by observing the tester.
3. Giving testers the wrong task – sometimes you’ll need to test the sign up process. You can’t just tell people “browse the website as you would normally do”, and then hurry them through the sign up with just minutes left on the clock. Maybe the fact they didn’t get there organically is a flaw, but it doesn’t have to be.
4. Being the “insider” – as a test facilitator, you should be as impartial as possible. Don’t intimidate people by saying you’ve designed the prototype, and try not to use jargon. You should be as relatable as possible.

A wrong environment for workshops

We’re very strict with this, to the point that we discourage clients from remote workshops. They just don’t compare, but if you can’t get everyone in the same room, it’s a viable alternative.

But what can go wrong if you can meet everyone in-person?

First of all, running out of supplies. You can not run out of paper, sticky notes, sharpies, and the like.

Second, bringing the wrong snacks. We explained how food affects workshop participants, and we’ve had people bring their own food. It hasn’t derailed the process completely, but we’ve seen how it affects their mood. Unless it’s for health reasons, you should always be in control of the snacks. Ideally, you should accommodate those with allergies.

Third, no access to food for lunch. There’s a longer lunch break during both days of workshops and a long drive to get food can damage your schedule. It’s acceptable to arrange catering for those situations. Ideally, do the workshops in areas with plenty of restaurants to choose from.

Finally, avoid distractions. Phone notifications are strictly forbidden, like the forest at Hogwarts. If you’re running workshops at an office, make sure others won’t disturb you. Their “urgent” questions for any of the participants will need to wait.

Messing up the handover of the outcomes

We generally execute on the outcomes of our Design Sprints, but that’s not always the case. It’s possible that you’ll deliver the prototype but someone else will implement it – especially if it’s a physical product.

The Design Sprint framework talks little about this, but you’ll need to have a proper plan for the handover. Consider giving your clients a roadmap, a rough outline of the scope of work, and a summary of the user tests.

Other helpful documents include an impact/effort matrix, highlighting risk, and separating validated facts from assumptions.