Playtest Report Template: Turn Notes Into Decisions

A playtest report template gives every round of testing the same shape: what you tested, what players did, how bad each problem is, and what you will change before the next build. Below is a copy-paste template you can drop into a doc today, a filled-in example from a small action game, and a severity scale that stops you from fixing the loudest comment instead of the biggest problem.

This guide is about the write-up after the sessions are done. If you still need to plan the sessions themselves, start with our session script for running a playtest, then come back here once you have notes.

Why a solo dev still needs a playtest report

It is tempting to skip the write-up when you are the whole team. You watched the sessions, you remember what happened, so why write it down?

Because memory edits itself. A week later you will remember the tester who loved your art and forget the three who never found the dash button. Graham McAllister, who has run player research for studios for years, puts it well in his playtesting book: a report turns knowledge that lives in a few people's heads into something explicit, and it is a persistent account of what happened. That second part matters most for solo developers. Your future self is the other person on the team.

A short report also does three practical jobs:

• It forces you to count. "Some people struggled" becomes "4 of 6 testers died to the first elite enemy."
• It separates what players did from what you think should change, which keeps you from fixing symptoms.
• It gives you a baseline. When you test the next build, you can check whether the problem actually went away.

PlaytestCloud's advice on playtest summaries makes the same point for solo devs: you do not need to spend long writing up, but structured notes are still worth keeping for future reference. One page is enough if it is the right page.

The playtest report template (copy and paste)

Copy everything in this section into a Google Doc, Notion page or plain text file. Fill in the brackets. Delete any part you do not need for a small round.

1. Header

• Game: [name or codename]
• Build: [version number or commit, and platform]
• Round: [for example "Round 3: first 15 minutes, new players"]
• Dates of sessions: [dates]
• Report written: [date]
• Author: [your name, so teammates or collaborators know who to ask]

2. Purpose

• The question this round was meant to answer: [one sentence, for example "Do new players understand the upgrade shop without help?"]
• Context: [how this round relates to earlier ones, for example "Second test of the tutorial after removing the text popups"]

3. Summary

• Answer to the question: [Yes, No, or Partly, plus one sentence]
• Top three findings: [one line each, most severe first]
• What changes before the next build: [one to three items]
• So what: [one sentence on what this means for the game, for example "The core fight is landing, but onboarding is costing us the first five minutes."]

4. Who played and how

• Players: [number, and how you found them]
• Fit: [do they play games like yours? list two or three games they mentioned]
• Format: [in person, remote and moderated, unmoderated, video review, written review]
• Session length: [planned and actual]
• Tasks or instructions given: [what you told them, word for word if possible]
• Questions asked afterwards: [link to your form or list them]

5. Findings

Repeat this block for each finding. One finding per block keeps the report scannable.

