Stop Polishing. Your Prototype Only Needs to Answer One Question.

Decide the question before you build, write it down, and build only what answers it. Everything else stays grey. A prototype that looks finished invites judgement on presentation rather than on the question, which is how teams get a confident answer to something they were not asking.

Why this matters

Prototypes are cheap only when they are ruthlessly scoped. An unscoped prototype becomes a small game, and a small game takes months.

The second cost is subtler. A polished prototype produces polite feedback about polish. People respond to what is in front of them, and if the art is finished they will discuss the art.

Naming the question protects both the schedule and the answer.

Deciding the question before you build

The question should be answerable with a yes or a no, and it should matter.

Strong questions:

• Does this mechanic hold attention for two minutes without progression?
• Can a new player understand the goal in five seconds with no text?
• Does this control scheme work one-handed on a phone?
• Is this loop still interesting on the twentieth repetition?
• Does this hook read in a three-second video?

Weak questions: is this fun, is this good, would people play this. None of them can be answered, so none of them will be.

If you cannot say what result would make you stop, you have not written a question yet.

Write the failing condition alongside the question. Deciding in advance what a no looks like is what makes it possible to accept one later.

What to build to answer it

Build the shortest path to a real answer, which is usually much less than it feels.

Work backwards from the question.

The right column is the important one. Every item you build from it is time spent not answering the question.

What to deliberately leave ugly

Some things should look unfinished, because looking unfinished sets the right expectation for the viewer.

• Art. Flat colours, one font, no effects beyond what the mechanic needs.
• Menus. A single screen, or none at all, starting straight into play.
• Audio. One or two placeholder sounds, unless the question is about feel.
• Content volume. Three levels, not thirty.
• Persistence. Nothing saved, unless the question requires a second session.

There is one exception worth making. If the question concerns feel, then feel must be real, and the rest gets even rougher to compensate. That is the version described in Why Juice Sells.

How polish hides a bad answer

This is the failure mode that costs the most.

A polished prototype gets a warmer reception from everyone: your team, your testers, your investors. That warmth is a response to craft, and it is easily mistaken for a response to the game.

Three specific distortions.

1. Testers report the wrong thing. They comment on art and sound because those are the most legible parts.
2. Your own judgement shifts. Effort invested makes a concept harder to abandon.
3. A weak loop is masked. Good feel can make almost any interaction pleasant for sixty seconds, which is exactly the window in which most prototypes are judged.

The defence is to test the loop while it is still ugly. If a grey-box version holds attention, the concept is real. If it only works once it looks good, you have learned something about your art rather than your design.

Killing a prototype cleanly

Most prototypes should end in a no, and how you end them determines whether the process is sustainable.

Four steps.

1. Compare against the failing condition written at the start, not against how you feel about it.
2. Write the finding in three sentences: the question, what happened, what you would do differently.
3. Keep the reusable parts. Tooling, templates, and any system worth carrying into the next one.
4. Stop on the agreed day, even if it feels close. Prototypes that get extended once get extended every time.

Then move on without ceremony. A no reached in a week is a good outcome, and treating it as a failure is what makes teams stop running them.

The failures worth publishing are also worth keeping internally, which is the reasoning behind Prototype Graveyard.

What we would do

Write the question on a card and keep it visible while building. It sounds trivial and it changes what gets built, because every proposed addition gets measured against it.

Test at the ugliest point you can stand. The earlier you show a grey-box build to real people, the more honest the answer.

Then hold the stop date. The discipline that makes prototyping valuable is not the building, it is the stopping, and it is the part that erodes first.

The short version

• Write one question and its failing condition before building anything.
• Strong questions are answerable with yes or no; "is this fun" is not one.
• Build only the shortest path to the answer, and leave the rest grey.
• Polish attracts feedback about polish, and can mask a weak loop for sixty seconds.
• Test while it is still ugly, because that answer is the honest one.
• Kill on the agreed day, write three sentences, keep the reusable parts.

Write the question and the failing condition for your current prototype today. If you want a team that runs these to a fixed cadence, get in touch.

Related reading: The 7-Day Prototype, What Is a Game Prototype, and How to Run a Playtest With Ten People.