Make one change you can learn from
A repeatable recipe for moving from a messy observation to a focused change and an honest keep-or-revise decision.
One documented experiment with a useful next decision.
Completed example
Original fictional example. These are filled-in worksheet answers, not evidence of a built or tested game.
Move the basket, keep the rest of the route
- Symptom
- Illustrative playtest note: a player returned with fruit but searched side paths before finding the basket.
- Hypothesis
- Moving the basket into the return sightline may make the destination easier to notice. This is a hypothesis, not a confirmed cause.
- One change
- Move only the basket. Keep the spawn, camera, instruction, fruit locations, and delivery rules unchanged. Save the previous placement.
- Compare
- Repeat the same arrival-to-delivery route and record where the player looks or hesitates. Identify the version and test conditions for both captures.
- Decision rule
- Keep the change only if the basket is easier to find without blocking movement. Otherwise restore or revise it, and record why. No result has been observed in this fictional example.
Expected resultA reversible experiment with one changed variable, a repeatable observation, and an explicit keep-or-restore decision.
Try it in your blank worksheetCollect the symptom before the solution
Choose one observed problem and retain its starting state, route, and evidence. Write what happened without assuming the cause. 'The tester walked past the basket twice' is more useful than 'the tutorial is bad' because another person can inspect it.
Choose a single question for this iteration. If several problems block the same route, fix the earliest blocker first so later observations have a meaningful starting point.
- Build / starting save / route
- Observed player action / expected cue
- Evidence file and timestamp
- Question this iteration should answer
Choose the smallest plausible change
State a hypothesis and one change that could test it. Preserve a copy of the current build and write a stop condition before editing. Avoid bundling a new layout, new economy, and new tutorial into the same experiment when you need to understand which change helped.
Name one adjacent behavior that must continue working. A more visible objective marker is not useful if it blocks the touch control or points to a hidden object.
Illustrative recipe: if a low-contrast basket is the reason players miss the destination, increase its silhouette contrast while keeping position and reward unchanged. Repeat the arrival route with a fresh tester. A better result is evidence for this hypothesis, not proof that every player will understand the game.
- The hypothesis can be contradicted by an observation.
- The proposed change has one owner and a bounded scope.
- The previous build can be restored.
- An adjacent behavior has an explicit regression check.
- Hypothesis / change / owner
- Keep condition / revise condition / stopping condition
- Preserved behavior / restore point
Repeat the route and keep the comparison fair
Use the same task, starting save, and environment where possible. Record any differences rather than hiding them. Let the player use normal input without coaching the solution. Capture the complete action and recovery, including an unsuccessful attempt.
When comparing timings, define the same start and end event and keep interruptions visible. Do not turn one faster attempt into a percentage performance or conversion claim. Small sessions often reveal usability problems more reliably than they estimate population-wide effects.
- Before build / after build / shared starting state
- Task and input used
- What changed in test conditions
- Observed result / evidence / adjacent check
Keep, revise, or restore with a reason
Compare the evidence with the decision condition you wrote earlier. Keep a useful change, revise an unclear one, or restore the prior version if the change harmed the route. Record uncertainty as uncertainty; an inconclusive session still tells you how to design the next check.
Leave the next session a concrete question and its smallest useful task. Save the selected source and evidence together so another owner can continue without reconstructing the whole conversation.
- The decision cites an actual observation.
- Failed cases and unresolved limits remain visible.
- The selected build and evidence can be located.
- The next task has an owner and a pass condition.
- Decision / reason / confidence
- Selected source / remaining gap
- Next question / smallest task / next owner
Evidence and limits
This original recipe organizes an iteration. It does not run a playtest, validate an experiment statistically, or establish retention, revenue, or device performance. Use the companion playtest worksheet when you need a fuller session record.
You may copy, adapt, and use this BerryBlox worksheet in your own projects and team handoffs. Examples are fictional and include no licensed source, production artifacts, or private player information.