quantipixels Prototype
Build a throwaway decision instrument for one question that discussion, static prose, or a cheaper sketch cannot settle.
Do not fake the dimension being tested.
A behavior/process question needs a truthfully exercisable representation of that behavior. A visual-reading question needs sufficient visual fidelity. A CLI or API ergonomics question needs a runnable interaction. The prototype produces decision evidence; it is not the accepted delivery result.
1. Pin the decision question and evidence claim
State the one material question, why cheaper evidence is insufficient, who must experience the result, the dimension being tested, accepted fidelity, variants if needed, exclusions, disposal boundary, available environment, and mutation or external-effect authority.
One prototype boundary may contain several variants when they answer the same pinned question and test the same dimension. A new material question, audience, or evidence claim requires a new boundary.
Do not start when the missing outcome is selection without experiential evidence, accepted/production delivery, or ordinary polish.
When the question depends on subjective experience, require an attending human. An unattended run cannot invent how the interaction feels or what the user prefers.
2. Build the minimum truthful artifact
Choose the smallest medium and fidelity that can answer the question. Reuse existing project/runtime components, templates, fixtures, documents, process artifacts, or host-native preview capability when that improves truth without turning the prototype into accepted delivery work.
Use a disposable or isolated location for file-based prototypes. Do not modify the accepted/production candidate unless separately authorized for a bounded prototype location. Avoid real customer data, production credentials, irreversible effects, external messages, or payments. Label simulated behavior clearly, but never simulate the dimension being decided.
Use an existing preview/server capability when one is needed; do not add a bundled server merely for this workflow.
3. Let the user experience and decide
Give the user the runnable, inspectable, or otherwise directly experienceable path and a concise observation prompt tied to the question. Record what they actually observed, not what the author expected. Compare variants only against the pinned dimension.
Revise only while the next version still answers the same question. Finish with exactly one result:
DECIDED— direct experience selected or confirmed an answer;INCONCLUSIVE— the artifact was exercised but did not distinguish the alternatives;BLOCKED— a named environment, capability, authority, evidence, or human-attendance gap prevented the test; orABANDONED— the user ended the experiment without a decision.
Return the question, artifact locator, variants, fidelity, simulations, observations, result, unresolved alternatives, and limitations.
State the evidence boundary explicitly. A visual prototype does not prove performance, security, accessibility, integration, maintainability, operational viability, or another dimension unless that dimension was represented truthfully. A runnable interaction does not prove production readiness.
4. Retain the decision, not disposable implementation
Prototype implementation/material is not the accepted delivery result. Carry forward the confirmed decision, interaction/process contract, selected assets, measurements, and limitations—not the disposable implementation by default.
Temporary work may be deleted after the evidence is captured. Persist the decision instrument only when a durable result is separately required.