references/methods-prototype-test.md

# Prototype and Test method cards

## Prototype to Learn — `public_design_practice`

Name the hypothesis, pivotal assumption, question, minimum fidelity, signals, and excluded scope. Isolate the variable. Build only what changes the participant's response or technical result.

**Participatory route:** choose one Prototype Card field per turn, starting with the pivotal uncertainty. Explain unfamiliar terms at point of use and keep the user's decisions `USER_PROVIDED`.

## Paper Prototype — `supplemental_design_practice`

Use hand-drawn or printed states for flow, comprehension, and information hierarchy. A facilitator swaps states. Avoid polishing or testing backend feasibility with paper.

## Storyboard — `public_design_practice`

Show trigger, context, actors, sequence, emotional/operational moments, and aftermath. Test whether the scenario and value make sense before interface detail.

## Roleplay / Service Rehearsal — `public_design_practice`

Act out frontstage and backstage roles, handoffs, scripts, waits, and recovery. Mark what is improvised. Debrief participants and observers separately.

## Clickable Mock — `supplemental_design_practice`

Use linked screens for navigation, language, and interaction expectations. State clearly what is not functional. Avoid inferring technical feasibility or real long-term use.

## Fake Door / Landing Page — `supplemental_design_practice`

Measure attention or a meaningful commitment before capability exists. Use truthful disclosure at the right moment, avoid collecting unnecessary data, and define what action counts. Clicks alone are weak evidence of sustained value.

## Concierge — `supplemental_design_practice`

Deliver the proposed value manually and visibly. Learn whether the outcome matters and how service logic works. Record hidden labor and avoid presenting manual economics as automated economics.

## Wizard of Oz — `supplemental_design_practice`

Let participants experience an apparently automated interaction while a human or simple rule operates behind the curtain. Use ethical disclosure/debriefing and do not fake consequential decisions.

## Manual Workflow — `mightshape_original`

Run the intended process with people, checklists, and existing tools. Capture work, exceptions, and information requirements before automating.

## Spreadsheet / Email / SMS Simulation — `mightshape_original`

Use familiar low-cost media to simulate information capture, reminders, routing, or decisions. Test behavior without product infrastructure.

## Coded Spike — `mightshape_original`

Write the smallest disposable code that tests a technical or interaction uncertainty. Define time box and throwaway boundary. Do not let clean architecture become the result.

## Physical Mock — `supplemental_design_practice`

Use rough materials at relevant scale to test reach, placement, handling, fit, legibility, or environment. Match only the properties required by the question.

## Experience Prototype — `public_design_practice`

Create enough context, sequence, and sensory/social cues for someone to experience the proposed moment. Avoid staging a theatrical success that removes real friction.

## Technical Proof — `supplemental_design_practice`

Test a capability, integration, performance bound, or failure mode in isolation. Passing establishes technical possibility only—not desirability, adoption, or operational viability.

## Assumption Test — `mightshape_original`

Choose one high-risk assumption, identify the evidence that could weaken it, run the lowest-cost fair test, and record supported/weakened/falsified/inconclusive. Do not design an approval-seeking metric.

**Participatory route:** ask for one signal or test choice at a time. Coach leading or confirmation-seeking wording without erasing the original contribution.

## Usability Test — `supplemental_design_practice`

Give realistic tasks with minimal explanation; observe attempts, hesitation, errors, recovery, and expectations; then ask neutral follow-ups. Do not rescue too early or reduce the session to satisfaction.

## Feedback Matrix — `public_design_practice`

Organize feedback into useful/working elements, questions, change ideas, and surprises (labels may vary). Tie each item to observed context and avoid treating requested features as direct requirements.

## Comparative Prototype Test — `mightshape_original`

Compare the incumbent and distinct mechanisms when contrast will expose tradeoffs or determine
what gets built. Keep the trigger, evidence boundary, and success signals matched; change the
mechanism rather than the scenario. Counterbalance order where practical. Ask participants to act,
not merely vote; preserve reasons and context. Use the fewest arms that retain the decision-changing
contrast.

## Reality Check — `mightshape_original`

Compare a named synthetic expectation with real human evidence, record support/contradiction/transformation/inconclusive, and update the frame. Never blend participant types or overwrite the original synthetic record.