From paper prototype to a useful playtest

Not every game idea can be tested on a table. Movement feel, animation and real-time precision usually need a playable digital version. But a paper prototype can answer useful questions about choices, resources and the information a player needs. Start by naming the question rather than trying to represent the entire game.

Choose one decision

Suppose the player must choose between a short dangerous route and a longer reliable one. Draw a few location cards and give the player a limited supply of counters representing time. Write the cost of moving and the consequence of taking the risky route on separate cards so they are easy to change.

Use simple shapes and handwritten labels. Beautiful components create pressure to preserve a rule that ought to be discarded. Keep the first version small enough to explain in a minute and play in a few minutes.

Make the information explicit

Decide what the player knows before choosing. Do they see the cost of both routes? Is the danger uncertain? Can they recover after a poor decision? These details often matter more than the number of spaces on the board.

If you are standing in for the computer, record every rule you apply. Do not quietly rescue the player with an exception that is absent from the design. When you need to improvise, write the missing rule down and discuss it after the round.

Watch for the dominant choice

Play several short rounds with the same rules. If one option is always selected, ask why. It may be too powerful, too easy to understand or simply better aligned with the stated goal. Do not immediately add random events to disguise the imbalance. First check whether both choices offer a real trade-off.

Change one variable and repeat. For example, alter the cost of the longer path while leaving the reward unchanged. Keep a note of the version so that observations from different rule sets do not become mixed together.

Know when paper has done enough

The prototype is ready to move on when it has answered its question or revealed a question that paper cannot answer. You might learn that the route choice is interesting but depends on how movement feels. That is a good reason to build a small digital test.

Photograph the final layout and write a short rule sheet. Include the unresolved issue. A paper prototype is useful because it supports a decision, not because it resembles a miniature finished product.

Run the first observed test

A first playtest is a chance to discover what your prototype communicates without you. It is tempting to guide the player around every rough edge, but that can hide the very problems you need to see. Choose a small test, state its limits and give the player room to make their own decisions.

Set one learning goal

Write a question such as “does the player understand how to open the gate?” or “can they find the inventory after collecting an item?” Avoid trying to measure enjoyment, balance, accessibility and performance in one short session. A focused question makes both observation and revision easier.

Prepare a reliable starting state and a way to restart. Tell the participant that you are testing the game rather than their ability. Ask permission before recording audio, video or identifying information. You can take anonymous notes without building an unnecessary collection of personal data.

Give the minimum introduction

Explain the controls the prototype genuinely requires, then stop. If learning the controls is the test itself, make that clear in your plan. Do not add hints merely because a pause feels uncomfortable. A pause can reveal uncertainty that a fluent demonstration would conceal.

Record observable events: “opened the same drawer three times” or “walked past the exit twice”. Keep your interpretation in a separate column. “Did not understand the goal” may be plausible, but it is still an explanation to investigate rather than a directly observed fact.

Ask about moments, not ratings

After the session, return to specific events. Ask what the player expected when they pressed a button or why they returned to a room. Avoid questions that contain your preferred answer, such as “was the flashing light helpful?” A neutral question leaves room for an unexpected explanation.

A participant’s suggested solution can be useful, but first identify the problem behind it. “Add an arrow” may mean that the destination was unclear, the environment lacked contrast or the goal was forgotten. Those problems may need different changes.

Choose the next revision

Group the notes around your original question. Select one or two changes with a clear expected effect and preserve the current build for comparison. Do not treat one person’s preference as a universal result. A small playtest provides evidence and new questions; repeating a focused test with another person can help you distinguish a pattern from an isolated experience.