How to sabotage a Design Sprint

Let’s set the scene. The executives at EvilMediCorp have raised the prices on some medicine I need, and now I have made it my life’s mission to waste as much of their time as I can in revenge. Luckily, they’ve just hired me to help them run a design sprint for their new medical advice chatbot, and I am going to use all my experience to make sure that the sprint is a mess, from start to finish. You can use this story to seek design sprint based vengeance in your life, or just use it as a ‘things not to do’ list. Dealer’s choice.

Day 1: Choose the wrong goal

If I could only do one thing to achieve my goal, it would be this: I would hurry them through Day 1 of the sprint, and make sure they choose a vague sprint question that is either too ambitious or too limiting.

Choosing the wrong question is the easiest way to undermine the whole sprint on day 1. For example, compare these potential sprint questions:

1. How can we improve our chatbot that advises people who buy our medicine?
2. What problems are users having with our chatbot right now?
3. How can we communicate the side effects of our medicine to our users?
4. What are the most common questions that our medicine buyers are searching for and how can we best deliver it to them?

By steering them to path A, I’ve made the sprint significantly harder than it needs to be, and put the cart in front of the horse before setting out on the journey.

Immediately after they choose that kind of sprint question, they’d get bogged down into a long team discussion of many different theoretical problems they imagine the users to have. Next, we’d waste more time arguing which of these imagined problems is the most important to solve. Glorious.

If I carefully avoid timeboxing the discussions and let the alpha executive be aggressive with his/her ideas, I can easily waste most of their day and ruin their mood right at the start.

I’d keep them away from Paths B,C and D. All three are user oriented, focused on specific aspects of the service. D is the most open ended, and would work if they’re unsure if the chatbot is the best way to do this. C is very focused, and would be the best way forward if they have to solve that specific problem. B is more of a research sprint question, and more suited to a team of researchers than a design sprint. Designers and developers are expensive. Only get them if you need them.

Get off on the wrong foot

Most importantly, it’s immediately obvious in all three paths what the next steps are. In the following days we’d benchmark the competition, interview different user types about their positive and negative experiences with the bot, understand what they’re looking for and then test which is the best way to satisfy that need and save some lives.

But we’re not saving lives today. We’re here to make some executives angry.

As the final knife in the wound, I would avoid asking them to define any metrics for success or what kind of tangible numbers they would want to see in a successful product. I’d also avoid drawing clear user journeys, because then everyone has a different picture of the service in their heads, which is a time bomb that blows up a bit later in the sprint.

Day 2: Benchmarking for actual dummies

Ruining day 2 of the sprint is very easy and can be done in three simple steps.

Step 1: Encourage limited or no benchmarking of competing solutions and do not find examples from other industries. This ensures that all ideas the executives have are from the same closed box they walked in with. This helps you start from square one, instead of taking advantage of the blood and sweat the competitors put in.

Step 2: Don’t give them solo ideation time. Solo ideation helps the quieter members of the team have time to get their ideas on paper and communicate them, and also helps the whole team develop their ideas a bit before verbalising them or getting criticism on them too early.

Step 3: Get them to criticise each other’s ideas unproductively. By ‘forgetting’ the facilitation tricks of the sprint, I predict that I could spark multiple verbal fistfights and lifelong grudges within the first 10 minutes of idea sharing.

Day 3: Make the UI Designer’s life hell 

My strategy for this is to drown the poor designer in unnecessary details. I’m a UI and service designer myself, and the most valuable lesson for me was that I’m not designing an MVP during the sprint. I am supposed to be designing a prototype, one that is laser-focused on answering the critical questions of the sprint.

The difference is crucial. The prototype does not need to be visually pleasing, or match the branding completely. You don’t need to waste time making a detailed settings screen or splash screen if it’s never going to be the point of the UX test. Speaking of, before you draw anything, you should decide what you’re actually testing, and what screens and flows you need to present to the user.

Instead, it’s best use the time to design as many alternative solutions to the same problem as possible. This is because test users do not know what they want, but they are very good at choosing a preference out different options.

But for this destructo-sprint, I’d forget that, and waste time making high fidelity prototypes of the bot’s UI, instead of tweaking the onboarding or copy text for clarity. Instead of focusing on the screens and user flows that will be tested, I’d focus on what looks good on Dribbble and Behance and Powerpoints.

If all goes well, I can successfully ruin day 4 at the same time. For best results, I would completely ignore the suggestions of the domain experts and actual day-to-day workers in the company, and just prototype the ideas of the loudest executive in the room.

Day 4: Sabotage the UX testing

If I can’t convince them to ditch the user tests altogether, there’s a few ways to make UX testing unproductive. The best way is to skip making a proper script and testing plan ahead of the test, and not decide what it is I’m testing.

Then the test can be just me dumping the prototype into the user’s hands with a ‘what do you think?’ instead of focused questions. The best (worst?) result here would be an unhelpful ‘that’s nice’, because they have no idea what I’m asking them about.

Another golden strategy is to drown the user in a bunch of unnecessarily complicated user flows, with tons and tons or irrelevant screens, so they’re not sure what they should focus on, and spend their time talking about the wrong things, like the color of the sidebar on the settings screen.

As a bonus irritant, I would forget to switch on the live stream of the UX tests to the clients. This way, the executives rely on whatever I tell them the users said, instead of seeing it for themselves. A direct view of the user tests can help clients really understand their users and their needs. But we don’t want that here do we?

If I’m feeling extra cruel, I’d pick the most senior executive and bring him into the testing room with me to intimidate the users.

Day 5: Wrap up the useless results in a terrible handover

At this point, I have successfully trapped a room full of important executives and employees of EvilMediCorp in a room, with no tangible gain for almost 5 days. How can I turn that into months of suffering for them?

Let them leave with no reflection on the sprint and test results, and especially avoid making any sort of scoped feature list and roadmap for further development. IF I can get them to avoid these things, the developers will get a messy pile of half-formed thoughts and junk UX test results to bake a full fledged product from.

I’ve also hopefully ensured that the ideas are all useless ‘moonshots’, because I didn’t include developers and domain experts during the sprint, so the results are completely unconnected to reality or feasible development.

All the UI I designed is copied directly from Dribbble, so it’s very pretty but completely ignores all guidelines for web, iOS, and Android apps and is confusing as hell to actually use.

Now all I need to do is cash my hefty paycheck for the sprint, and wait for the inevitable collapse of EvilMediCorp’s product.

Bonus trick: Neglect the pre research

If the executives really, really annoyed me, I’d unleash the bonus strategy: skip all pre research before the sprint. The secret is, the design sprint team are usually not domain experts in the services they help design. So they lack a lot of specialist knowledge, including some core basics. Pre research before the sprint is how we cover that gap.

For example before a sprint for an investment platform, we could research the world of investment in startups, what goes into making a deal and different types of investors with a mix of user interviews and secondary research.

By skipping this, we can really ensure that half the time in the actual sprint is spent asking basic questions like ‘what does OEMC mean?’ and ‘when does the patient actually take the medicine anyway?’

The good news is that you now have all the intel you need to ruin any design sprint you come across. The bad news is, you also have a lot of tips you can use to run a truly excellent design sprint, too. As with all things in life, the choice is yours.