• Finding: [short title, for example "Players miss the dash"]
• Area: [level, feature or moment in the game]
• Severity: [Critical, High, Medium or Low, see the scale below]
• Frequency: [how many players out of how many, for example 4 of 6]
• What happened: [observed behaviour only, for example "Four players died to the first elite without dashing once."]
• Why we think it happened: [your best explanation, labelled as a guess]
• Evidence: [timestamps in recordings, quotes, screenshots]
• Player quote: ["I didn't know I could dodge."]
• Suggestions heard: [ideas from players or the team, not yet decisions]
• Decision: [Fix now, Fix later, Watch next round, or Won't fix, plus a reason]

6. What went well

• [Moments players enjoyed, replayed or talked about without being asked]
• [Things you were worried about that turned out fine]

7. Decisions and next round

• Changes for the next build: [each one tied to a finding]
• What we expect each change to fix: [so you can check it next time]
• Next round's question: [one sentence]
• Who to test with next: [fresh players, returning players, a specific genre fan]

8. Open questions

• [Things you could not answer this round and want to look at again]

How to fill in the findings

The findings block is where most reports fall apart. Here is how to make each field useful.

Write what players did before what you think

McAllister suggests describing the issue factually: what the player actually did or what they believe about how the game works, then why it happened, then the effect. Keep those in order. "The dash is badly explained" is a conclusion. "Four of six players never pressed the dash button during the first fight" is a finding. The conclusion can follow, clearly labelled as your interpretation.

Use a severity scale you decide on before reading the notes

Pick your scale once and reuse it every round. This one works well for indie games:

• Critical: blocks progress or makes players quit. Crashes, soft locks, a door nobody can find, a boss nobody can beat.
• High: players get through, but the problem damages the experience they came for. Missing the core mechanic, getting lost for minutes, a difficulty spike that kills the mood.
• Medium: noticeable friction that players recover from on their own. Clunky menus, unclear icons, a confusing reward.
• Low: polish. Typos, small visual bugs, minor balance quibbles.

Combine severity with frequency

Severity tells you how bad a problem is. Frequency tells you how many people hit it. You need both. A simple rule of thumb:

1. Critical issues get fixed even if only one player hit them, because the next player might quit.
2. High issues that several players hit go to the top of the list.
3. Medium issues that most players hit often matter more than a High issue only one person found.
4. Low issues go in a polish list and wait.

Put the frequency as a plain count ("3 of 5"), not a percentage. With small playtest groups, percentages make one person look like a trend. If you want a sense of how many players a round needs before counts mean anything, see our guide on how many playtesters you need.

Keep suggestions separate from decisions

Players are great at noticing problems and often less reliable at solving them. When a tester says "add a tutorial popup", write it under Suggestions heard. The finding is that they did not understand something. You decide the fix. Sometimes the best fix is a level layout change, not a popup.

Choose one way to order the findings

McAllister lists several ways to structure findings: by research question, by level or section, by game feature, by the player's journey through time, or by severity from high to low. For most indie rounds, severity order is the most useful because it puts the work in priority order. If you tested a long build, ordering by the player's journey (first minute, first fight, first upgrade) can be easier to read.

A filled-in example

Here is a short example of a completed report for a fictional game, so you can see the level of detail that is enough. The game and numbers are made up for illustration.

Header. Ember Run, build 0.4.2, Windows. Round 3: first 15 minutes with new players. Sessions on two evenings. Written the next morning.

Purpose. Do new players learn the dash before the first elite enemy? Second round after moving the dash prompt from a text box to the first corridor.

Summary. Partly. Players who read the corridor prompt learned the dash, but most ran past it. Top findings: players miss the dash (High, 4 of 6), the upgrade shop icon reads as a settings menu (Medium, 3 of 6), one crash on alt-tab (Critical, 1 of 6). Next build: block the corridor with a gap that needs a dash, change the shop icon, fix the alt-tab crash.

Who played. Six players who mostly play action roguelikes (they named Hades and Dead Cells). Four remote with screen recording, two written reviews.

Finding 1: Players miss the dash. Area: first corridor and first elite. Severity High. Frequency 4 of 6. What happened: four players walked past the prompt while looking at the enemy ahead and never pressed dash until the elite killed them. Evidence: recordings at 2:10, 1:45, 3:02 and 2:30. Quote: "Wait, there's a dodge?" Suggestion heard: "Make the prompt flash." Decision: Fix now. Replace the prompt with a gap players must dash across, so learning the move is required to continue.

Finding 2: Shop icon reads as settings. Severity Medium. Frequency 3 of 6. Three players opened the shop by accident while looking for options, then closed it. Decision: Fix now, swap the gear icon for a coin bag.

Finding 3: Crash on alt-tab. Severity Critical. Frequency 1 of 6. Decision: Fix now.

What went well. Five of six players restarted after their first death without being asked. Two mentioned the hit sound unprompted.

Next round. Question: does the dash gap teach the move? Test with six new players who have not seen the game.

That is the whole report. It took less time to write than one of the sessions, and the next round now has a clear pass or fail check.

A lighter version for small rounds

When you only had two or three testers, or you are testing a single change, use this five-line version instead:

1. Build and question: [version, one-sentence question]
2. Answer: [Yes, No or Partly]
3. Biggest problem, with count: [finding, severity, 2 of 3]
4. One thing that worked: [moment players enjoyed]
5. Change for next build: [one change and what you expect it to fix]

Keep these short reports in one running document, newest at the top. After a month you have a history of every round, which is gold when you write a devlog, a Steam update or a pitch.

Turning different kinds of feedback into findings

Your notes will come in different shapes. Here is how each one feeds the template.

• Observation notes from live sessions: these are your strongest evidence for "what happened". Copy timestamps straight into the Evidence field.
• Survey answers: count answers to the same question and put the counts in Frequency. Our list of playtest survey questions is built so answers are easy to count.
• Written reviews: pull out the moments the reviewer describes and treat each one as a possible finding. Quotes go in the Player quote field.
• Video reviews and livestreams: watch at double speed and note the timestamp every time the player stops, dies, reads something twice or says something out loud. Video is where you see the problems written reviews leave out.
• Vague comments: "it was fun" or "felt off" are not findings yet. Look for the behaviour behind them, or ask a follow-up. Our guide on vague playtest feedback has prompts for exactly this.

If your feedback is coming from testers you never meet, our remote playtesting guide covers how to get recordings and timestamps you can use as evidence.

Mistakes that make playtest reports useless

• Writing the report a week later. Write it within a day of the last session while you can still remember why a note mattered.
• Leading with opinions. If the first line of a finding is a design idea, rewrite it as what players did.
• Reporting everything at the same volume. Twenty findings with no severity is a to-do list, not a report. Rank them.
• Counting the same person twice. If one tester mentioned the same issue three times, the frequency is still 1.
• No decision column. A report without decisions just postpones the hard part. Every finding gets Fix now, Fix later, Watch or Won't fix.
• No check next round. If you do not write down what each change should fix, you cannot tell whether it worked.
• Hiding the good news. The What went well section tells you what not to break while you fix everything else.

Where the playtest reports come from

A template only helps if you have players to fill it with. You need people who would actually play your kind of game, and you need them to say specific things.

On Get Playtests, players pick your game from the open playtests because it looks like something they want to play, and you set the focus questions they answer. Reviews come back as written notes, videos or livestreams, which map straight onto the Evidence and Player quote fields above. Posting is free, with no credit card. Post your playtest free and use this template for the first round of reviews you get back.

If you still need more sources of testers, our guide on how to find playtesters covers communities, swaps and platforms, and where to post your game for feedback covers the subreddit and Discord rules you need to know before posting.

Common questions about playtest reports

How long should a playtest report be?

As long as it needs to be for someone who was not there to understand what happened and what you decided. For a small indie round that is usually one or two pages. Bigger rounds with many findings can run longer, but keep the summary to a few lines at the top so it can be read on its own.

Should I include every single note?

No. Group repeated notes into one finding and put the rest in a raw notes appendix or a link. The report is for decisions. The raw notes are for when you need to check something.

Is a playtest report the same as a bug report?

No. A bug report describes one defect so it can be reproduced and fixed. A playtest report covers what players experienced, including bugs, confusion, difficulty and fun, and records what you decided to change. Crashes from a playtest can go straight into your bug tracker, with the report pointing to them.

What tool should I use?

Whatever you already open every day. A Google Doc, a Notion page or a Markdown file in your repo all work. The structure matters more than the tool. If you track tasks in Trello, Jira or GitHub Issues, McAllister's advice is worth following: ask how the findings will be used and make it easy to move each one into the task tool.

How do I write a playtest report for a board game or tabletop game?

Use the same template. Replace the build number with the rules version, and record which rules players misread or skipped under What happened. The severity scale still works: a rule nobody understands is High, a confusing card wording is Medium.