How to Run an Indie Game Playtest Before You Feel Ready

Indie teams often postpone playtesting until the game looks presentable. The build needs better art, the tutorial needs one more pass and the known bugs feel too embarrassing to show. This instinct is understandable, but it turns playtesting into a final exam instead of a production tool.

An early playtest is not a verdict on the game. It is a way to reduce one important uncertainty before the team invests more time. You do not need a polished build or dozens of players. You need a clear question, a playable route and a plan for turning observations into decisions.

This guide explains how to run a small, useful indie game playtest while the project is still rough.

Start with one decision, not a request for feedback

“Tell us what you think” sounds open, but it produces scattered opinions. One player comments on the colors, another asks for multiplayer and someone else suggests changing the genre. The team finishes with many notes and no obvious next action.

Begin by naming the production decision the test should inform. For example:

• Should the player see the objective before entering the arena?
• Is the dash understandable without written instructions?
• Does the first combat encounter create enough pressure to teach healing?
• Can a new player complete the crafting loop without developer help?
• Which of two control schemes should become the default?

A useful playtest question is narrow enough that the team can change something after hearing the answer. “Is the game fun?” is too broad. “Do players understand when to switch weapons during the first boss phase?” points toward a specific design decision.

Write the question at the top of the playtest plan. When somebody proposes an extra task or survey item, ask whether it helps answer that question. If not, save it for another session.

Choose the smallest playable route

Do not ask a tester to wander through the entire available build. Create a short route that exposes the decision you care about.

If you are testing whether the dash is readable, the route might include:

1. A safe space where movement can be discovered.
2. One obstacle that makes dashing useful.
3. One low-risk consequence for mistiming it.
4. A clear end state after the player succeeds.

This route may take five minutes. That is enough if it generates the evidence you need.

Use a save file, debug menu or special build to start near the relevant moment. The goal is not to disguise development; it is to protect the test from unrelated noise.

Define success before watching anyone play

Decide what evidence would support or challenge the current design. Use observable behavior rather than a satisfaction score alone.

For a first combat encounter, success criteria could be:

• at least four of five players identify the threat without a prompt;
• most players use the intended defensive action during the encounter;
• no player remains stuck for more than 30 seconds;
• players can explain the win condition in their own words afterward.

These criteria are not universal quality standards. They are thresholds for one team decision. A tiny sample cannot prove that every future player will behave the same way, but it can reveal repeated confusion and prevent the team from rationalizing obvious problems.

Also write down what would make the session invalid. A crash before the test route, a tester who already knows the solution or a developer giving accidental instructions may mean that result should not be compared with the others.

Prepare a stable-enough build

A playtest build does not need final content. It does need to preserve the path being tested.

Before inviting anyone, run the exact route on the same hardware and input method the tester will use. Check that:

• the build launches without development tools;
• required controls are available and correctly mapped;
• the test route can be completed from a clean start;
• save data from another session cannot change the result;
• known bugs have workarounds or are outside the route;
• recording and note-taking tools do not damage performance.

Give every participant the same clean start. Label placeholder content only when it could be mistaken for a final design; lengthy apologies encourage reassurance instead of natural reactions.

Recruit for the question you are asking

You do not always need players from your final marketing audience. The right participant depends on the uncertainty.

A tutorial test benefits from people unfamiliar with the game. A high-level balance test may require players who already understand the genre. A local cooperative flow needs pairs who can communicate naturally. Testing a complex controller layout with keyboard-only players will answer the wrong question.

For an early qualitative test, five carefully chosen participants can expose repeated confusion. Treat this as discovery, not a statistical claim. Record only useful context such as genre familiarity, platform and whether the participant played an earlier build.

Give neutral instructions

Tell participants what will happen, how long the session will take and whether the screen or voice will be recorded. Ask for explicit permission before recording.

Then describe the task without teaching the solution. Compare these two prompts:

Use the blue dash ability to pass the laser gate.

Find a way through the laser gate.

The first prompt tests execution after instruction. The second tests whether the game communicates the mechanic. Either can be valid, but they answer different questions.

