01 — Design System
Visual identity
The Sprint Toolkit shares the structural bones of the PM Maturity Toolkit but introduces its own palette — purposeful, energetic, and workshop-native. Every deliverable derives color, type, and layout decisions from these tokens.
Primary palette
Neutrals & surfaces
Typography
DM Serif Display
Headlines, module titles, cover display — weight 400
DM Sans — body, labels, UI
Weight 400 (body), 500 (labels), 600 (emphasis)
DM Mono — file names, codes, prompts
Module color assignments
02 — Content Guidelines
Rules every deliverable follows
These principles govern copy, layout, and interaction decisions across all four files. New deliverables must satisfy all of them before they ship.
Sprint-first, theory-second
Every page leads with what practitioners do, not what they should know. Learning comes through working the process, not studying it. Avoid lengthy explanations — put the doing first.
Cross-functional voice
Copy speaks to a mixed audience: PMs, designers, engineers, researchers, and business stakeholders. No jargon that belongs only to one function. Use concrete, role-neutral language that a VP and a UX researcher can both act on.
Structured empathy
Sprint work starts with people, not solutions. Every module should make visible the human problem behind the effort — quotes, personas, friction moments — before any solution framing appears.
Time-aware layout
Design sprint events are intensely time-boxed. All planning, itinerary, and phase views must make time and sequence a first-class visual element — never buried in text.
Decision-grade outputs
Readouts and intake forms must be dense enough to hand to a VP and make a go/no-go call. No vague summaries. Every section drives toward a concrete recommendation or decision.
Consistent navigation
All four files link to each other. A persistent nav or footer allows movement across the toolkit without backtracking. Navigation items use the module's own accent color.
Print and share ready
Readout and intake files must print cleanly. No fixed-position UI, no critical content inside hover states, no interactive-only data. A PDF export of any page should work as a standalone document.
Interactive where it earns it
Interactivity is reserved for things users genuinely need to fill in, expand, calculate, or navigate. Decorative animation is not used. Every interactive element has a clear purpose in the workflow.
03 — Deliverables
Four modules, fully specced
Click any deliverable to expand its full specification, opening prompt, and definition of done. Build in order — each module builds on the one before it.
Goal
Give any first-timer a confident understanding of the Google Design Sprint format, the 2-day in-person variant used here, and what each phase produces — in under 10 minutes of reading.
Audience
Sprint newcomers, skeptical stakeholders, and cross-functional participants who were just invited to an event and want to understand what they're walking into.
Page structure
- Hero — bold statement of what a design sprint is + when to use one vs. not (dark bg, DM Serif Display headline)
- Sprint origin — brief Google Ventures lineage; 5-day → 2-day condensed rationale
- The 5 phases — visual horizontal rail: Understand, Map, Sketch, Prototype, Test. Each phase: icon, name, time label, one-sentence output, and color-coded chip
- The 2-day sprint model — how 5 phases compress into Day 1 (Understand + Map + Align) and Day 2 (Prototype hand-off + Review feedback). Timeline visualization
- Who's in the room — role cards: Facilitator, Decider, SME, Cross-functional Team, Prototype Owner, Researcher. Each card: role, responsibility, and "you're right for this if…" line
- When to sprint — entry criteria summary (links to Module 2 Intake); problems that are too big, too small, or the wrong kind
- What you'll leave with — output artifacts: problem statement, decision map, sketches, prototype, research insights
- Footer CTA — "Ready to propose a sprint? Start the intake →" links to intake.html
Visual signature
A horizontal 5-step phase rail with animated progress fill on scroll — each phase locks in as you reach its corresponding section. Purple accent throughout.
Tone tags
Energizing · Grounded · Practical · No hype · Cross-functional-safe
Definition of done
- 5 phases represented visually with time labels and output descriptors
- 2-day event model clearly distinguished from 5-day original
- Role cards for all 6 participant types
- Entry criteria section with at least 4 trigger scenarios
- Link to Intake form (Module 2) present in hero and footer
- Navigation to all four modules in footer
- Prints clean to PDF with no truncated content
Opening prompt — paste to start this build
I'm building a Design Sprint Toolkit as a standalone HTML module set. The Sprint Plan is in project-plan.html. Let's build deliverable 1: the Learning Module overview page (index.html). This is similar in spirit to our PM Maturity Framework overview page — a rich, single-page HTML file that teaches the Google Design Sprint format adapted to our 2-day in-person model. Use the design system from the Sprint Plan: DM Serif Display for headlines, DM Sans for body, Sprint Purple (#6B5CE7) as primary accent, surface #F5F4F1 background, ink #0E0F11. Include: a dark hero, a 5-phase horizontal rail (Understand/Map/Sketch/Prototype/Test), a 2-day model visualization, role cards for 6 participant types, entry criteria triggers, and a footer CTA linking to intake.html.
Goal
Help a team determine whether their challenge is sprint-worthy, frame the problem clearly, and assemble the right stakeholder structure before committing to an event.
Dependency
index.html must exist — intake links back to the learning module for teams who need context before filling it out.
Form sections
- Section A — Problem framing: Problem title; Problem type (radio: known problem/unknown problem/suspected outcome off-track/failing metric/business pressure); one-paragraph problem narrative; who is most impacted and how
- Section B — Evidence & signals: What data, research, or signals suggest this is real; quantitative metric inputs (current vs. target); qualitative evidence (quotes, complaints, trends)
- Section C — Stakeholder setup: Executive sponsor (name, role, email, decision authority checkbox); Lead SME (name, function, availability); Primary solution team (3-person minimum: names, roles, functions)
- Section D — Sprint scope: Hypothesized outcome; what success looks like in 90 days; what is explicitly out of scope; risk appetite (low/medium/high)
- Section E — Priority & resources: Priority matrix (2×2 visual: Impact vs. Urgency — user places their challenge); budget range selector; timeline flexibility (firm date / flexible / TBD)
- Section F — Entry criteria check: Scored checklist — 8 yes/no criteria; auto-calculates sprint readiness score; threshold for "sprint-eligible" vs. "needs more definition" vs. "not sprint appropriate"
- Submission summary: Compiled brief card ready to copy/print — The Pitch (auto-populated from A + B + D); stakeholder map; readiness score badge; recommended next step (proceed to Event Planning / revisit problem / escalate to leadership)
Interactivity
Progress bar across top (6 sections). Auto-save state in sessionStorage. Priority matrix uses drag-to-place dot. Entry criteria score updates live. Summary card generates dynamically on completion.
Tone tags
Rigorous · Direct · Low-friction · PM-grade · Decision-oriented
Definition of done
- All 6 sections present with required field indicators
- Entry criteria checklist with 8 items and live score
- Priority matrix (2×2 drag-to-place) functional
- Budget and timeline inputs present
- Summary card auto-populates from form entries
- Readiness score shows one of three outcomes with recommended next action
- CTA to Event Hub (Module 3) appears on "sprint-eligible" result
- Print/export of summary card produces clean single-page output
Opening prompt — paste to start this build
I'm building a Design Sprint Toolkit. The Sprint Plan is in project-plan.html and the overview page is in index.html. Let's build deliverable 2: the Sprint Intake Form (intake.html). This is a rich interactive HTML form that helps teams build a case for a design sprint. It has 6 sections: problem framing, evidence and signals, stakeholder setup, sprint scope, priority and resources, and an entry criteria checklist. Design system: DM Serif Display headlines, DM Sans body, Sprint Teal (#0E8C6A) as accent, surface #F5F4F1 background. Include a live entry criteria score, a 2×2 priority matrix, a budget selector, and an auto-generated summary card ("The Pitch") that populates from form entries. Readiness score should output one of three outcomes: sprint-eligible (CTA to event hub), needs more definition, or not sprint appropriate.
Goal
Give the sprint facilitator a single page to manage all event logistics — dates, attendees, hotel recommendations, travel, and the full 2-day itinerary — so nothing falls through the cracks before or during the sprint.
Dependency
intake.html — Sprint title, problem statement, stakeholder list, and team roster pull from the intake submission (or are re-entered here).
Page sections
- Event header: Sprint name, problem statement pull-quote, event dates, city/venue, facilitator name — editable on-page fields
- Calendar block: Visual 5-day calendar window centered on sprint days; Day −2 (travel-in window), Day −1 (team dinner), Day 1 (Sprint Day 1), Day 2 (Sprint Day 2 + prototype hand-off), Day +1 (departure); each day has a status chip and color code
- Attendee registration: Tabular roster with: name, role, function, attendance type (in-person/remote/hybrid), RSVP status, dietary notes, travel needs. Add/remove rows. Tracks confirmed headcount by role type.
- Recommended accommodations: 3 hotel cards per city (placeholder template with: hotel name, distance from venue, price tier, link field, amenities chips). Facilitator notes field per hotel.
- High-level itinerary — Day −1: Afternoon arrival window · Welcome dinner (venue TBD) · Informal team intro · Sprint kickoff pre-brief for facilitator and Decider
- High-level itinerary — Day 1 (Sprint Day 1): 8:30 AM Welcome & norms · 9 AM Understand (expert talks, HMW notes) · 11 AM Map (journey mapping, target moment) · 12:30 PM Lunch · 1:30 PM Sketch (Lightning Demos, 4-step sketch) · 4 PM Align (dot voting, Decider decision) · 4:45 PM Storyboard · 5:30 PM Wrap + prototype brief hand-off
- High-level itinerary — Day 2 (Sprint Day 2): 9 AM Design team prototype session (separate) · 9 AM Sprint team: Icebreaker + open design questions · 10 AM Review prototype draft · 12 PM Lunch · 1 PM Prototype finalized — team preview · 2 PM Research debrief prep · 3 PM Reconnect session: facilitated review of user feedback and insights · 4:30 PM Team retrospective · 5 PM Close + next steps
- Departure logistics: Day +1 departure window, ground transport notes, post-sprint communication plan (when readout will be delivered)
- Materials checklist: Sticky notes, markers, dot voting stickers, printed HMW cards, laptop for remote participants, timer, whiteboard/digital board setup
Visual signature
A vertical timeline rail for the full event arc (Day −1 through Day +1) with color-coded day blocks and time-chips. Sprint Coral as primary accent.
Tone tags
Operational · Clear · Host-grade · Warm but efficient · Zero ambiguity
Definition of done
- 5-day calendar block (Day −2 through Day +1) with status chips
- Attendee roster table with RSVP, role, and travel fields
- 3 hotel card placeholders with all required fields
- Complete time-blocked itinerary for Day 1 and Day 2
- Team dinner and departure logistics sections present
- Materials checklist with all items
- Link to Sprint Readout (Module 4) in footer
- Prints to PDF cleanly — itinerary readable as standalone handout
Opening prompt — paste to start this build
I'm building a Design Sprint Toolkit. The Sprint Plan is in project-plan.html. Let's build deliverable 3: the Sprint Event Hub (event.html). This is a rich logistics and planning page for hosting a 2-day in-person design sprint event. Design system: DM Serif Display headlines, DM Sans body, Sprint Coral (#D85A30) as accent, surface #F5F4F1 background. Include: a 5-day visual calendar (Day −1 through Day +1), an editable attendee roster table with RSVP tracking, 3 hotel card placeholders, and a complete time-blocked itinerary for Day 1 (Understand/Map/Sketch/Align/Storyboard) and Day 2 (Prototype hand-off, design team session, reconnect review, retrospective), plus departure logistics and a materials checklist. The itinerary is the visual centerpiece — use a vertical timeline rail with color-coded time blocks.
Goal
Produce a structured, exec-ready post-sprint document that tells the full story: what problem was brought in (The Pitch), what the team designed and hypothesized (The Concept), and what the research revealed and what to do next (The Recommendation).
Dependency
intake.html provides Part 1 source material. Sprint artifacts and researcher feedback feed Parts 2 and 3. Readout is produced after prototype testing.
Part 1 — The Pitch (from Intake)
- Sprint name and date range
- Problem statement (pulled from intake)
- Problem type label (known/unknown/metric failure/business pressure)
- Key signals and evidence (from intake Section B)
- Stakeholder roster: Sponsor, Decider, SME, Team
- Entry criteria score and sprint readiness badge
- Priority matrix placement (Impact × Urgency quadrant label)
Part 2 — The Concept (from Sprint)
- Sprint hypothesis — "We believe that [solution] will [outcome] for [user] because [rationale]"
- Solution concept description — what the team decided to prototype and why
- Key risks identified during alignment (risk type, likelihood, mitigation idea)
- Hypothesized outcome — measurable improvement expected
- KPIs to track — 3-5 success metrics with baseline and target values
- Prototype link field (Figma, Marvel, InVision URL)
- Sprint team signatures / participants roster with role
Part 3 — The Recommendation (post-research)
- Top 3 insights (each: insight title, supporting user quote, frequency signal, team implication)
- Prototype link with thumbnail or screenshot placeholder
- What to iterate — ranked list of changes with rationale
- What to change entirely — fundamental pivots identified
- What to ditch — features or approaches that failed testing
- Success assessment — hypothesis verdict: Validated / Partially validated / Invalidated; evidence summary
- What we learned vs. what we assumed — table comparing pre-sprint assumptions to research findings
- Recommended next steps — 3 actions with owner, timeline, and priority
- Go / No-go / Pivot recommendation with one-paragraph rationale
Visual signature
Three clearly delineated "chapters" with large Part labels (DM Serif Display, amber accent). Part 3 insight cards use a quote-forward design with pull-quote styling. Hypothesis verdict displayed as a large status badge.
Tone tags
Evidence-forward · Executive-grade · Honest · Decisive · No spin
Definition of done
- All three parts clearly delineated with visual separation
- Sprint hypothesis field in Part 2 using the structured "We believe…" format
- Risk table with type, likelihood, and mitigation columns
- 3–5 KPI rows with baseline and target fields
- Prototype link field present in Parts 2 and 3
- Top 3 insight cards each contain: insight title, user quote, frequency signal, implication
- Iterate / Change / Ditch sections each present with labeled items
- Hypothesis verdict badge (Validated / Partially validated / Invalidated)
- Assumptions vs. findings table present
- Go / No-go / Pivot recommendation with written rationale
- Next steps table: 3 rows with owner, timeline, and priority
- Navigation to all four modules in footer
- Prints to a clean multi-page PDF — exec-shareable without editing
Opening prompt — paste to start this build
I'm building a Design Sprint Toolkit. The Sprint Plan is in project-plan.html. Let's build deliverable 4: the Sprint Readout (design-sprint-readout.html). This is a three-part post-sprint document: Part 1 "The Pitch" (from intake — problem, evidence, stakeholders, readiness score), Part 2 "The Concept" (from the sprint — hypothesis using "We believe..." format, prototype link, risks, KPIs), and Part 3 "The Recommendation" (post-research — top 3 user insights with quotes, what to iterate/change/ditch, hypothesis verdict badge, assumptions vs. findings table, Go/No-go/Pivot recommendation, next steps). Design system: DM Serif Display headlines, DM Sans body, Sprint Amber (#B87418) as accent, surface #F5F4F1 background. The document must print cleanly as an exec-shareable PDF. Part 3 insight cards use quote-forward design. The hypothesis verdict is a prominent status badge (Validated / Partially validated / Invalidated).
04 — Build Sequence
Recommended build order
Build 1 → 2 → 3 → 4. Each file links to the next; building out of order creates broken navigation before content exists.
"To resume any build: share this plan file, name the deliverable number, and paste the opening prompt from that deliverable's spec. Everything needed to continue is here."
How to resume this project in any future session
Share this file (project-plan.html) and say: "I want to continue building the Design Sprint Toolkit. The Sprint Plan has all the specs. Let's build deliverable [number]." Then paste the opening prompt from that deliverable's spec card above. The design system, content guidelines, and all specs are captured here — any new session can pick up exactly where the last one ended.
05 — Architecture
How the four modules connect
The Sprint Toolkit is a linear workflow — a team moves through all four modules in sequence. Each file's content feeds into the next.