I spend a lot of time in design sprints. And with 20 years in the industry, I've got a few stories to tell when things haven't gone well.
But design is very rarely a perfect process, and many factors can either make or break a successful sprint, from making sure the right people are there to even running it on a particular day of the week.
Here are some of the most common challenges we've experienced when running sprints for our partners, and some of the methods we use for dealing with challenges when they arise.
Whether you're an agency, studio or in-house team, simply getting started can sometimes be the biggest challenge, particularly if you have stakeholders who are against them.
Our design sprint journey started with an IDEO course which was really collaborative and highly recommended. We also ran internal sprints as side-projects to practice the core steps and put some of our learnings into practice before doing them with clients. It's handy to take lots of pictures throughout your sprints and write them up afterwards, always focusing on the value provided to the client.
At the end of the day, a design sprint is just a collection of workshops, so a UX designer or anyone in product should be equipped to get started in some shape or form. If you break it down to its path and individual parts, it's less scary.
I think we're all experts in all those stages, it's just about bringing it together. So my advice is to give it a go!
Another common challenge I've experienced is that everything doesn't work in a sprint. You still need dedicated time to do things like production or research.
A design sprint can be both physically and mentally draining too, so running back-to-back sprints is not recommended. It's important to take some downtime in between sessions and protect your creative thinking time.
Sprints are a method that you can slot into your overall design programme to help find solutions to particular problems, so reserve them for big problems that need a multi-collaborative push. It's not a replacement of someone just getting down and doing some design.
And you still need to do research, product, brand and content, all that needs to go into it.
With sprints rising in popularity and more clients asking for them, it's common that they need to be turned around and delivered rapidly - something that could set you up in the wrong way.
As a word of caution, don't continue with a flawed plan. Sprints require users to test and lots of research and insights. All things that will impact the quality of the outputs if not prepared correctly.
Remember it's ok to say no and reschedule to give you a vital few weeks to prepare, and it's always good to set up a lead time with a client before doing a sprint.
A badly-run sprint could also create negative PR for you and your team, which nobody wants. So be bold and brave enough to say no when you don't feel it's the right plan.
People in a design sprint can shape and influence the experience, so you must focus on people, purpose and product. If you haven't got those three things all aligned and understand that the right people are doing it for the right reason, you've got all the ingredients for it to go wrong.
Having the wrong people in a room can also kill a sprint. If you have someone who's being pessimistic, you must keep their energy up and be counter positive. Being able to design the people you put into a sprint is also really important. They're not client theatre, everyone needs to be productive. It's ok to let people leave who realise it's not for them and tap someone else in.
Not having a clear goal for a particular challenge is often one of the main causes of an unsuccessful sprint. So just like you would with a workshop, think about the end goal, and then work backwards. You should have your design sprint challenge agreed upfront with the client and everybody knows what they're doing as a statement going in.
It's worth thinking about an engaging way to onboard the team into the insights too. Rather than just doing a series of lightning talks for a morning, you could split up into pairs and write a mini design challenge to extract out things that they think is important and present them back to each other as a way of learning and onboarding into the sprint.
Design your sprint for the insights you need‚ not because you read you have to do certain activities on certain days. Think and plan a sprint like you would a workshop, then work backwards. It's all about adaptation. Everyone says plan plan plan, which is true, but you have to plan to pivot and plan to change.
It's really important to have the right skills in the room as well. If you're going to do a sprint around interaction, it'd be useful to have a front-end developer there. Or if it's really content focused, you may need a content designer in there to stretch what you're thinking and how you might come up with ideas.
Another thing we've learned with larger organisations is that they will often go a lot slower than the design sprint process.
We generally start on a Wednesday as the understand day, Thursday as the diverge day where we collect all our ideas and package that so on Friday the client can share with their peers or stakeholders. You've then got the weekend to let those ideas settle, protecting that creative time and thinking time. Then on Monday, everyone's refreshed, they've got feedback on the ideas and focused on the same thing.
Treat feedback as signals too, you can still evolve and merge ideas that didn't necessarily get voted on by the client for the prototype phase.
Workshop and design sprints are meant to be fun, energising and creative, but with remote-working now commonplace that whole experience has been boxed up onto a screen. So you have to try and think about making it different.
Instead of doing full days, we'll run a sprint across half a day, using shorter exercises and breaks to keep the energy going and spirits up. We use Miro as our go-to tool for remote sprints, hiding frames and locking off future sessions to avoid participants skipping ahead and losing focus.
Taking silence as acceptance is also useful, and setting tasks beforehand to allow participants to get familiar with the software is always beneficial so you're ready to go from day one.
We've now started running hybrid sprints too, with some of us together in the office sketching and clients and other members of the team participating remotely - but even if you only had one remote person, you'd still have to design the sprint to cater for them.
. . .
Want to find out more about our design sprint process and how it could help your organisation create rapid new ideas and bring people together? Get in touch for a chat.
You can also watch the recording of our Product Love talk on the hidden challenges of running a design sprint here.