# Demo Driven Design Process > 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). - Skill: `peterbamuhigire/demo-driven-design-process` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add peterbamuhigire/demo-driven-design-process` - Raw SKILL.md: https://api.skillmd.com/api/skills/peterbamuhigire/demo-driven-design-process/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: peterbamuhigire (https://skillmd.com/u/peterbamuhigire) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/peterbamuhigire/demo-driven-design-process --- # 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). 6. **Repeat until it converges — then stop.** Run rounds until further variation stops improving the one thing (taste, not a target number, tells you you're there). Resist both early-stopping (ship the first that works) and endless polishing. "We picked one and moved on" is a virtue once the loop has done its job. 7. **Capture the decision.** Record what was chosen, what variations it beat, *why* (the conviction in one sentence), the algorithm/heuristic class, and any metric/AI signal logged as **convergence, not endorsement**. This stops the choice being silently re-litigated and feeds the next loop. See `references/decision-capture.md` and `examples/save-search-toast-iteration-log.md`. ## 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).