demo-driven-design-process

name	demo-driven-design-process
description	Use when a design or feature must converge through repeated demo, feedback, dogfooding, selection, and decision capture. Do not use merely to choose one prototype's fidelity; route that artefact decision to wireframing-and-prototyping. through).
metadata	{"portable":true,"category":"05-ux-process-research-and-psychology","compatible_with":["claude-code","codex"]}

Demo-Driven Design Process (Creative Selection, Operationalised)

Use When

• You have an idea or a half-formed design and need to refine it by iteration — not produce one big-bang artifact and not write a spec and execute it, but run a continuing progression of concrete working demos, each a deliberate variation on the last, with feedback as the selection pressure that decides which variation survives.
• You must decide what a given demo has to prove and, just as important, what it is allowed to fake or omit — drawing the fidelity ring and writing the explicit non-goals before building.
• A choice is stuck — the team keeps re-arguing it, or keeps redesigning without converging — and you need to tell whether it is an algorithm decision (codify a rule; there is an objective arrow of improvement) or a heuristic decision (resolve only by demo + taste + time), and run the right procedure for each.
• Someone proposes settling a taste decision with an A/B test, a metric, or an AI recommendation, and you need to decide whether that is evidence (admissible) or authority (not).
• You need to judge whether the choices add up over time, not just in one review — i.e. you need to live on the build / dogfood it before earning an opinion.
• A round has converged and you need to capture the decision — what was chosen, what it beat, why, and on what evidence — so it is not silently re-litigated or lost.

Do Not Use When

• You are choosing the fidelity of a single artifact (paper → lo-fi → mid-fi → hi-fi → clickable) or wiring one wireflow → use wireframing-and-prototyping. That skill produces a demo; this skill runs the loop of demos and decides what each must prove. They pair: pick the rung there, run the rounds here.
• You are running the research protocol itself (interviews, moderated tests, synthesis) → ux-research-and-usability-testing. That generates the feedback; this skill is the engine that consumes feedback to vary and re-decide.
• You are facilitating a critique session or running a heuristic evaluation as a one-off review → design-critique-and-review-facilitation / heuristic-evaluation-and-design-critique. Those are review events; this is the longitudinal build-loop they sit inside.
• You are making the one distinctive aesthetic decision for an artifact (the signature move) → 04…/distinctive-by-design. That states the ONE decision; this skill is the loop you run to refine it after it is stated.

Required Inputs

Input	Source	Evidence
Decision to resolve and demo audience	Product/design lead	One explicit learning question and decision owner
Fidelity boundary and non-goals	Team agreement	What is real, simulated, excluded, and unsafe to infer
Feedback and success evidence	Reviewers, tests, or dogfooding	Observation log separated from opinions

• The one thing this loop is trying to get right — stated concretely (this interaction, this threshold, this moment), not as a direction ("make it feel premium"). A direction is not a decision; the loop exists to force the abstraction down to something you can choose between.
• A way to make a real, running demo of that one thing — even at the lowest honest fidelity. Mock-ups of mock-ups, specs, and slides do not count (see Anti-Patterns: imaginary puppies).
• A feedback source — yourself living on it, a teammate, a test participant — and a single decider for each round (the person who selects the surviving variation; access to that room is earned by making the work better, not by rank).
• The algorithm/heuristic call for the decision at hand (see references/decision-capture.md), because it sets how the decision is allowed to be settled.

Workflow

