Letters To The Editor: Submit A Letter
View All Letters 
| 07.17.2007Why (lots of long) design documents don't matter
So I see that Ernest Adams has come out with a spirited argument in favor of design documents, but I think that he glosses over the basic point: Nobody reads them. They mostly don't refer to them either.
The reasons are many, but the core reasons are these:
1. They are usually very badly written
2. They are usually very tedious
3. They are usually non-specific
4. The people who mostly refer to them are designers in meetings talking to people of other disciplines who haven't read them and as the designer to just tell them what they want
5. Records of changes and decisions only matter to lawyers.
Of all of these, I would say that the key one to pay attention to is number 3. The problem is usually that the documents as they are written are written with everybody in mind, when the most productive approach is in fact to write documents with very specific people in mind.
For example, coders and artist are not interested in all the fiction and the fluff, the wonderful descriptions of this and that and the justifications of the business model. Coders want bullet-point instructions that explain how features work, and simple Visio-stylee diagrams that sequentially explain an apparently complex operation very easily. What coders want is not "design documents". They want 2-page design specs which use an economy of language.
What artists want is picture galleries, reference material, links to videos or images that comprise a general style, and maybe a few small notes about things like poly restrictions, anim frame restrictions etc and any impediments.
What producers need is schedulable break-downs of key features and systems in 5-word descriptions, with estimates of time and complexity, preferably rendered as charts. What marketing/pitching people want is glossy 10-page treatments with nice pix and such that wow clients. What external producers want is high-level breakdowns of asset charts, IP issues and confidence-building reports.
Nobody but nobody wants a pretentious D+D-style manual of the game's design complete with a 5-page change list that they can't be bothered following, stuffed full of sections that they can't read and obliging them to trawl through and index or chapter list and hunt for references in the document that refer to deleted sections.
So the problem is that game designers have to write, but they have to write what's wanted rather than what they think is wanted, and that usually means doing a lot of documents to order. It means learning how to give only the necessary information to a person of any particular discipline and for this to be an ongoing task. There is no silver bullet document that will solve all ills, and even though various book writers and freelance design contractors have tried for many years to imprint the idea that what we need are more words, the fact is that what we need is less, not more.
I applaud that Adams and co. have had the consistency of this vision of how things should be for so long, but the reality is that shoulds and coulds are for the most part never going to materialise. I would therefore advise any aspiring game designer not to waste his time with so much typing and instead learn to ask the question "What do you need?" rather than "Here is my vision, if you only read it, you would understand" because that is in fact his job.
Tadhg Kelly
-Tadhg Kelly
|
|
|
|
|
Letters to the Editor
