Game Design Prototype Intent Audit
Decide what the prototype is for before deciding what the prototype should contain.
Use this skill to audit whether a prototype is being built to convince stakeholders that an idea works, or to reveal the least-understood parts of the design. These two goals require different prototype choices. Confusing them is one of the most common ways to waste prototype time.
Read references/prototype-modes.md when classifying the prototype intent.
Read references/unknowns-checklist.md when identifying what a learning prototype should target.
Read references/failure-patterns.md when diagnosing common prototype mistakes.
What to produce
Produce:
- Prototype read - what is being prototyped and why
- Intent diagnosis - whether this is a selling demo, a learning prototype, or a confused hybrid
- Scope fit - whether the prototype contents match the stated intent
- Unknowns coverage - what the prototype is or is not actually testing
- Risk diagnosis - what time or learning may be wasted under the current plan
- Recommendation - what to prototype instead, emphasize, cut, or sequence differently
Process
1. Clarify the prototype ask
Ask:
- what idea, feature, or concept is being prototyped?
- who is the prototype for?
- what decision is the prototype supposed to unlock?
- what would count as success for the prototype itself?
2. Diagnose intent
The prototype usually serves one dominant purpose:
- Selling demo - prove the concept is exciting, legible, or worth greenlighting
- Learning prototype - reveal unknowns and answer risky design questions
- Confused hybrid - trying to sell the idea while also pretending to test unknowns, without doing either well
3. Check scope fit
Ask whether the implementation focus matches the intent. For example:
- selling demos usually emphasize strengths, clarity, and presentability
- learning prototypes should target unclear, risky, or least-understood aspects
4. Audit unknowns
If the team claims the prototype is for learning, identify:
- what specific unknowns are being tested
- whether the prototype can actually answer them
- what it is avoiding or glossing over
5. Diagnose failure mode
Common failures include:
- demo dressed up as learning
- prototype solving the easiest part, not the riskiest part
- too much polish hiding too little insight
- trying to answer too many questions at once
- building broad slices when one narrow uncertainty should be isolated
6. Recommend a better prototype move
Possible recommendations:
- turn it honestly into a selling demo
- strip it down into a learning prototype
- split one prototype into two sequential prototypes
- narrow the question set
- focus on the riskiest unknown first
Response structure
Prototype Read
- ...
Intent Diagnosis
- ...
Scope Fit
- ...
Unknowns Coverage
- ...
Risk Diagnosis
- ...
Recommendation
- ...
Fast mode
- Who is this prototype for?
- Is it trying to sell the idea or learn something?
- What unknowns are actually being tested?
- What is being polished that does not answer the real question?
- What is the better prototype plan?
Style rules
- Be explicit about the dominant intent.
- Do not flatter vague prototype plans.
- Prefer one answered question over many implied ones.
- If the prototype is really a demo, say so cleanly.
- If the prototype is not testing the true risk, point that out directly.
Working principle
A prototype is not automatically useful because it exists. Its value comes from whether it is built for the right purpose and judged by the right standard.
Part of the Game Design Skills Bundle by Stanislav Stankovic. Licensed under PolyForm Noncommercial 1.0.0 — free for personal, academic and nonprofit use. Commercial use requires a licence, sold as skill packs. See https://github.com/Stanestane/game-design-skills-bundle for terms.
Required Notice: Copyright Stanislav Stankovic (https://www.stane-island.net/)
