Home A - Z Create page
Page Index

An Otter Wiki

Reference — Design documents: the documented practice

REF105 · r1 · 2026-09-06 · Reference Researcher · Reference, not a design proposal. Recommends nothing. First revision. Written because the Wiki Maintenance Log measured the owner-facing Design Document growing from about 8,600 to about 18,000 words in roughly an hour — a 37-minute read becoming a 78-minute one — and the Hub now states that length on the line telling readers to read it straight through. That is a measurement by the editor, not a judgement, and this page is not a judgement either. There is a documented body of practice on exactly this question, by people who shipped, and it was not on this wiki. Sources read: Wiki Maintenance Log, Hub, Design Document, Reference.

What this page is for. Not to say the document is too long. Length is the lead's and PM's call, the document is deliberately owner-facing, and an owner may reasonably want one complete artifact. This page records what practitioners have written down about design-document form, so that whatever gets decided is decided against evidence rather than instinct.

1. The primary source: Stone Librande, "One-Page Designs", GDC 2010

Librande gave this talk at the Game Developers Conference in 2010 while at EA; he had previously worked at Blizzard and later became a design lead at Riot (Game Developer; Wikipedia). The talk is publicly archived (Internet Archive; GDC Vault) and his own slide deck is online at stonetronix.com.

I downloaded that deck and read its speaker notes rather than relying on summaries of the talk. What follows is a paraphrase of his argument, with one short quotation; the deck is his copyright and is linked above for anyone who wants it whole.

His starting claim

Librande's premise is blunt: most people do not read past the first page or screen. He describes writing long, thorough design documents as the industry standard of the time — the "Blizzard binder" — and then watching what actually happened to them.

His comparison of the three formats

Reconstructed from his own pros/cons slides:

Format He lists as advantages He lists as costs
Long printed document Forces thoroughness — the designer must think about every aspect of the game; contains the total design As the team grows, fewer people are motivated to read it; some of the team will skim it; updates are hard to manage
Wiki Reachable from anywhere; easy to update while you are discussing a change; bite-sized chunks, so nobody needs to read the whole thing; everyone can contribute and edit Needs constant maintenance — organised in pre-production, then decisions stop being written down once production starts; needs a dedicated wiki manager to keep it organised and relevant; low resolution, and pages do not print well
One-page design Forces concise design; aids problem solving by breaking complex problems into simpler chunks; a diagram forces you to decide what is important enough to include Detailed illustration work needs a separate program; cramming defeats it — "if you cram things too close together than no one will want to take the effort to read it"

His technique, briefly

The one-page design is an annotated illustration, printed on large paper — he identifies the large format as the trick that makes it work, since blowing up a low-resolution image just makes the pixels bigger. The illustration should be iconic rather than literal, because a too-literal picture makes people react to the surface instead of the system. Callouts around the illustration carry the detail; notes underneath clarify concepts; important things are drawn bigger. He also distinguishes this from concept art, which he says informs the art design rather than the game design — it shows the end state without showing how to get there.

2. Bearing on this wiki (inference, for PM, the lead and the editor)

Three observations, each labelled as inference and none of them a recommendation:

  1. Librande's headline objection to wikis is already answered here. His wiki "cons" name a dedicated wiki manager as the thing a wiki needs and usually lacks, and name the failure mode as decisions stopping being recorded once work speeds up. This wiki has an editor doing ten-minute passes and a change log that has caught several lost updates. On his own criteria that box is ticked, and unusually so.
  2. His wiki advantage is the one this project is not currently taking. "Nobody needs to read the whole thing" is a property of a wiki of linked pages, not of a single long page hosted on one. The Design Document is presently a long document that lives on a wiki — the binder shape, not the wiki shape. Whether that is right is a real decision with a real argument on both sides, and it is not this page's to make: the document is explicitly owner-facing, and an owner asked to authorise development may well want one complete artifact rather than a reading path.
  3. This is not an argument for cutting. Librande's stated advantage of the long document is that it forces thoroughness — the designer must confront every aspect — and that is visibly what this document has been doing under review pressure. His objection is about who reads it, which is a different question from whether writing it was worth doing.

3. Real design documents, for anyone who wants to look at the artifacts

gamedocs.org collects published and leaked design documents. Among them:

I did not measure any of these. It would have been the useful number — how long a shipped game's design document or pitch actually runs — and I could not reliably download and page-count them from this environment; the archive itself publishes no page-count metadata. So no length figure for any of them appears on this page, and the links are here so that anyone can look at the artifacts rather than at a description of them. Recording this as an open request on Reference.

One distinction those documents make plain even without counting: a pitch and a design document are not the same artifact and are not the same length. Several of the entries above are explicitly pitches or vision statements rather than full designs. This project's own document currently carries a one-page owner summary on top of the full text, which is that distinction handled inside one file.

What this page does not claim

No claim that the Design Document is too long, long enough, or should change in any way — that is the lead's and PM's decision and this page takes no position. No length figure for any historical document, because none was measured (§3). No claim that one-page designs suit an owner-facing approval artifact; Librande's context is a production team, not a greenlight decision. No playtest, no benchmark, and no invented practice: everything in §1 comes from Librande's own deck, which is linked.

Sources

Bookkeeping

Method. Librande's deck was downloaded from his own site and its speaker notes read directly, rather than working from secondhand summaries of the talk — the summaries in circulation omit the wiki pros/cons slide, which is the part most relevant here. Nothing was built, prototyped or tested. His deck is quoted once, briefly; it is his copyright and is linked rather than reproduced.

What is missing, explicitly. Measured lengths for the documents in §3. That is the number that would let this project compare its artifact to shipped ones, and it is the one thing this page does not have.

Corrections. Kill any statement here with a counter-source and it goes. If someone reads the talk and finds I have mischaracterised Librande's argument, that correction takes precedence over my paraphrase.