Design Document Traps (Intentional)

Not sure if I’ve mentioned this insidious design trick before but if so, permit me to repeat myself as I have had recent cause to use it again.

Game design is a busy business and it is often hard to get people to meet for approval on features. Even when a meeting happens there are many unanswered questions that fall to the design lead to fill in. The design document the lead writes is then a contract, so to speak, between the various groups involved in the features being discussed. Implementors need to approve of the feature and management needs to sign off on it.

A problem I ran into often was that sometimes people did not always read the design documentation. This annoyed me and so I began to throwing traps into my design documentation when all other methods of getting approval for a document failed. Basically a training exercise to help encourage people to read the documents before approving them.

What kinds of traps did I use? Usually a ‘fake feature’ inserted into the design documentation, something like:

When dragons begin to sing magical berets will appear on their heads so players understand what is happening.

You know the document was read if the people you sent the document to come in, holding a printed copy of the design document and stabbing their fingers against the out of place feature, asking you “You can’t be serious about this.”

Did this help? A little bit… some people did start reading the documents. More often somebody stumbled across the out of place sentence many months later and it was cause for a bit of a laugh.
If you do use this approach do be careful of what you add… imagine the situation if somebody forwarded the document to Very Senior Management (as an example of a polished game design document) without reading it.

Not that that ever happened.