Summary
Agile design is the practice of making game design decisions iteratively, grounded in evidence from a working game, rather than speculatively up front. Its central argument: a design document can describe a game in exhaustive detail, but it cannot tell you whether the game is fun. Only playing it can do that.
This is not an argument against documentation — it is an argument about what documentation should do and when design decisions should be made.
Key ideas
Designs do not create knowledge — games do
The canonical failure mode of traditional game design: designers write detailed specifications before the game is playable. Specifications accumulate — weapon clip counts, exact enemy numbers, precise AI behaviour trees — creating the illusion of certainty. When the game is finally integrated at beta, it bears little resemblance to the specification. Designers must scramble to adapt to what the technology can actually deliver, under deadline pressure, with no time to iterate.
Keith’s example: on a fantasy shooter, the design document specified not just all the weapons but how many clips each player could hold and how many bullets per clip. None of this detail “helped the team. In fact, for a while, it led it in the wrong direction.”
The alternative: treat the working game as the primary design document. Make design decisions at the point where they can be tested. Defer specifics until their context is established by a playable build.
This principle bridges to prototyping — the iterative design loop — and to the core argument of Scrum: the Sprint Review makes the game visible as early as possible precisely so that design can respond to what is actually fun.
The game emerges at the end
In traditional development, the first fully integrated version of a game appears at beta — at which point it is too late to address fundamental design problems. The technology underperforms expectations; features are cut because they are “90% done” rather than because they lack value; the shipped game is a shadow of the original vision.
Agile design moves integration to the beginning. Every Sprint produces a potentially shippable version. The game emerges continuously, not as a single reveal at the end.
Set-based design
Set-based design is a Lean-derived technique for deferring commitment under uncertainty. Instead of committing to a single design solution and building it, the team keeps a set of design options alive until evidence from the working game forces a decision.
How it works in practice:
- In early sprints, implement multiple variants of a mechanic (e.g. two different jump feels, three different camera behaviours)
- Play-test each variant
- Eliminate options as the game provides evidence about what works
- Commit to the surviving option once the decision is well-grounded
Set-based design accepts that the cost of implementing two variants early (when the codebase is simple) is much lower than the cost of changing a wrong decision late (when everything depends on it).
Keith calls these early exploratory options “parts on the garage floor” — pieces of the game laid out to be examined before being assembled. The assembly is informed by what you learned from laying out the parts.
The role of documentation
Agile design does not eliminate documentation. It redefines its purpose:
| Traditional design doc | Agile design artefact |
|---|---|
| Describes the finished game | Communicates the current vision |
| Attempts to specify all decisions | Identifies what is known and what is unknown |
| Is written before development | Is written to enable the next sprint |
| Is updated reluctantly | Is superseded by the working game |
A design document in an Agile project should: share the vision with the team and stakeholders; identify design questions that need answering; not attempt to answer questions that only the working game can answer.
Keith: “A design document should limit itself to what is known about the game and identify, but not attempt to answer, the unknown. A working game is the best way to address the unknown.”
The designer’s role in Scrum
Designers on Agile teams face a specific transition: when they first start using Scrum, they often approach a Sprint as a mini-waterfall — spending the first quarter writing documentation for the work to be done in the remaining three-quarters. Over time this shifts to daily collaboration and conversation about the emerging goal.
Structural principles:
- A designer should be part of every cross-discipline team working on a core gameplay mechanic
- The designer is selected based on mechanic and skills (e.g. a designer with usability experience for the HUD team)
- Designers accept that design ideas come from every discipline at any time — they filter and adapt ideas, not generate them exclusively
- The lead designer’s vision is communicated through embedded designers on cross-discipline teams, not through design documents cascading down a hierarchy
The lead designer role maps to a design influence on the Product Owner — the vision that orders the backlog — rather than a separate document-generating function.
Documentation as a publisher deliverable
Keith recounts a publisher requiring a 300-page design document as a contract deliverable. The team inserted a paragraph describing SpongeBob SquarePants appearing in their M-rated game; the publisher never commented. “It turns out that we didn’t invent this practice” — rock bands include absurd contract riders for the same reason.
This illustrates the gap between documentation as a communication tool and documentation as a compliance artefact. The former is useful; the latter is a ritual.
In practice
In a Unity project, Agile design looks like:
- Implement a rough version of a mechanic in the first sprint that touches it
- Play it; assess whether it supports the player experience
- Iterate — adjust parameters, try variants, cut what does not work
- Only then lock down acceptance criteria and refinements
The Unity Inspector is an Agile design tool: tunable parameters exposed at runtime allow a designer to adjust values without engineering support, compressing the design-test loop.
Contrast with specifying exact values in a design document before implementation — those values have no basis in the actual player experience of the actual implementation.
Evidence
“Designers need to create a vision, but design documents can go too far beyond this and speculate instead.” (Keith, Ch. 14)
“At the end of a typical game project, when all the features are being integrated, optimised, and debugged, life becomes complicated for designers. This is the first time they experience a potentially shippable version of the game.” (Keith, Ch. 14)
“A design document should limit itself to what is known about the game and identify, but not attempt to answer, the unknown. A working game is the best way to address the unknown.” (Keith, Ch. 14)
“Successful designers collaborate across all disciplines. […] They also accept that design ideas come from every member of the team at any time.” (Keith, Ch. 14)
Implications
- The “Cops and Robbers” mode in Midtown Madness originated from a programmer playing Team Fortress after hours and suggesting a variation to the designer — a good design idea came from outside the design discipline and outside work hours
- The designer-as-gatekeeper model (all ideas go through the designer, all design comes from the designer) fails at scale and under Agile
- Design documents written for publisher compliance are not communication tools and should not be confused for them
Open questions
- How do you maintain design coherence across a large game when design is distributed across many cross-discipline Scrum teams?
- At what granularity should the lead designer maintain a written vision? What must be documented vs. what can be held in conversation?
- Set-based design produces waste (the rejected variants). At what team size or project stage does this waste outweigh the benefit of deferred commitment?
Related
scrum-in-game-development | product-backlog | user-stories | prototyping | playtesting | minimum-viable-game | mda-framework | game-feel | overview-agile-game-development | source-agile-game-development