Tell testers that you are testing the game, not their skill. Ask them to think aloud if that will not interfere with the experience. Make it clear that silence is also acceptable; behavior is evidence even when a player cannot explain every action.

Observe without rescuing the player

Watching someone struggle with a system you built is uncomfortable. Developers naturally want to explain the rule, point at the interface or say, “Most people notice that icon.”

Do not intervene unless the session has reached a predefined rescue condition. Note the moment, the visible behavior and what the player appeared to expect. Avoid interpreting motives while the test is running.

A useful observation is specific:

The player opened the inventory three times after collecting the key, then returned to the locked door without equipping anything.

A weak observation adds a conclusion too early:

The inventory is confusing.

The specific note gives the team several hypotheses to examine. Perhaps the door feedback implies that an item must be equipped. Perhaps the key icon is unclear. Perhaps the previous tutorial taught the wrong pattern.

When you must help, use the smallest prompt possible and record it. The amount of assistance required is part of the result.

Separate observation, interpretation and action

After each session, organize notes into three layers:

• Observation: what the player did or said.
• Interpretation: what the team thinks may explain it.
• Action: what will change or what needs another test.

For example:

• Observation: four players waited beside the inactive elevator after combat.
• Interpretation: the end-of-encounter state did not communicate that the exit door had opened behind them.
• Action: add a camera cue and retest the transition with three new players.

Keeping these layers separate prevents one developer’s theory from becoming a fact. It also makes disagreements productive. The team can agree on the observation while proposing different explanations.

Tag repeated observations, but do not count every comment equally. A player requesting a crafting system is an opinion. Five players missing the same objective marker is a pattern in behavior. Both can be saved, but only one may be relevant to the current decision.

Debrief after the playable route

Ask questions after the player reaches the end state, not during every moment of confusion. Interruption changes how they experience the next section.

Good debrief questions invite recall and explanation:

• What did you think your objective was?
• When did you first notice the dash?
• What did you expect to happen after the enemy was defeated?
• Was there a moment when you felt stuck?
• What information would have helped at that moment?

Avoid leading questions such as, “Was the objective marker too small?” They encourage agreement with the team’s hypothesis.

If a participant proposes a feature, ask what problem it would solve. The underlying need may be valuable even when the suggested implementation does not fit the game.

Turn findings into a small change list

Hold a short synthesis session while observations are fresh. Start with the original playtest question and choose one outcome:

1. Keep the current design because the evidence supports it.
2. Change the design and define the smallest retest.
3. Run another test because the evidence is mixed or the session was invalid.
4. Drop or reduce the feature because the problem is not worth further production cost.

Create only the tickets needed for that outcome. Each ticket should reference the observed problem, identify an owner and belong to a playable milestone. Do not convert every comment into backlog work.

Limit the immediate change list. When a test generates 30 tasks, the team has probably mixed unrelated feedback with the core decision. Preserve the other notes in a research summary, but protect the next build from uncontrolled scope growth.

Close the loop with another build

A playtest is complete only when the team uses the evidence. Link the session summary to the relevant milestone and record:

• the question;
• participant profile;
• build version;
• key observations;
• chosen decision;
• follow-up tickets;
• planned retest, if needed.

This short record matters when the same debate returns months later. It shows what was tested, what was not tested and why the team chose the current direction.

The next test should be smaller when possible. If a camera cue is the proposed fix, you do not need to replay an hour of content. Put new participants near the transition and check whether they leave the arena without help.

A compact early playtest template

Use this template for a session that can fit inside one production cycle:

• Decision: the choice this test will inform.
• Question: the player behavior you need to understand.
• Build and route: the exact version, start point and end state.
• Participants: who can answer the question and what experience they need.
• Success criteria: the observable behaviors that support the design.
• Rescue condition: when the observer may intervene.
• Capture method: notes, screen recording, telemetry or a combination.
• Debrief questions: three to five neutral prompts.
• Synthesis owner: the person responsible for turning evidence into a decision.
• Retest plan: the smallest route that can verify the change.

The best time to playtest is not when the game can impress a stranger. It is when the team faces an expensive uncertainty that a small playable build can reduce. Test one decision, observe real behavior and let the next milestone follow the evidence.