# Make one change you can learn from

BerryBlox creator resources
Edition 1.0 · November 5, 2026

A repeatable recipe for moving from a messy observation to a focused change and an honest keep-or-revise decision.

Take away: One documented experiment with a useful next decision.
Beginner · 5 min read

Original BerryBlox editorial worksheet. You may copy, adapt, and use it in your own projects and team handoffs. Linked sources and third-party materials retain their own terms.

Download this Markdown file and fill it in with any text editor. Your notes stay in your copy; this worksheet does not upload or save them to BerryBlox.

## Collect 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.