1. Frame the one decision, and classify it. Name the single thing this round must resolve, as a concrete instance. Then classify it: is it an algorithm (there is an objective arrow — faster, fewer taps, higher contrast-ratio — that always points one way → codify the rule and move on) or a heuristic (a real value but no objective arrow — a duration, a colour, a swipe threshold, a tone → resolvable only by demo + taste + time)? Getting this wrong is the root error: settling a heuristic with a metric is the "41 shades of blue" mistake (doctrine/references/creative-selection-and-taste.md). See references/decision-capture.md for the test.
2. Draw the fidelity ring and write the non-goals. Before building, draw a conceptual ring around the one thing the demo must prove. Build that at the highest fidelity it needs (the lamppost that bears the actor's weight); deliberately fake or omit everything outside the ring (the empty hat-shop facade); take extra care only at the boundary where the fake meets the real. Write the explicit non-goals — what this demo is not trying to show — so feedback lands on the idea and not on the scaffolding. Pick the cheapest honest fidelity with wireframing-and-prototyping. See references/demo-loop-and-fidelity.md.
3. Build the smallest real, running artifact that proves it. A demo is real, running, concrete, and focused. Build only inside the ring. The point is to have a concrete thing in the room to react to — never hold the design discussion about an imaginary artifact.
4. Live on it / get feedback. For a heuristic you cannot judge from a single look — live on the build ("dogfood" it) long enough to feel whether the choice adds up over time, or route a real feedback pass through ux-research-and-usability-testing. Refinement is longitudinal. If you have not lived on the thing, you have not yet earned an opinion about whether it works.
5. Select by taste; let the feedback cause a fresh divergence. The single decider selects the surviving variation by conviction, not by deferring to a number or an AI pick (metrics and AI suggestions are admissible as evidence to inform, never as authority to decide — doctrine/design-doctrine.md §2). Then let what you learned cause the next deliberate variation. Converge on a demo → diverge on the feedback → converge again. Prefer subtraction: the strongest next demo is often the one with something removed ("edit for less", Miller 7±2).

Decision Rules

Condition	Choice	Wrong-choice failure
Outcome has an objective measurable improvement	Algorithmic rule/test	Taste voting obscures a verifiable answer
Options are viable and differ by feel	Time-boxed craft judgment with named owner	Fake metrics launder subjective preference
Demo plumbing does not affect the question	Simulate it and label the boundary	Building irrelevant infrastructure delays learning

Capability Contract

• Must inspect demo artefacts and capture evidence; review is read-only unless the iteration explicitly authorises edits.
• May prototype within the agreed fidelity ring, but may not present simulations as production evidence or publish without authority.

Degraded Mode

• If no single decision or owner exists, stop the demo cycle and establish them.
• Without runnable prototypes, use a storyboard labelled simulated. Recover a non-informative round by narrowing the question, changing the fidelity boundary, and scheduling the next evidence-producing demo.

Quality Standards

• Each round changes or confirms one decision and preserves the evidence, dissent, and non-goals.
• Convergence is an explicit owner decision, not exhaustion or majority taste.

Anti-Patterns

• Arguing about imaginary puppies. Holding a design discussion over specs, slides, or a mock-of-a-mock with nothing real and running in the room. Build the smallest real artifact that proves the one idea, then react to it (doctrine/references/creative-selection-and-taste.md).
• Outsourcing a taste decision to a metric. A/B-testing 41 shades of blue and shipping the winner — picking the best of the options you were handed and paying the opportunity cost of the far-better design conviction would have reached. A metric may inform a heuristic; it may never decide it. (Same error, restated: outsourcing the pick to an AI recommend-list — both launder the choice to the mean the Mission exists to escape.)
• Using an algorithm where a heuristic is required (or vice-versa). Tuning an animation's duration with a conversion metric; or "deciding by taste" something that has a hard objective arrow (load time) and should just be codified.
• Demos with no ring. Polishing everything to the same fidelity so feedback scatters across scaffolding instead of landing on the one idea; or, conversely, faking the very thing the demo was supposed to prove.
• Reviewing once and calling it judged. Shipping a heuristic off a single look without living on it — refinement is longitudinal; one critique is not enough signal.
• Big-bang build / spec-then-execute. Skipping the loop entirely: producing one large artifact from a written spec, with no progression of variations and no selection pressure.
• Never converging. Treating every round as a reason to add more, never letting taste call the loop done. Decisiveness is part of the craft.
• Losing the decision. Converging and then not capturing why, so the same argument is had again three weeks later with no record of what was already tried and beaten.

Outputs

Output	Consumer	Evidence and acceptance
Demo brief and iteration log	Team and decision owner	Question, fidelity ring, observations, selection, and next move are recorded
Decision record	Implementers	Chosen option, rejected options, rationale, owner, and reopening condition are explicit

• A classified decision: the one thing being resolved + its algorithm/heuristic class + the procedure that follows from the class.
• A demo plan per round: the fidelity ring, the explicit non-goals, the cheapest honest fidelity.
• An iteration log: the progression of demos, the feedback each round, the taste call and its one-sentence conviction, and the convergence point — see the worked example.
• A decision record: what was chosen, what it beat, why, on what evidence (with any metric/AI signal logged as convergence, not authority), ready to hand to dev/critique/handoff.

Examples

• See examples/save-search-toast-iteration-log.md — a real worked demo-driven iteration for one feature ("confirm a saved search without yanking the user out of their flow"): four demos, the feedback and the taste decision each round, the algorithm-vs-heuristic calls, convergence by subtraction, and the captured decision record. Representative content throughout — never lorem.

References

• references/demo-loop-and-fidelity.md — the demo → feedback → next-demo loop run end to end; what makes a demo real, running, concrete, focused; the fidelity ring + non-goals (Hollywood-backlot) method for what to make real vs fake; "live on it" / dogfooding as longitudinal refinement.
• references/decision-capture.md — the algorithm-vs-heuristic test (when to codify a rule vs make a judgement call), the "metric/AI is evidence, never authority" rule, convergence-by-taste, and the decision-record template that captures what was chosen and why.
• doctrine/references/creative-selection-and-taste.md — the doctrine this skill operationalises (the five working rules, the "41 shades of blue" lesson, the inspiration→…→taste→empathy chain). This skill operationalises that reference; it does not duplicate it.
• doctrine/design-doctrine.md — §0 (the moat is looking human-made; push away from the convergent mean) and §2 (the sourcing-authority asymmetry rule — a taste decision traces to human conviction, never to a number or a model's pick).
• Pairs with wireframing-and-prototyping (pick one artifact's fidelity there; run the loop here) and feeds design-critique-and-review-facilitation / heuristic-evaluation-and-design-critique (each round's feedback pass) and group-09 handoff (the captured decision).