How to run a remote design sprint

Design sprint is a new-ish term for something the industry has been doing for over a decade. You put a group of engineers, designers, and product people in a room and tell them not to come out until they have a solution to a specific problem.

Traditional design sprints — the sort popularized by former Google designer Jake Knapp — are held over five days. Each day corresponds to a separate stage in the process: Map, Sketch, Decide, Prototype, and Test.

Think of the sprint process as a double-diamond.

You start at the left on a single point. That’s the customer problem — say, how does a global shipping company improve its WeChat user experience?

During the first two stages (Map and Sketch), you explore a range of solutions. The shipping company could develop an AI-powered chatbot, create an asynchronous communication option, or improve the user interface. By the end of the second stage, you have all these different options available to you. The diamond has expanded, and you’re right in the middle. During the third stage (Decide), you evaluate your ideas and select one to run with. This is the first diamond tapering back to a single point.

The final two stages (Prototype and Test) follow the same structure. As you develop ways to turn your sketches into a real product, the second diamond expands. From there, you choose the best approach and create a prototype to test. This is the diamond tapering back to its final rightmost point.

Until recently, the consensus has been that design sprints are best held in-person because they’re highly energetic processes. Participants buzz around the room, sticking Post-It notes on the walls, sketching ideas on whiteboards, and holding a dozen conversations at once. Trying to do that online would be chaos, right?

Well, not quite.

Design sprints can work when your participants are hundreds or thousands of miles apart — we’ve proved that at Abstract with our fully distributed team.

But to work well, you need to tweak Knapp’s original process. Here’s how you do it.

Setting up design sprints for remote teams

The biggest change we made to the original design sprint is time. Whereas Knapp’s sprint takes place over five days, ours runs for just two.

On day one of our new condensed design sprint, we run through both ideation stages — Map and Sketch — to create a bunch of solutions to our problem. Then, on day two, we analyze those ideas and pick one to run with.

The hardest week of a remote sprint is the week before.

Jason Fund | Design Strategy Lead, IDEO

The remaining two stages — Prototype and Test — aren’t part of the two-day remote design sprint. Instead, our design and engineering teams break off with the final idea to conduct prototyping and user testing asynchronously.‍

Since we’re shrinking the timeframe of the design sprint without omitting any of the original process, time is tight. To give ourselves breathing room, we run a lot of the research before the sprint itself. Product & design independently research the problem, interview customers about their challenges, and prepare detailed notes of their findings. As IDEO’s design strategy lead, Jason Fund, once said: “The hardest week of a remote sprint is the week before.”

The second big change from in-person to remote sprints is technology. Because participants aren’t in the same room, you have to use technology to support their interactions. Two pieces of technology underpin everything:

The first is the virtual whiteboard.

The whiteboard is the beating heart of the design sprint. It’s where you anchor your ideas, arrange your thoughts, and experiment with new concepts. As tools, whiteboards are so effective because they’re flexible — you can scribble in one section, stick Post-It notes on another, sketch out concepts in a third. To recreate this online, we use collaborative whiteboard platform Miro.

Ideas are ephemeral when you’re in-person, but they’re automatically recorded when you work online.

In some ways, virtual whiteboards are actually better than their physical counterparts. Instead of writing “DO NOT ERASE” and trusting others to follow your instructions, virtual whiteboards act as permanent living documents. Ideas are ephemeral when you’re in-person, but they’re automatically recorded when you work online.

The second piece of must-have technology is a video conferencing platform. It’s hard to communicate with someone if you can’t read their facial expressions. Although that applies to remote work in general, it’s especially important in a design sprint where you’re actively collaborating. We use Zoom for its stability, high quality, and ability to easily record calls.

The final tweak teams must make for productive remote collaboration involves behavior. When you’re working in a physical room, it’s easy to stay focused. But when you’re working at home and battling Zoom fatigue, it’s easy to drift off and get distracted. The good news is that you can mitigate distraction and disengagement by setting expectations upfront.

Before you start, the sprint moderator should explicitly ask people not to multitask or, at the very least, to avoid it where possible and practical. If someone puts their phone in a drawer and closes their email tab, it’s much easier to ignore potential distractions and remain focused. Since the power of the sprint comes from collective attention, it’s critical everyone keeps their attention focused.

During the sprint, moderators play an ongoing role in keeping collective energies up and attendees engaged. As with colocated meetings, it’s often the loudest voice that dominates the discussion. During remote sprints, with everyone hidden behind their black mirror, it’s even easier for this to happen and for attendees to fall through the cracks. Whenever a moderator notices someone is beginning to take over, they should move to re-engage others in the discussion, ensuring a diverse input.

Remote sprint day #1: Map and sketch

One of the first design sprints we ran at Abstract was to tackle the problem of design systems. Design systems are an important tool for our customers, so we knew it was important to deliver robust design system features in our product.

In the morning of our first day, our 10-person team launched into the Map stage. We ran through all the same exercises we would have if we were in a room together — Affinity Grouping, Ask the Experts, How Might We, Jobs to be Done, and so on.

As Knapp explains, “The structure allows the team to “boot up” as much information as quickly as possible — while preventing the usual meandering conversations.”

By the afternoon, we had some great ideas to develop in the Sketch phase. We dove into sketching exercises, where people developed our ideas and envisioned how they would work in practice. Some of our team literally sketched out ideas on a piece of paper and uploaded a photo to Miro, while others worked digitally from iPads.

When we logged off for the day, we had a huge range of well-developed ideas.

Remote sprint day #2: Decide

Coming into the second day with a lot of ideas is great — but you can’t run with them all. Prototyping and testing are time- and resource-intensive processes. You need to whittle your ideas down to one solid option.

In the morning, we split into smaller groups and analyzed our options. Knapp has an interesting five-part “Sticky Decision” method for this. You tape all your solution sketches to the wall, vote silently with small dot stickers, debate the options as a group, vote silently again, and then pass off the final choice to your ultimate decision-maker.

It sounds like a roundabout way of narrowing your options — but it works.

In the afternoon, we took the sketches from our winning options and arranged them into a storyboard. The storyboard is a step-by-step plan showing how users will interact with your chosen solution and it forms the skeleton for your subsequent prototype.

And this is where your remote design sprint ends. After two days of intense ideation, analysis, and debate, you have your final storyboard. It’s time to thank everyone for their hard work and log off for some much-needed relaxation.

Asynchronous follow-ups: Prototype and test

After the two-day remote sprint, the design team peels off to run the final two stages asynchronously. The first thing they do is turn your storyboard into a realistic clickable prototype. These prototypes look the part and allow users to interact with them as if they were a real product — but they’re not. They’re just a facade, although some advanced prototypes may include some working code.

Prototyping allows you to test out an idea without going through the hassle of actually developing the full solution.

With a prototype designed, the design team sets up user testing sessions. During these sessions, you release real users onto your prototype. You can test your assumptions and observe how they actually interact with your solution.

Depending on the outcome of your testing, you know if your idea is an effective solution or misguided folly.

Empowering remote design teams

When Knapp published Sprint, his book on design sprints, he was gently dismissive of remote opportunities. “Hopefully the technology for remote sprints is just around the corner,” he wrote, “but it’s not quite here yet.”

Four years later, the tech he alluded to is both widespread and affordable — and remote design sprints are not just feasible, but effective.

We’ve run successful remote design sprints at Abstract with team members scattered across the world — in San Francisco, New York, and Belgium. We’ve seen that geographic differences don’t need to be an impediment to creativity and collaboration. If you think carefully about how you work, you can reap all the benefits of the traditional design sprint — and more.