Build versioned rules and components, observe real playtests, retest focused changes and prepare a complete playable package with retained evidence.
Write the intended players, player-count range, interaction, decisions and type of ending. Choose a design question for the first prototype, such as whether a trade creates a meaningful choice or whether players can explain scoring. List constraints on table space, reading, handling and components before committing to production art.
Create only the components needed to exercise the question and make each piece identifiable. Write setup, turn sequence, legal actions, end conditions and scoring so the game can reach an outcome. Keep a component inventory and a version label on the rules and prototype. Use clear type, sufficient contrast and cues beyond color for important distinctions.
Walk through a complete game and deliberately test resource shortages, ties, simultaneous effects and empty decks or markets where applicable. For each ambiguous situation, write the current rule and expected resolution. Use the matrix tool with prototype version, player/configuration label and rule test to record actual outcomes.
Give the same versioned rules and setup materials to the test group. Choose whether this session tests a taught game or independent rule comprehension, and record that condition. Observe choices, waits, questions, errors and the ending; ask neutral follow-ups afterward. With participants’ agreement, retain only the notes or recordings needed for the design decision.
Group evidence into rules clarity, interaction, pacing, accessibility and balance questions. Choose a focused change, update the rules and component version, and explain the intended effect. Retest the original problem and related cases under a new prototype label. Compare different player counts and relevant player experience rather than merging unlike sessions into one verdict.
Assemble the current rulebook, component list, setup example, playable files or physical prototype and known open questions. Verify another group can identify the materials, set up and reach a valid ending under the intended teaching condition. If approaching a publisher or manufacturing partner, follow that recipient’s current submission/specification requirements and obtain quotes from the actual component design.
Loading your checklist…
Keep enough context to interpret a result.
| Record | Details |
|---|---|
| Version | Rules and components used, with changes since the prior run |
| Group | Player count and relevant experience; avoid unnecessary personal data |
| Condition | Taught or independent rules, setup and design question |
| Observation | Choices, confusion, waits, errors, ending and direct comments |
| Decision | Specific revision, intended effect and next test |
A recipient should be able to identify and run the current design.
| Artifact | What it should resolve |
|---|---|
| Rules | Setup, turn structure, legal actions, ending and scoring |
| Components | Inventory, IDs and readable distinctions |
| Example | A worked turn or scoring situation that removes a real ambiguity |
| Evidence | Tested version, unresolved questions and revision history |
Use these records as an original working method. No mandatory framework, fixed playtest count, universal session duration or automated balance verdict is assumed. Check the intended recipient’s current requirements before sending a submission.
Write the expected effect before the next test so you can compare observations.
A rulebook problem and a balance problem may need different sessions and different evidence.