From time to time I get questions from students, or see postings on the Internet from newbie developers, demanding to know why they should write design documents. They want to dive straight in and get modeling or coding, and they see the paperwork as a waste of time. The player will never see it, so why take the trouble to write it?

I know the feeling; I was that way too, when I first started making games. I remember writing out FORTRAN code long before I had a clear idea of how my game was going to work either as a form of entertainment or even as a piece of software. Of course, back then there were no experienced designers around to tell me how it should be done - everybody made it up as they went along.

One of the most common newbie objections to writing design documents is that nobody reads them. That sounds valid at first, but it actually misses the point. Nobody reads the phone book, either, but if there weren’t a way to look up phone numbers, the telephone would be a lot less useful. Like the phone book, most design documents aren’t intended to be read but referred to. Nobody reads them cover to cover, but managers and developers look things up in them that are relevant to their particular tasks.

Another common objection is that, as most games are prototyped first, the prototype can form the basis for the game and the team can just keep adding new features to it, so why write a document? But that’s not what a prototype is for, and doing it robs the prototype of its value. They’re intended to be quick and dirty, and the dirtier they are, the quicker they can be. They’re testbeds, not designs - you can play them, but you can’t look up data or plans in them.

In Mark Cerny’s famous design methodology, he warns his developers that every scrap of material they create for a prototype will be thrown away. This frees them to cut corners as much as they like, secure in the knowledge that whatever kludges they make in the prototype, those kludges won’t find their way into the product. It’s always dangerous to try to turn prototype code into final code, and Cerny avoids those risks by making sure it doesn’t happen.

Also, prototypes almost never include all the content of the final game. We build prototypes mostly to test mechanics and user interfaces. If a game will have thirty levels, the prototype might implement three or four, or maybe only one. Somebody still has to design and document all the remainder for the content teams to construct them. A prototype can’t replace the documents - diagrams, maps, lists of objects and so on - that are needed to build those levels.

So far I’ve answered some objections, but I haven’t advanced any positive reasons why design documents matter. Anybody who’s led a big project in the mainstream industry knows perfectly well why they do, but it's still a reasonable question for those who haven’t enjoyed that dubious privilege. There are actually several reasons, which I’ll address from least to most important.

Reason 1 (least important): Funding agencies (publishers and others) want design documents as evidence that the designer knows what he’s doing.

A lot of people in the industry would like to get the money first and figure out the details later - heck, who wouldn’t, if you could get away with it? Sometimes you can sucker a private investor into letting you do that, especially if they don’t know much about the business. But a sensible publisher simply won’t hand over several million dollars to a designer who doesn’t have a clear plan in mind.

Executive producers want to see something in writing. They no longer insist on a 300-page game bible, as they did 15 years ago, but they still want something they can hold in their hands and take to show the marketing department. These days it's more likely to be a 30-page treatment, but it’s still a design document and somebody has to write it. No document, no money.

If you’re self-funded, this isn’t an issue, but there are several other good reasons for writing design documents even if you’re paying your own way.