Reason 2: Design documents are sometimes the basis for contractual obligations.

Most development contracts include a milestone schedule that dictates when the developer will produce certain deliverables and when the publisher will advance more development money. You can’t create a schedule until you know what features will be in the game, and you can’t know that until you’ve designed at least part of it, including some kind of a written record to build the schedule from.

In practice, milestone schedules always change, and the feature list almost always changes too. That doesn’t matter; you have to start somewhere. No feature list, no milestone schedule; no milestone schedule, no contract. Furthermore, it’s in the developer’s best interests to have each milestone deliverable be as clear and unambiguous as possible.

If the developers can demonstrate unequivocally that a certain amount of the work is done and a new payment is due, they are in a position of strength. If the game design consists of a lot of vague hand-waving, the publishers can do a lot of hand-waving in return when explaining why they are withholding payment and demanding more work. The more you know in advance about what you are promising to provide, the more confident you can be that you have met your obligations when the time comes.

In addition to the developer’s legal relationship with the publisher, there’s also the developer’s legal relationship with external content providers to consider. Music, art, animation, and writing are frequently outsourced to specialized agencies these days. In order for those companies to do their jobs, they have to have documents telling them what’s wanted, and again, those documents may form the basis of their contract.

Reason 3: Design documents communicate your intentions to the rest of the team, and let them plan their tasks.

In theory, this is why anybody writes a design document: to communicate information to others. Small teams don’t need this as much because the team members are often working in the same room and talking to each other all the time. This is why students and newbie independents don’t see the point of writing design documents: they assume that if they can all talk together, there’s no need to put anything on paper.

However, as we’ve seen, some documents are created for business or contractual reasons, and they serve other functions as well. Strangely enough, communicating with the rest of the team isn’t actually the most important reason for writing a design document. But it is one of the reasons, and a good one.

Instructors make students write design documents even though student teams don’t always require them for communication because the instructors know that the students won’t always be on a small team, and they need the practice before they get into the working world. Large dev teams can run up to 150 people, often spread out over several offices and even several countries, if some of the work is outsourced. Talking all the time, even on the phone or in videoconferences, is impractical.

Electronic Arts' long running Madden NFL series 

The bigger the game, the more important it is to document the design so that others can build their schedules. If you want your game to include 45 types of moving creatures, the artists will have to make models, textures, and animations for all of them. They’ll need concept art to work from - another form of design document. The audio engineers will have to find or create sound effects for each creature. If the creatures are autonomous, the programmers will have to know their behavioral characteristics. If you don’t write all this down, how will all those people know what to do? You can’t just explain it all in a meeting and expect them to remember it.

When I was doing the audio/video production for the Madden series, I wrote the audio recording scripts for the play-by-play - yet another form of design document. All told, they were about 75 pages long. We had to record material for every possible event that could occur in the game, and all of John Madden’s color commentary as well. Nobody could possibly keep all that in his head, and in any case, Madden needed something to read from in the voice booth, and the audio engineer needed something to work from when editing the raw recordings.

Sports games require more design docs than you might think, because even though the league has created the rules of the game, somebody has to figure out all the strategies (in football, the playbook for each team), animations, and user interface required to translate the sport to the target hardware. All that work produces documentation.

Finally, on some projects, not all the team members will speak the same language - literally. I encountered this when working with THQ (England) and GSC Game World (Ukraine) on S.T.A.L.K.E.R.: Shadow of Chernobyl. Most of the developers did not speak English at all, only Russian or Ukrainian. They couldn’t have simultaneous voice translators standing by 40 (or 60) hours a week, so a great deal of communication between the publisher and developer took place in the form of translated documents.