Appendix D: Playtesting Protocol Templates
Chapter 31 argued that playtesting is the single most important skill a designer can develop, and that most designers underinvest in it because it is uncomfortable, time-consuming, and humbling. That chapter gave you the why and the methodology. This appendix gives you the forms. It is the operational manual you flip open the morning of a playtest when you realize you need a consent form, a pre-test script, an observation template, and an aggregation spreadsheet, and you do not want to invent them from scratch while a tester is driving to your office.
Every template here is meant to be copied. Open the appendix, highlight the block you need, paste it into a Google Doc, adapt the placeholders, go. Nothing in this appendix is sacred. A template that does not serve your project is a template you should throw out. But starting from something is almost always better than starting from nothing, and most designers freeze in the gap between "I should probably run a playtest" and "I have all the materials ready to go." These templates close that gap.
One note before the forms: if you skipped Chapter 31 and came straight here, go back and read it. The templates will make no sense divorced from the methodology. You will run a technically correct protocol that produces no design insight, because the methodology is what tells you what to do with the data. This appendix is the hammer and the nails. Chapter 31 is the house plans.
Playtest Recruitment Templates
Recruiting testers is the bottleneck. Most beginning designers discover this the first time they try to playtest and realize they have no one to test with. Budget more time for recruitment than you think you need. A rule of thumb: every 10 testers you want to run through a session costs you roughly a week of part-time recruiting effort, between posting, pre-screening, scheduling, and no-shows.
Two versions of recruitment copy follow — one for acquaintances (weaker signal, easier to schedule), one for strangers via forums or Discord (stronger signal, harder to book).
Template — Recruitment Message to Acquaintances
Subject: Would you playtest my game? (~45 minutes, paid)
Hey [Name],
I'm looking for playtesters for [Game Title], a [genre]
I've been building for [X months/years]. I'm at a stage
where I need feedback from people who are NOT in my head
about the game — which is why I'm reaching out to you
specifically: you play [similar games], and you tend to
say honest things, which is what I need.
The session is ~45 minutes, either in person or over
Discord with screen sharing. I'll ask you to play, think
aloud while you do, and then I'll ask a few questions
afterward. No preparation needed.
Compensation: [$20 gift card / free copy of the game on
release / dinner / etc.].
Important ask: if you do this, I need you to be honest,
even if things are bad. Polite-but-honest is fine.
Encouraging-but-vague is not useful to me. I'd rather
you tell me the combat feels bad than tell me it was
nice.
Dates that work on my end:
- [Date/time option 1]
- [Date/time option 2]
- [Date/time option 3]
Let me know?
Thanks,
[Your name]
The critical line is the "polite-but-honest is fine" sentence. Acquaintances will default to kindness. You must explicitly grant permission to criticize or you will get love-filtered feedback, which is not feedback.
Template — Recruitment Post for Strangers (Discord, Forum, Subreddit)
Subject: [PLAYTEST] Looking for 10 testers for [Genre]
game — compensated, ~45 min
Hi all,
I'm [Your Name], an independent developer working on
[Game Title], a [one-sentence description]. I'm looking
for ~10 playtesters for a remote session later this
month.
WHAT YOU'D DO:
- Install a dev build (PC/Mac/Linux, ~[size]MB).
- Hop on a Discord call with me, share your screen,
and play for ~35 minutes while thinking aloud.
- Answer some questions afterward (~10 minutes).
Total time: ~45 minutes.
COMPENSATION:
- $20 USD gift card (Steam, Amazon, or equivalent), OR
- A free copy of the game when it releases, OR
- Both, if your session runs long.
WHAT I'M LOOKING FOR:
- Players who enjoy [specific genre/comparables].
- Mix of experience levels (brand-new to veteran).
- Mix of input types (controller, keyboard).
- You are NOT already involved in my development or
personal network — I need fresh eyes.
WHAT I'M NOT LOOKING FOR:
- QA bug hunters (I have a separate process for that).
- People looking to give marketing advice.
- Reviewers / streamers (different conversation; happy
to chat, but this is playtesting, not coverage).
IF INTERESTED:
Reply here or DM me with:
1. Your gaming background (favorite games, hours/week).
2. Time zone + general availability.
3. Input preference (controller/keyboard).
I'll get back to you within 48 hours. Thanks!
[Your Name]
The key phrase "you are NOT already involved in my development" does more work than it looks like it does. Friends of friends will answer these posts. You want to catch that before you have booked them. A tester who knows someone on your team is already partially spoiled.
Compensation Norms
- $20–$50 gift card is standard for a 45-minute remote session in North America or Western Europe. Lower in regions with lower cost-of-living; ask locally.
- Free copy of the shipped game costs you nothing and is valuable to enthusiasts; stack it with cash for best results.
- Early access to future builds is attractive to hardcore fans but has logistical cost (tracking who has access, handling NDA).
- Nothing is acceptable only for volunteer communities (game-dev clubs, indie friends) where the exchange is tacitly reciprocal. Even then, pizza helps.
- PlaytestCloud and similar services handle compensation for you at $30–$100 per tester; factor this in when deciding build-vs-buy.
Demographic-Question Framing
When pre-screening, avoid framing demographic questions as judgment. The goal is diversity along axes relevant to your game.
QUICK BACKGROUND (optional but helpful):
1. How many hours/week do you play games on average?
[ ] < 2 [ ] 2–5 [ ] 5–15 [ ] 15+
2. Which of these have you played? (Any you have
enjoyed.)
[ ] [Comparable 1]
[ ] [Comparable 2]
[ ] [Comparable 3]
[ ] [Adjacent genre]
[ ] None of the above — this would be a new genre
for me.
3. Preferred input:
[ ] Controller [ ] Keyboard + mouse [ ] Touch
4. Anything I should know to run a good session for
you (accessibility needs, motion sickness
sensitivity, content preferences)?
Mark everything optional. Some testers will skip demographic questions on principle; that is fine. You want the willing, not the compliant.
Consent and Recording Form
You are recording a person. In most jurisdictions, informed consent is ethically mandatory and often legally mandatory. Keep the form short, respectful, and unambiguous.
=======================================================
PLAYTEST CONSENT AND RECORDING FORM
[Game Title] — [Date]
=======================================================
Thank you for helping test [Game Title]. Before we
begin, please read and acknowledge the following.
1. OBSERVATION
I will watch you play and take notes. I may ask
questions during play.
2. SCREEN AND AUDIO RECORDING
With your permission, I will record your screen and
our conversation. Recordings help me review
sessions later and compare across testers. I will
NOT share recordings publicly or with anyone outside
the development team. Recordings will be deleted
within 12 months.
[ ] I consent to screen recording.
[ ] I consent to audio recording.
[ ] I do not consent; please take notes only.
3. USE OF FEEDBACK
I may quote your comments or describe your behavior
in internal design discussions, post-mortem
write-ups, or public articles/talks about the
development process. Quotes will be anonymized: no
name, no identifying details, unless you explicitly
agree otherwise.
[ ] You may quote me anonymously.
[ ] You may quote me by first name only.
[ ] You may credit me fully.
[ ] Do not quote me.
4. RIGHT TO WITHDRAW
You can stop the session at any time, for any reason,
without explanation. You will still receive the
agreed compensation. You can ask me to delete
recordings or notes at any time up to 30 days after
the session.
5. NO TEST OF YOU
The purpose is to evaluate the game, not to evaluate
you. There are no right answers. Confusion, mistakes,
and frustration are valuable data — they tell me
where the game is unclear, not where you are wrong.
Signature: _________________________ Date: _________
Printed name: ______________________
=======================================================
For remote sessions, an email acknowledgment with these bullet points is generally sufficient in most jurisdictions. Do not wing it; look up the rules where you live, especially if you are recording testers who live in the EU (GDPR applies).
Pre-Test Briefing Script
You read this to every tester at the start of every session. Scripting it ensures each tester hears the same framing, which makes their data comparable. Memorize the structure; the exact words can adapt.
=======================================================
PRE-TEST BRIEFING SCRIPT
=======================================================
"Thanks for being here today. Before you start playing,
I want to walk you through how this is going to go.
FIRST: this is a test of the GAME, not a test of you.
There are no right answers. If something is confusing,
that's information for me — it means the design needs
work. If you get stuck, that's good data. If you quit, I
learn something. You can't fail this.
SECOND: please think out loud while you play. Whatever
is in your head — 'I'm looking for the door,' 'I think
this enemy is going to attack,' 'I don't know what that
icon means' — just say it. I know it feels weird at
first. Keep doing it anyway. The running narration is
the most valuable thing you can give me.
THIRD: I am mostly going to be quiet. I will NOT help
you, even if you're stuck. This is on purpose — I need
to see what a new player does when they can't figure
something out. If you're stuck for more than a few
minutes and getting frustrated, I might give you a
small hint, but only if I see it affecting your mood. I
promise I'm not being cruel.
FOURTH: if you want to quit at any point, for any
reason, just say 'I'm done.' No questions asked. You
still get compensated.
Any questions before we start?
[Pause. Wait for questions. Answer briefly.]
Great. I'm starting the recording now. The game is
[already launched / going to launch when you press
Play / etc.]. Take a moment to get comfortable with the
controls, and whenever you're ready, go ahead."
=======================================================
That script takes 90 seconds to deliver. It saves you 30 minutes of confusion later, because the tester knows what to expect and you have not accidentally primed them by improvising.
Think-Aloud Protocol Cue Sheet
Think-aloud is the single most productive data-collection technique in playtesting, and it is also the one testers are most likely to forget to do. Within 30 seconds of play, they will go quiet. Your job is to gently re-prompt without leading.
Prompts That Work
- "What are you thinking right now?"
- "What did you expect to happen?"
- "What are you trying to do?"
- "What do you notice on the screen right now?"
- "Walk me through what you're seeing."
- "What do you think that icon / button / enemy
does?"
- "You just [did a thing]. What was going through your
head?"
- "How are you feeling about [specific moment]?"
Each of these is open. None of them contain the answer.
Prompts That Do Not Work
- "Did you see the sign?"
- "You were supposed to jump there, right?"
- "Good job!"
- "That's a bug, sorry."
- "Try pressing X next time."
- "Most players figure it out by now."
Every one of those corrupts the session. "Did you see the sign?" tells the tester a sign existed and they missed it, which is useful data you just destroyed. "Good job!" turns the tester into a performer trying to please you. "That's a bug, sorry" makes the tester doubt their own impressions of everything subsequent. "Most players figure it out by now" is cruelty. Do not do these.
When You Must Intervene
Sometimes a tester is truly stuck, visibly distressed, or about to quit in frustration. A small hint is acceptable — but frame it as a release, not a correction.
- "If you want a hint, I can give you one." (Let the
tester opt in.)
- "Take a break if you want; there's no time
pressure."
- "You can skip this section if you'd like; I have
a way to move you forward."
Notice that even the hint offer puts the tester in charge. The session is theirs; you are the facilitator.
Observation Note Template
You will take notes during the session. You will not remember what you meant by "weird moment around the cave" three days later. Structured notes make findings comparable across testers. A simple table, printed or on a second screen, works well.
=======================================================
OBSERVATION NOTES — [Tester ID] — [Date]
=======================================================
| Time | Behavior | Words | Interpretation | Sev | Category |
|-------|--------------------------|--------------------|-------------------|-----|----------|
| 00:47 | Walked past NPC twice | "Hmm, anyone here?"| Missed interact | 2 | UX |
| 02:15 | Held jump, didn't dash | (silent) | Didn't know dash | 3 | Design |
| 04:30 | Died to spike | "Oh what?!" | No spike telegraph| 3 | Design |
| 05:22 | Found hidden room | "Ohhh nice!" | Intended moment | - | Positive |
| 07:10 | Opened inventory | "Can I use this?" | Item use unclear | 2 | UX |
| ... | ... | ... | ... | ... | ... |
Severity scale:
1 = Minor (nice-to-know)
2 = Meaningful (real friction)
3 = Critical (breaks experience or progression)
Categories:
Bug — technical failure
UX — interface / affordance / clarity issue
Design — gameplay mechanic or system issue
Content — narrative / level / balance issue
Positive — moment of delight (track these too)
=======================================================
One row every time something happens. Do not try to write prose. Cryptic shorthand is fine; you will transcribe immediately after the session while memory is fresh. The severity rating forces you to distinguish the earth-shattering from the nitpick, which will matter when you triage findings later.
Tracking positive moments is critical and most beginners forget. You need to know not just what broke, but what worked — because when you revise, you must not accidentally destroy the moments of delight while fixing the moments of failure.
Kleenex Test Protocol (First Five Minutes)
Chapter 31 introduced the kleenex test — so named because each fresh tester is, like a kleenex, single-use. Once they have played the first five minutes, they can never again be a first-time player of your game. The kleenex test is specifically for onboarding: tutorial, opening sequence, first-moments-of-play. It is the highest-leverage test in all of game development for most games, because the first five minutes is where the majority of potential players decide whether to continue.
Protocol
=======================================================
KLEENEX TEST PROTOCOL
=======================================================
OBJECTIVE:
Evaluate the first five minutes of play. What does the
fresh tester understand? What do they struggle with?
Where are they by minute 5?
RECRUITMENT:
- Fresh testers only. No one who has played any build,
seen any gameplay video, or read your Steam page.
- 10 fresh testers per round.
- Brief demographic screen (fits target audience).
BUILD:
- The actual opening of the game — title screen, any
intro cutscene, tutorial (if any), first real
gameplay.
- Build must be stable for the first 10 minutes.
Beyond 10 minutes can be janky.
SESSION LENGTH:
- 15 minutes total. 5 minutes setup + 5 minutes play +
5 minutes debrief.
PRE-TEST SCRIPT (abbreviated for kleenex):
"You're about to play the opening of a game I'm
making. Play for about 5 minutes. Think out loud the
whole time — what you're seeing, what you're
thinking, what you're trying to do. I won't help you.
When I say stop, stop wherever you are."
DURING PLAY — WATCH FOR:
1. Does the tester press Play / Start without help?
2. Do they understand how to move in the first 30
seconds?
3. Do they understand the objective by minute 1?
4. Do they discover the primary mechanic by minute 2?
5. Do they reach the first gameplay moment by
minute 3?
6. What is their facial expression at minute 4?
7. Have they quit, gotten stuck, or engaged by
minute 5?
POST-PLAY QUESTIONS (5 minutes):
1. In one sentence, what is this game about?
2. What were you trying to do for the first 60
seconds?
3. What, if anything, confused you?
4. Would you keep playing if you had the chance?
Why or why not?
5. What did you think the [primary mechanic] does?
FINDINGS WORTH TAKING SERIOUSLY:
- Any moment 3+ testers out of 10 get confused by the
same thing.
- Any moment where testers' guess about the mechanic
does not match the designed intent.
- Any moment where 3+ testers say "I wasn't sure what
to do" in debrief.
=======================================================
Run this round monthly for the first six months of production and you will ship with an onboarding that works. Skip it, and you will discover on launch day that half your players quit in the tutorial, which is what happens to most first-time indie developers.
Post-Test Interview Script
The debrief interview happens after the session, for ~10–15 minutes. Its purpose is to surface the things you did not see — the internal experience of the tester that did not show up on screen or in their think-aloud. Structure is key; freewheeling interviews drift into the tester restating what already happened.
=======================================================
POST-TEST INTERVIEW SCRIPT
=======================================================
1. OVERALL EXPERIENCE (3 questions)
"Thanks for playing. Now I want to hear your big-
picture reactions. There are no right answers."
Q1: "In one sentence, how would you describe the
experience you just had?"
Q2: "What was the best moment of the session for you?
Why was it the best?"
Q3: "What was the worst moment? Why?"
2. SPECIFIC MOMENTS (2 questions per key moment;
plan ahead)
"I want to ask about a couple of specific moments I
noticed."
Q4: "At [specific moment X], you [did a specific
thing]. What was going through your head?"
Q5: "What did you expect to happen at [moment X]?"
Q6: "When [moment Y] happened, how did you feel?"
Q7: "What did you think [mechanic Z] was for?"
3. OPEN QUESTIONS (2 final)
Q8: "If you could change one thing about what you
played, what would it be? Why?"
Q9: "Is there anything I haven't asked that you want
to tell me?"
=======================================================
Notice what is NOT on the list: "Did you like it?" That question produces a one-word answer filtered through politeness, and you learn nothing. Also not on the list: "Would you recommend this to a friend?" That is a survey question, not an interview question. In a live interview, it triggers performance behavior.
The substitution that actually works is "what were you thinking when X?" That question presupposes the tester had an inner experience and asks them to narrate it. You will get richer data from five "what were you thinking when" questions than from twenty "did you like it" questions.
Survey Template for Asynchronous Playtests
Not every playtest requires a live observer. For remote or asynchronous rounds (where the tester plays on their own time and fills out a survey afterward), use Google Forms, Typeform, or similar. Keep it to 10–15 questions; longer surveys get abandoned.
=======================================================
ASYNC PLAYTEST SURVEY TEMPLATE
[Game Title] — Round [X]
=======================================================
1. How many hours did you play this build?
[ ] < 30 min [ ] 30 min–1 hour [ ] 1–2 hours
[ ] 2–4 hours [ ] 4+ hours
2. On a 1–10 scale, how much did you enjoy the
experience? (1 = hated it, 10 = loved it)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
3. How likely are you to recommend this to a friend
who enjoys [genre]? (0 = not at all, 10 = extremely)
[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
4. Which checkpoint did you reach before stopping?
[ ] Tutorial
[ ] Checkpoint 1
[ ] Checkpoint 2
[ ] Checkpoint 3
[ ] First boss
[ ] Past first boss
[ ] [Other key markers specific to your game]
5. In one sentence, what is this game about?
[Text field]
6. What was the best moment of your experience?
[Text field]
7. What was the worst moment? Where did you get
stuck, bored, or frustrated?
[Text field]
8. Rate the difficulty of what you played:
[ ] Way too easy
[ ] A little easy
[ ] About right
[ ] A little too hard
[ ] Way too hard
9. Rate the clarity of what to do:
[ ] I always knew what to do
[ ] I usually knew
[ ] I sometimes knew
[ ] I was often confused
[ ] I was almost always confused
10. Did the controls feel good?
[ ] Felt great
[ ] Felt fine
[ ] Felt off but I got used to it
[ ] Felt bad the whole time
[ ] Other: ______________
11. If you stopped before the end of the build, why?
[Text field]
12. What, if anything, surprised you?
[Text field]
13. Demographics (optional):
- Age range
- Hours/week gaming
- Platform played on
14. Anything else you want me to know?
[Text field]
=======================================================
Surveys give you quantitative patterns across many testers fast. They do not give you the qualitative why that a live session gives you. The ideal playtest round is a mix: 3–5 live sessions for qualitative depth, 20+ async surveys for quantitative breadth.
Findings Aggregation Template
After 3–10 sessions, you have a pile of notes and need to distill them into actionable findings. The temptation is to fix whatever the last tester complained about. Resist. Aggregate first. Look for patterns.
=======================================================
FINDINGS AGGREGATION TABLE
Round [X] — [Date range]
Testers: [N] total
=======================================================
| # | Finding | # Testers | Severity | Category | Proposed Fix | Status |
|----|----------------------------|-----------|----------|----------|--------------------------|---------|
| 1 | Missed interact prompt | 7/10 | 3 | UX | Larger icon, brighter | To-do |
| 2 | Dash tutorial unclear | 6/10 | 3 | Design | Add in-game text prompt | In prog |
| 3 | Second boss too easy | 5/8* | 2 | Content | +20% HP, faster attack | To-do |
| 4 | Menu font too small | 4/10 | 1 | UX | +15% font size | Done |
| 5 | Enjoyed the waterfall area | 9/10 | - | Positive | Do more of this | Protect |
| 6 | Felt lost in the mines | 3/10 | 2 | Design | Add signposting | To-do |
| 7 | Inventory sort buggy | 2/10 | 3 | Bug | File QA ticket | QA |
| 8 | Wanted more dialogue | 2/10 | 1 | Content | (evaluate later) | Defer |
| 9 | Controller rumble too much | 1/10 | 1 | UX | Make opt-out in settings | To-do |
| 10 | Story confusing | 1/10 | ? | Content | (need more data) | Watch |
* Only 8 testers reached the second boss.
=======================================================
Number of testers who hit the finding is the most important column. A problem 7 out of 10 testers encountered is a real problem. A problem 1 out of 10 testers encountered might be a real problem, or might be idiosyncratic to that tester. Use the number to prioritize.
The "Status" column closes the loop — a finding without a status is a finding you will forget. Statuses I use: To-do, In prog, Done, Defer (deliberately not fixing this round), Protect (this worked, do not break), QA (handed off to bug-tracker), Watch (need more data).
Triage Matrix
Once you have findings, you cannot fix all of them. You need a decision framework. A 2×2 matrix of severity × cost gives you a fast triage.
=======================================================
TRIAGE MATRIX
=======================================================
CHEAP MODERATE EXPENSIVE
(< 1 day) (1–5 days) (> 5 days)
CRITICAL FIX NOW FIX NOW FIX OR CUT
(breaks exp) THE FEATURE
IMPORTANT FIX SOON FIX SOON SCHEDULE
(real FOR NEXT
friction) MILESTONE
NICE-TO-HAVE FIX IF IN DEFER CUT
(polish) FLOW
IGNORE LEAVE LEAVE LEAVE
(1 tester,
low sev)
=======================================================
The "FIX OR CUT THE FEATURE" cell is the honest one most developers flinch from. If a critical problem is going to cost more than a week of work, you must seriously consider cutting the feature that has the problem. Chapter 37's treatment of scope management is the relevant reference — sometimes the cheapest fix is removal.
The Playtest Retrospective
After a round of 3+ tests, do not immediately start fixing. Hold a retrospective — even with yourself, as a solo designer — to look for patterns.
What to look at:
-
Patterns across testers, not individual complaints. A single tester who hated the third level is a data point. Three testers who disengaged at the third level is a pattern. Chase the patterns.
-
Signal vs. noise. Some findings are noise — a tester's bad mood, a bizarre personal preference, a temporary bug that is not actually part of the design. Filter the noise before you react.
-
Where testers diverged. Sometimes two testers had opposite experiences of the same moment. That divergence is information: the design is probably reading differently to different player types, which may be intentional or may be a clarity problem.
-
Moments of delight. Protect these. The natural tendency of a fix-round is to edit the bad parts and accidentally sand down the good parts. Explicitly mark "this worked" findings as protected before you start editing.
-
When to ignore feedback. This is the hardest skill in playtesting. Some feedback is wrong. A tester's recommendation ("you should add a map") may be a misdiagnosis of their experience ("I felt lost"). Your job is to address the underlying experience, not to implement the literal recommendation. If the tester felt lost, maybe you add signposting, maybe you rebalance the level, maybe you reshape the exploration — a map is one of many possible solutions and often the worst one. The designer's vision comes back in here: you chose not to have a map for a reason; respect that reason unless the evidence says the reason was wrong.
The honest question to ask every retrospective: which of these findings would I be embarrassed not to have fixed if a player told me about them on launch day? Fix those. Defer the rest.
Remote Playtest Logistics
Remote playtests dominate indie production for cost and access reasons. Doing them well requires attention to logistics that in-person sessions handle invisibly.
Setup checklist:
- Discord or Zoom call, with screen sharing enabled on the tester's side.
- OBS or Zoom's built-in recording capturing both the tester's screen and audio.
- Tester's build installed and tested before the session. Run a 5-minute pre-session check a day earlier. Do not debug during the session.
- Tester on a wired connection if possible; Wi-Fi glitches corrupt screen-sharing framerate.
- Backup plan if tech fails: a Google Form survey the tester can fill in instead.
- Tester's microphone tested. Nothing kills a think-aloud session faster than an unintelligible mic.
Screen-share etiquette:
- Ask the tester to share their full screen, not just a window. You need to see notifications, alt-tabs, anything that breaks their flow.
- Ask them to mute notifications for the session.
- Explicitly confirm recording permission on camera at the start. "I'm about to start recording — is that still okay?" Get a verbal yes.
Tools by situation:
- PlaytestCloud — paid, handles recruitment + recording + reporting. Best for quick quantitative rounds.
- UserTesting.com — paid, similar, broader than games but covers UX.
- Lookback — recording tool for UX sessions; commonly used in research orgs.
- Discord + OBS — free combination that works for small indie teams; best for qualitative sessions with testers you recruited yourself.
- playable.world — browser-based playtest hosting; useful for games that can run in a browser.
Anonymizing: when you share session clips with a collaborator, crop out face cameras if you have them. When you quote a tester in post-mortems or talks, change or omit their name unless they opted in to credit. Default to privacy.
Ethics of Playtesting
Testers are people, not subjects. Treat them well.
Tester welfare. Session length matters. Nobody should be asked to play for more than 60 minutes without a break. Past the 90-minute mark, tester fatigue corrupts data; past the 2-hour mark, you are being rude. If you need longer sessions, schedule a break with water and a bathroom; if you need much longer, schedule a second session on a different day.
Sensitive-content warnings. If your game contains content that some testers would want to know about in advance — graphic violence, body horror, flashing lights, sexual content, depictions of self-harm, religious or political material — disclose it in the recruitment message, not after they have installed the build. Offer an opt-out without penalty. This is basic respect and in many regions it is legally required.
Age-appropriate recruiting. If your game's rating is M / 17+, do not playtest with minors. If your game's target audience is children, recruitment requires parental consent and stricter ethical care; consult the research ethics guidelines for minors in your jurisdiction. Do not improvise this.
Data handling. Recordings of human subjects are sensitive data. Store them in access-controlled folders. Do not email them around casually. Delete them on a schedule (12 months is a reasonable default). If a tester asks you to delete their data, delete it. If you operate in the EU or handle EU residents' data, GDPR applies and the rules are stricter; look them up.
Crediting testers. Ask each tester whether they want to be credited in the final game. Many will say yes and be thrilled. Some will say no; respect that. If you say "you'll be credited," credit them. The credits-reel tester list is a small gesture that builds a real community.
Compensation fairness. Pay what you promised, on time. Do not string testers along on "I'll send the gift card when the game ships." Do not offer "exposure" as compensation. Indie means scrappy; indie does not mean exploitative.
Templates as Copy-Paste Blocks
For convenience, here are the recruitment email, consent form, pre-test briefing, and post-test interview as clean copy-pasteable blocks. Highlight, copy, adapt.
Copy-Paste Block 1 — Recruitment Email (Strangers)
Subject: [PLAYTEST] Looking for 10 testers for [GAME]
— $20 compensation — ~45 min
Hi all,
I'm [Name], building [Game Title], a [one-sentence
description]. Looking for ~10 playtesters for a remote
session this month.
WHAT: Install a dev build, hop on Discord, play for
35 min while thinking aloud, answer questions after
(~10 min). ~45 min total.
PAYS: $20 gift card + free copy on release.
LOOKING FOR: Players who enjoy [comparable 1],
[comparable 2]. Mix of experience levels. Not already
in my dev network.
IF INTERESTED: DM me with (1) games you've enjoyed,
(2) time zone, (3) controller or keyboard. I'll reply
within 48 hours.
Thanks!
[Name]
Copy-Paste Block 2 — Consent Form (Short Remote Version)
Before we start, please confirm:
[ ] I consent to screen recording for internal review.
[ ] I consent to audio recording.
[ ] I understand I can stop at any time.
[ ] I understand any quotes will be anonymized unless
I specify otherwise.
Recordings will be deleted within 12 months. They will
not be shared publicly. You can request deletion at any
time up to 30 days after the session.
Reply "Yes to all" or tell me which box you'd rather
uncheck.
Copy-Paste Block 3 — Pre-Test Briefing (90 seconds)
"Thanks for being here. Three things before we start.
One: this is a test of the GAME, not you. Confusion,
mistakes, getting stuck — that's all useful data.
You can't fail.
Two: please think out loud while you play. Whatever
is in your head, say it. I'll remind you if you go
quiet.
Three: I won't help you, even if you're stuck. I need
to see what a real new player does. If I think
you're suffering, I'll offer a hint you can take or
leave.
You can quit any time by saying 'I'm done.' No
questions asked.
Starting the recording now. Whenever you're ready,
go ahead."
Copy-Paste Block 4 — Post-Test Interview (10–15 min)
"Thanks. Some quick questions.
1. In one sentence, how would you describe the
experience you just had?
2. What was the best moment?
3. What was the worst moment?
4. At [specific moment], you [did a specific thing].
What were you thinking?
5. What did you expect to happen at [moment]?
6. When [other moment] happened, how did you feel?
7. What did you think [mechanic] was for?
8. If you could change one thing, what would it be?
9. Anything I haven't asked that you want to tell me?
Thanks — this was incredibly useful. I'll send your
compensation within 24 hours. Cheers."
Four blocks. Copy, paste, adapt, run the session. You have everything you need to go from "I should probably playtest" to "I am running a playtest right now" in about 20 minutes of setup. That is the gap this appendix exists to close.
Chapter 31 told you playtesting is the highest-leverage skill a designer can develop. This appendix gives you no excuse not to start.