Get feedback you can actually build from
Give a tester one task, observe without coaching, and turn a finding into a small next step.
First Play Studios · Edition 1 · Updated November 14, 2026
Three observations and one improvement with an observable success check.
Before you start- A small playable build or paper prototype
- One willing tester and a way to take notes
In this guide
Choose one question
A first test does not need to judge the whole game. Choose a question such as ‘Can someone work out where to deliver the parcel without my help?’ Make sure the build contains enough of that experience to answer it. If pickup is still broken, a test about delivery clarity will mostly reveal the pickup bug.
Give the tester a short task and the controls they genuinely need. Avoid explaining the intended solution. For a clarity test, ‘Try to finish a delivery’ leaves room to observe discovery. ‘Pick up the parcel on the left and walk to the glowing table’ answers your own question before the test begins.
Separate observation from interpretation
Write what happened first: ‘The tester returned to the door twice and never approached the workbench.’ Then write a possible explanation: ‘The destination may be unclear.’ The observation is evidence; the explanation is a hypothesis. There may be another cause, such as an unreadable label or a camera angle that hides the table.
Pause if the person is uncomfortable or wants to stop. Ask permission before recording audio or video; written notes are enough for this exercise. After the attempt, ask what they expected to happen, where they felt uncertain, and what helped. A person’s suggestion is useful input, but you still choose the design change.
Turn one finding into a new test
Choose an issue that blocks the task. Propose the smallest experiment that addresses it, such as a destination label visible before pickup. Define a success check: ‘A fresh tester reaches the workbench without spoken hints.’ Try the changed build with the same task.
One tester can reveal a problem but cannot establish how every player will behave. Keep the build version and date beside each observation so results from different versions do not blur together. Over time, compare repeated patterns and investigate conflicting feedback instead of averaging everything into a score.
Run a five-minute delivery test
- Write one question, one tester task, and the build version.
- Observe the attempt without explaining the route; note pauses, repeated actions, and unexpected choices.
- Ask ‘What did you expect?’ and ‘Where were you unsure?’ after the attempt.
- Choose one observation, one proposed change, and one success check for the next test.
Check your result.
- Your notes distinguish observed behavior from your interpretation.
- The next task is small enough to build and compare.
- You have not treated one person’s response as a universal result.
Common mistakes to watch for.
- Coaching every action and then concluding that the interface is clear.
- Collecting a long wish list without identifying the problem each request addresses.
Keep the conversation useful.
Help me turn these playtest observations into one next task. Separate observations, interpretations, and suggested solutions. Keep the original test question in view. Suggest a small change and an observable success check, and flag where one test is insufficient evidence.
Sources & version notes.
Original First Play Studios playtest worksheet. This is a practical starting method, not a validated research protocol.
This worksheet is an original First Play Studios exercise.
Practice times are estimates. Software-specific exercises are documentation-based unless their version note says otherwise.A question or a small win?
Tell the workshop what happened when you tried this guide. Ask for a useful next step, or share something you got working.
See discussions about this guide We’ll include the guide link in your draft. Sign in to post, then add your own question or progress before sharing.