Design sprints and design studios — choose your weapon

Two useful tools in a product designer’s toolbelt — design sprints and design studios. They might sound similar, but they’re actually best used to achieve different goals. Let’s unpack that a little, starting with the mighty design sprint.

Chances are you’ve heard of design sprints, or even ran a few yourself. This tool was added to the product designer’s toolbelt just a few years ago but quickly became hugely popular, mainly thanks to the Sprint book by Jake Knapp.

The design sprint is a really appealing workshop format that condenses the “double diamond” human-centered design process into just a few action-packed days. During those days, it guides the team through multiple stages, from problem definition through to solution ideation, and even throws in some lean user testing at the end to make it a complete package. The truth is, design is messy. And design sprints make the process appear more organized. Everyone likes that, naturally.

Design sprints are most impactful when it’s not just designers participating, so I’ll keep referring to them simply as “sprints” from now on. They’re meant to be done with a multidisciplinary team, since the discussions naturally touch on product strategy, business, sales, and marketing topics too.

Sprints have become so popular that I’ve seen people conflating a sprint with the discovery phase itself. Careful here though — sprints won’t really help you address one of the four product management risks: the value risk. For that, you still need good ol’ market research — an understanding of your segment’s needs, addressable market size, an assessment of customers’ propensity to pay, and value testing methods (ideally quantitative). Sprints are merely one of the product discovery tools. It’s also worth remembering that while sprints are great for arriving at the right ideas, getting the ideas right still needs to happen afterward.

Various sprint flavors

Many sprint variations have cropped up over the years. For example, the 4-day condensed sprint 2.0, which I’ve befriended and used recently at Productboard. There’s even a brand design sprint. I also know of companies running 3-day, 2-day, and even single-day sprints, simply by cherry-picking a subset of the standard activities.

That said, it’s worth remembering that every time this humble process gets condensed further, we compromise on our ability to address the aforementioned “four risks” fully, whether it’s technical feasibility, business viability, or usability risk. So watch out when shortening sprints, and throw other discovery methods into the mix before you’re confident it’s time to transition into the delivery phase.

For now, let’s stick with sprints to see what they’re best used for, before comparing them with design studios.

When to sprint — and when not to

There are many situations where a sprint is the right tool for you. For example:

• To gain momentum, energize the team, and get to semi-decent, partially validated ideas quickly
• To align the team on the overall goal and problem to be solved
• To explore a range of solutions from different perspectives (thanks to the multidisciplinary group that participates)
• To evangelize the strategic nature of product design, which starts with a deep understanding of the user and business problem to be solved. This is especially useful in organizations where “design” is seen as something to add at the end to make it pretty.

Sometimes, however, a sprint is not the best tool to use:

• When the problem is too small or trivial (investing in a full-blown sprint won’t pay off)
• When the problem is too large or complex and/or can’t be meaningfully prototyped in a day
• When you don’t understand your users and their needs and goals well enough yet
• When your value proposition is unclear. In this case, you’ve got a much bigger fish to fry. There are fundamental questions to answer before it makes sense to sprint
• When you need product specifications that could go into delivery right after. Keep in mind that you move fast during a sprint, so many decisions are skipped or fast-tracked without sufficient consideration
• When you need to validate that there would be enough demand for your product idea — as mentioned before when talking about value validation

Running sprints remotely

Collaborative whiteboard from one of our remote design sprints

Most of us switched to remote work last year and had to run sprints with distributed teams, using screen-sharing and online whiteboarding tools. We ran our first remote sprint back in May 2020 to kick-off the discovery for a powerful dynamic segmentation functionality. We learned quickly that remote sprints are not only doable but in some respects even better than traditional co-located workshops. Here are some reasons why:

• Working with virtual stickies is faster and easier. And it’s more environmentally friendly too — it produces less waste
• Reviewing sketched ideas is easier, even in a larger group (no big huddle by the wall)
• Cutting and pasting parts of sketches to create a storyboard. I’ve not even tried this while working with pen and paper sketches, but it works a treat in digital form
• Outputs are easier to store. In the past, I literally kept rolls of craft paper plastered with stickies and sketches by my desk
• You can walk others through the outcomes easier, e.g. by narrating a Loom video over your online whiteboard

It’s fair to say there are some challenges to remote sprints, too. For example, it’s much harder to keep the group focused and energized, and also to build rapport if participants haven’t met before. But fret not, this can be mitigated. When working remotely, some activities will be quicker, while others will naturally take longer. It’s also useful to plan longer breaks.

You can find lots of tips online —but let me save you a few clicks, look for example here and here. There are also templates for various online collaboration tools. Kudos to the always-helpful design community! 💪

What about design studios?

Now let’s contrast sprints with another super useful tool in your arsenal. Before sprints were all the rage, we were going crazy about the Design Studio Method. Yes, this was back in the day — I’m talking 2010 or so.

The Design Studio Method is traditionally used in art schools and industrial design practice to generate ideas, critique them, and iterate collaboratively. And guess what — it’s already baked into a typical sprint. It’s just more condensed there. So sometimes, you might choose to run a design studio on its own and really do a much deeper critique, and more importantly, dial up the iterative cycles and idea refinement.

I would typically choose to run just a half-day design studio if:

• The problem is already pretty well understood and defined, and we need to visualize multiple solutions — whether they’re high-level conceptual ideas, new features, or detailed UI patterns
• We want to explore the solution space extensively, visualize many alternatives, and have a more rigorous process for shortlisting the most promising ones
• We’re after a more refined interaction and UI design solution that might almost be ready for delivery at the end of it. In that case, I’d invite multiple designers, and instead of pen and paper sketches, I’d work in digital right away

The traditional sprint doesn’t allow for much iteration. It’s biased towards fast decision-making and selection of a best-bet solution that can then be tested with users. In a design studio, on the other hand, we like to iterate a lot, mix and match ideas, and refine the solution’s details collaboratively.

Sometimes I even call them “design jams”, to emphasize their collaborative nature. It’s a safe space where we try things out, build on each others’ ideas, borrow, combine, tweak, tinker, and explore — very much like in a jazz music jam session.

I ran such design jams successfully with my previous team at Trainline to create vision artifacts. We did something similar with Petur at Productboard recently to explore the application of our new brand identity into product. The beauty of it is that after a few iterations, you tend to end up with something of very high quality that no single designer could have produced on their own.

So, which weapon to choose?

It really depends on where you are in the process and your objectives. Both tools have their strengths and are suitable for different challenges.

In a nutshell, if you want to kick things off with a bang, bring the team together, make a bet, and validate a new idea quickly, choose a sprint. But if you have a pretty good idea of what the problem is and want to visualize many solutions while building upon each other’s ideas collaboratively, choose a design studio.

So next time someone suggests running a design sprint, remember that there are more tricks up your sleeve. Not all design problems are sprint-shaped.