A brief for the next playable milestone
Use these prompts in your project notes. Answer what you can and mark unknowns plainly. The brief should help someone understand the requested experience and the evidence you need next; it does not need to prescribe an engine or implementation.
1. Who will play, and in what setting?
Describe relevant experience, available input, likely session length, and whether play is supervised. Identify target platforms and the devices you can actually provide for review. Avoid replacing this with “everyone”: that makes control, reading, difficulty, and testing decisions harder.
2. What does the player repeatedly do?
Write a short sequence of choice, action, feedback, and consequence. Separate the immediate activity from larger rewards or unlocks. If the game has a learning purpose, identify the observable task and the person responsible for checking its accuracy.
3. Where does this milestone begin and end?
Specify entry, included section, available actions, success or failure, restart, and exit. Say whether progress survives leaving. Name absent systems, such as online accounts or additional levels, so they do not become implicit promises.
4. What already exists?
List builds and source revisions, engine and plugin versions where known, editable assets, content, and rights records. Mark temporary and unavailable materials. For inherited work, note whether someone can reproduce the build and which access is missing.
5. What question or blockage matters most?
Provide a concrete example. “Players cannot tell which bridge is selected” gives the team a starting point. “Improve engagement” needs more discussion. Separate observations from your suggested solution; the same symptom can have several causes.
6. How will the result be reviewed?
Identify the design approver, relevant test participants, target-device checks, and acceptance tasks. Include one ordinary path and one meaningful exception or recovery path. State any deadline and what depends on it, rather than assuming an event date establishes development feasibility.
7. What must be available afterward?
Describe source and asset delivery, build instructions, distribution responsibilities, and support ownership. If another team will extend the game, say so before the handover is defined. Keep credential exchange outside the brief.
A compact fictional example
“We want a browser prototype for adults trying a route puzzle with a mouse. The player rotates two bridges, moves a traveler, and resets the board. We need to learn whether the connection changes can be predicted before a move. We have sketches, no code, and no release artwork. One initial board and one transfer task are included; accounts, saved progress, and stores are outside this stage. The design owner will review observed predictions and decide whether to test more boards.”
That example leaves room for technical judgment while making the intended decision clear. Read scope and budget, or send your own milestone.