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:

1. Prototype read - what is being prototyped and why
2. Intent diagnosis - whether this is a selling demo, a learning prototype, or a confused hybrid
3. Scope fit - whether the prototype contents match the stated intent
4. Unknowns coverage - what the prototype is or is not actually testing
5. Risk diagnosis - what time or learning may be wasted under the current plan
6. 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.

<!-- license-footer --> 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/)