How to Run a Design Sprint with an Online Whiteboard

Written by Greg Ives

Creator of Jotboard

A guide to running a 5-day design sprint using an online whiteboard, covering each day of the sprint and how to keep a remote team aligned.

What is a Design Sprint?

A design sprint is a five-day structured process for solving complex product problems, developed by Jake Knapp at Google Ventures. In a single week, a cross-functional team maps a challenge, generates solutions, makes decisions, builds a prototype and tests it with real users — all before writing a line of production code.

The sprint format is powerful because it creates focus. There are no status updates, no drifting scope and no endless debates about what customers want — you find out directly by putting a prototype in front of them on Friday.

An online whiteboard is central to every phase of a design sprint. It is where the team maps problems, sketches solutions, votes on ideas and organizes exercises. For remote or distributed teams, a shared digital whiteboard makes all of this possible without being in the same room.

Day 1: Map

Monday is about building a shared understanding of the problem. The whole sprint team — typically five to seven people from across product, design, engineering and customer-facing roles — gathers to:

• Define the long-term goal: what are you trying to achieve in two years?
• Map the customer journey from start to end of the problem space
• Ask subject-matter experts from across the company to share what they know
• Pick a target: one specific moment on the map that the sprint will focus on

Set up a Jotboard board with a slide for the goal, a slide for the journey map and a slide for “How Might We” notes. During the expert talks, participants add HMW sticky notes whenever they hear a problem or opportunity worth exploring.

Day 2: Sketch

Tuesday focuses on generating solutions. Crucially, this happens individually, not as a group. Research consistently shows that people produce better and more diverse ideas when they work alone before sharing.

Each team member spends the morning reviewing inspiration — competitor products, existing research, analogous solutions from other industries — and the afternoon sketching a detailed solution using a four-step method: notes, ideas, Crazy 8s, and a final solution sketch.

In Jotboard, each person works on their own slide so their sketches stay distinct. Use the drawing tools to sketch wireframe-style flows, and add sticky notes to annotate key decisions and assumptions.

Day 3: Decide

Wednesday is decision day. The team reviews all the solution sketches and decides which one (or which elements) to prototype. The process is designed to be efficient: a “heat map” vote using dot stickers, a structured critique, a final vote and a storyboard.

The storyboard is the most important output of Wednesday. It is a 10–15 panel comic-strip version of the prototype, showing every screen and step the test users will experience on Friday.

Lay the storyboard out across a single wide slide in Jotboard so the whole narrative is visible at once. Use sticky notes to annotate each panel with copy, interactions and open questions.

Day 4: Prototype

Thursday is all about building. The goal is a realistic-looking prototype that can be tested with real users — not a polished product, but something that feels real enough to generate genuine reactions.

The Jotboard board serves as the reference document on Thursday. Keep the storyboard open so the prototype builder can work from it directly. Use a separate slide to track open questions and decisions made as the build progresses.

Day 5: Test

Friday is when you find out if your solution works. Five users come in (or join a video call) and work through the prototype while the team watches and takes notes.

Set up a note-taking slide in Jotboard with columns for each user and rows for each step of the prototype. As observers watch each session, they add sticky notes in real time — patterns emerge quickly as similar notes cluster together.

At the end of the day, review the notes together and summarise what worked, what did not, and what the team would do differently. This becomes the foundation for the next phase of development — or the next sprint.

Running a Remote Design Sprint

Remote design sprints work well when the whole team can commit to video calls for the structured exercises each day. The key differences from in-person sprints are:

• Use breakout rooms for individual working time, with everyone back on a main call for group exercises
• Keep the Jotboard board open on a second screen throughout, so shared artefacts are always visible
• Be stricter about timekeeping — it is easier for remote participants to drift

Get started with Jotboard for free and set up your sprint board in minutes.