How we do design sprints – common problems and tips part 4

Plan well because then you can throw away the day’s schedule and adapt to your team’s needs

In this series of blog posts, we’ve taken an in-depth look at design sprints and how we can run them effectively in a remote work environment. In this final post I’d like to talk about some of the problems you might encounter and tips for overcoming them.

I’m struggling to get time with people as they can’t commit to 5 days full time

Be upfront about what you need from people. If you can tell them a week or 2 in advance it’s usually a lot easier to get their time. Let them know there’ll be an hour either side of the sprint day to catch up with their day job, and that if they need to answer a call or reply to an email during the sprint, that’s fine.

Some stakeholders just won’t be able to commit as much time as you’d like or need. In these instances make use of cameo sessions where people can drop in, get context, and help influence the team’s direction. Cameo sessions often need to be booked in advance, and can become immovable blocks in your otherwise agile working. Do what you can to fit your work around the sessions and prepare so you get the most out of them.

What do we do at the end of the design sprint?

This is a really important question and something that often doesn’t get enough attention. At the end of the design sprint, we’ll hopefully have validated our idea and know that it’s something we want to take forward. We’ll also have a load of learning that’s inside the heads of the team.

Ideally you’ll be running a sprint as part of a phase of development so you’ll have time to create some project outputs that document what you’ve learned. If not, then I’d recommend pushing for a few extra days after the sprint to write down all this knowledge and document the outputs.

It’s useful to include a video of the prototype’s user journey, along with some narration or a description of what’s happening. If you used a virtual whiteboard then you should be able to download the board to show what you did throughout the week and the reasons behind your decisions.

You may find it useful to cover some more in-depth user research and design work in separate documents so that if people choose, they can find out more.

Remember to recommend some next steps so the team have a way to progress.

This is great but vanilla design sprints are not quite right for me

I mentioned previously that you can adapt sprints and change activities to better suit the team you’re working with. I’d encourage you to switch things up and experiment. Just remember to set aside some time after the sprint has finished to reflect on what you did, what worked well, and what could be improved.

We seem to be spending a lot of time on the prototypes and sketches/these stages feel rushed

When we create things ourselves, we naturally attach more value to them and this can make it hard to look at our creations objectively. Prototypes, sketches, and so on are all disposable once we’ve learned what we can from them. Having this level of detachment is something that improves with experience but, at least for me, never goes away.

Be mindful of this, tell someone (ideally a delivery lead) to give the team a gentle nudge if they feel things are slowing down because people are getting too attached.

We struggle to choose what to prototype

If in doubt, take big risks as they could have a big reward. There’s little value at this stage of testing small improvements that you would probably make anyway. Likewise, if you can imagine the shape of something, or you know how a team could make something, don’t prototype that.

Remember that early on you set a goal, identified users, and mapped a journey. These should all help you make a decision. If you’re still struggling then find a friend of the project to sound things out with. Ideally someone who has experience with design sprints and who’s far enough removed to provide objective feedback.

If something’s missing, people will let you know

Sometimes it’s best not to show something. This can sound counterintuitive but if someone shows you a feature of a product, something desirable but not necessarily required or essential, you’ll likely say it’s useful. On the flip side, if something important is missing from a product you’ll definitely point it out.

Ask the experts takes too long/we don’t get enough out of it

There are things you can do to move the conversation along:

We pivoted and now feel like we’ve dropped the ball

Two of the hardest things to get used to in design are being okay with the possibility of failure and understanding that you make the best decisions you can with the information you have at the time.

Sometimes you’ll learn something that means your idea, or the thing you want to test, isn’t viable. This doesn’t mean you’ve failed. Sometimes your hypothesis will be validated, other times not. Either way you’ve learned something and can make a better decision as a result.

When you have to pivot and wonder how you didn’t see that coming earlier on, remember no-one in the team was wrong. You’ve learned something that will benefit you in future.

People are struggling but not feeding back to me

Sometimes people will struggle with aspects of a design sprint. The most important thing you can do is provide multiple ways for the team to seek help. Different people need help in different ways.

Make sure that every day you have time to reflect on what went well and what can be improved. In one end of day retrospective, for example, a member of the team explained that they had struggled with lots of group video calls and it made it hard for them to think deeply.

This meant I could change the next day’s activities to build in more time to work asynchronously. The second day was much easier and allowed us to find a good cadence to how we spent our time.

Set expectations and be clear about what you’re doing to overcome problems

If you’ve never run a design sprint before, I hope this will inspire you to give it a go. 

You can find a copy of our “dxw design sprint in a box” on Miro. Alternatively try the vanilla Google Ventures version of the sprint which is the most widely adopted way of doing things and probably the one most of your peers will have experience with.

Once you’ve run a design sprint take some time with the team and by yourself to reflect on how it went. Keep what works for you and throw away the rest, there are lots of different activities that you can do which will get you a similar result.

Good luck!