How to Run an Agile One-Day Design Sprint for Product Teams

Design sprints are intensive, multi‑role workshops traditionally lasting five days, but they can be flexibly executed in shorter formats. This article shares how we ran a 10‑hour, agile‑style design sprint for a marketing‑tool platform, detailing preparation, execution, and post‑workshop documentation.

1. Pre‑Workshop Preparation

Even for a one‑day workshop, success depends on thorough preparation: defining participants, limiting the group to 6‑8 people, arranging the venue, preparing materials, and setting clear goals and agenda.

Goal definition : Identify the problem to solve. Our ultimate goal was to create an internal marketing‑tool product, broken down into four sub‑problems to address during the sprint.

Diverse roles and clear responsibilities : Include research, product, and design leads, keeping the team size manageable to maintain focus.

We selected roles based on the "double‑diamond" model, assigning tasks such as facilitation, note‑taking, and idea synthesis to ensure each participant contributed effectively.

User insight : Researchers prepared a visual user‑experience journey map to surface key pain points before the workshop.

Creating a sense of ceremony : Invitation emails, journey‑map walls, and a comfortable venue help participants immerse themselves and adopt new roles.

2. Workshop Execution

The workshop began after all preparations were in place.

10:00‑12:00 Input

We introduced the rules to keep brainstorming focused and productive.

Postpone judgment : Avoid evaluating ideas during generation.

Bold ideas : Encourage wild, abundant suggestions.

Yes, and : Build on others' ideas.

Quantity over quality : Generate many solutions before assessing feasibility.

Visualize ideas : Record thoughts on paper from a neutral product perspective.

Researchers presented a user‑experience journey map, highlighting core users, pain points, and prioritized scenarios, which participants then voted on.

13:00‑15:00 Diverge

Using colored sticky notes, participants recorded diverse solution ideas, later grouped and discussed. Controversial topics were placed in a "parking lot" for later investigation.

15:00‑16:30 Converge

Ideas were clustered, filtered, and evaluated using a customized C‑Box model that considers necessity, feasibility, and existing system capabilities.

Selected capabilities were combined into an initial product concept.

16:30‑20:00 Build

We defined the primary problem, prioritized scenarios, and created low‑fidelity wireframes to visualize the product framework for subsequent testing.

3. Documentation

After the workshop, all sticky notes, whiteboard sketches, and meeting notes were photographed, digitized (Word, Axure, Photoshop), and stored in a shared space for future reference.

4. Final Thoughts

This agile design sprint enabled cross‑functional teammates to co‑create solutions, deepening mutual understanding of workflows and user needs. The resulting concepts exceeded expectations, and we hope this methodology helps others tackle similar challenges.

*Some images have been blurred because the product is not yet launched.