Demo Days 0 to 14 Time-Machine Playbook

Purpose

Most prototypes fail the same demo test: they only represent one maturity state. Either everything is empty and looks unfinished, or everything is fully populated and looks fake. A day-based time machine solves this by treating maturity as a first-class axis. You can show realistic progression from first run to stabilized usage, while preserving one interface and one narrative.

When to use it

• You need to demo onboarding, activation, and follow-through as one coherent story
• Stakeholders ask, “What does this look like at launch vs. two weeks in?”
• Your team keeps hard-coding fake “final state” screenshots that skip early-state UX
• You want honest Day 0 empty states without losing confidence in the later experience

Skip it when: your product has no meaningful state progression over time, or when legal/compliance requirements prohibit synthetic demo states.

Core framework

Use a state model with six demo checkpoints:

1. Day 0: first-run state, unknowns visible, setup prompts clear
2. Day 1: initial setup complete, first recommendations/actions available
3. Day 3: early usage patterns visible, first outcomes measurable
4. Day 7: patterns stabilize, prioritization starts to shift
5. Day 8: post-adjustment state after one optimization pass
6. Day 14: mature short-term state, routine operations and refinements

Design rule: each day must change user-relevant signals, not just numbers. If the workflow does not change, the day should not exist.

Use this transition map:

flowchart LR
  D0["Day 0 First Run"] --> D1["Day 1 Activated"]
  D1 --> D3["Day 3 Early Pattern"]
  D3 --> D7["Day 7 Stabilizing"]
  D7 --> D8["Day 8 After Tuning"]
  D8 --> D14["Day 14 Operational"]

Reusable template

# Demo-day state plan: <surface>

## Day checkpoints

| Day | User reality | UI signals | Allowed actions | Success signal |
|---|---|---|---|---|
| 0  | <first run> | <empty/unknown states> | <setup actions only> | <activation started> |
| 1  | <newly configured> | <first meaningful indicators> | <guided actions> | <first task completed> |
| 3  | <early rhythm> | <emerging patterns> | <selective optimizations> | <repeat behavior visible> |
| 7  | <stabilizing> | <clear priorities> | <targeted interventions> | <fewer unknowns> |
| 8  | <post-adjustment> | <state shift after change> | <fine tuning> | <delta acknowledged> |
| 14 | <operational> | <steady-state indicators> | <maintenance + refinement> | <routine confidence> |

## Invariants (must stay true every day)

- <navigation model>
- <information architecture>
- <core action semantics>

## Variables (can change by day)

- <status labels>
- <counts / trend direction>
- <recommended next actions>
- <coachmark / guidance emphasis>

Live reference prototype

• View the interactive day-switch reference at /toybox/prototypes/demo-days-0-reference/
• Use it to sanity-check whether each day changes user meaning (not just numbers)

AI-assisted workflow

Use AI to generate a coherent progression before writing UI copy.

You are helping me design a six-checkpoint demo timeline for a product
experience. Given the product surface and goal, produce Day 0, 1, 3, 7, 8,
and 14 states.

Output format:
1. User reality for each day
2. What the interface should visibly change
3. What must remain invariant
4. One anti-pattern to avoid for each day

Constraints:
- Do not invent internal metrics or confidential product facts.
- Keep all examples generic and reusable.
- Day 0 must show honest unknown/empty states.

Then validate consistency:

Review this day-based state plan and flag timeline breaks:
- sudden jumps that skip required setup
- repeated days that add no user value
- contradictions between allowed actions and visible state

Return:
1. broken transitions
2. minimal fix per transition

Collaboration considerations

• For PMs: define what each day means in user terms, not business terms
• For developers: isolate day fixtures from production pathways to prevent accidental coupling
• For research: test comprehension of progression, especially Day 0 credibility and Day 14 trust
• For accessibility: ensure every day variation preserves contrast, focus order, and semantic clarity

Common failure patterns

1. Turning days into number swaps with no workflow change
2. Hiding Day 0 emptiness with fake completed states
3. Adding too many checkpoints and diluting the narrative
4. Changing IA between days so demos feel like different products
5. Using irreversible demo controls that make side-by-side comparison impossible

Companion artifacts

• Secret Handshakes for Designers Playbook for hidden controls that make day switching repeatable in review
• Demo days 0 to 14 reference for a live implementation of this progression model
• Audit Command Center Template for tracking day-specific quality issues as findings

Generalized example

A fictional workflow automation dashboard uses this timeline:

• Day 0 shows no active automations, clear setup prompts, and unknown trend cards
• Day 1 introduces one configured workflow and one recommended next step
• Day 3 shows repeated runs and first exception alerts
• Day 7 highlights highest-friction step and targeted optimization actions
• Day 8 reflects post-optimization improvements in flow stability
• Day 14 presents routine operations with periodic tuning tasks

All numbers are illustrative. The value is the sequence logic, not specific metrics.

---

Public-safe review (verified before publish)

• No employer or client product names, codenames, or org names
• No customer names, segment sizes, or identifiable details
• No internal metrics, thresholds, OKRs, or telemetry numbers
• No roadmap, ship dates, or future plans
• No architecture, service names, API shapes, or schema fields from real systems
• No screenshots showing real chrome, real data, or recognizable surfaces
• No internal-only workflows, tools, or terminology
• Every example is fictional or abstracted; numbers are illustrative
• A peer outside any employer could read this and learn nothing proprietary