6 Ways to Make People Want to Read your Game Design Document - Lethal Deal Development Log 4

At some point in life, every designer comes to the same realisation, nobody wants to read your GDD. Luckly, I figured this out well before Lethal Deal started development, so I could do my best to make the GDD for Lethal Deal as readable as possible.

Navigation
A game design document could seem to a lot of people as a monolith of text that is overwhelming and dense. So having a way for each member of the team to locate parts of the GDD relevant to their role without having to read through it all is essential. Using Google Docs built in header system is a great way to get team members to where they need to be quickly. 

Presentation
How you present information in a document that people don’t want to read is vital. I don’t mean font or spacing, though that is obviously important. Instead, I mean the use of imagery, tables, charts, anything to turn words into images, or to segment essential words from paragraphs.

Here for example, I realised that the programmers on the team were used to using tables when planning out feature lists and tickets. So, to make it easier for them, I used a table to categorise every mechanic that is used to make the enemies work. 

I extended this idea to artists as well, as using tables literally segments words and puts them in a container that really allows any team member to focus on the key points of the document.

​Use it for Screening Concepts
Through team members reading through the documentation, conversations about different features and mechanics are sparked and through conversation, concepts are iterated on and changes to the documentation are made before development has gotten momentum. In my experinece working on Lethal Deal, every mechanic or system can be discussed and made better through that discussion. Only the GDD can allow for a consistent context for the non-vision holders of the team.

Consistency for the Vision
It’s almost impossible to explain something to one person, and then an hour late explain it to another person in the exact same way. The GDD is a great way to showcase a vision consistently. This leads onto the next point.

Categorising Essential Information
As an extension to the last point, having essential information at the beginning of the document is vital to creating that vision in the minds of team members. This can be surface level information, almost like an elevator pitch with a bit more depth. This doubles as a refresher to the project every day when members open the document which in turn helps them stay on track.

Change Log
This is probably the most obvious point in this list as a change log is included in every GDD template, but nonetheless it’s a great tool in your arsenal as a designer to present important information in the best way possible. If a programmer loads up the GDD, and they see that the documentation on a feature they started working on yesterday has been updated, that eliminates any confusion when they get to that part of the document.