How to make sure your GDD is relevant and readable for the entire team
Matthew Wiggins, CEO, JiggeryPokery
- Design docs are notorious for being out-of-date as soon as they are written, so I like to combine them with a log of discussions, playtests and decisions taken. This gives a deeper understanding of the intention of the design, helping with the many choices that will have to be made when actually making the game.
Des Gayle, founder, Altered Gene
- Do just enough design up front to get everybody started and failing faster. The days of the 50-page, static bibles for game design documents are done. Use an online collaborative tool like [Atlassian’s] Confluence so that discussions around features are open and everyone can see the “methods behind the madness”.
Tony Gowland, consulting F2P game designer, Ant Workshop
- Keep them short, cutting unnecessary words. I prefer bullets over well-written paragraphs – i.e. “Interactions: Swipe right to cancel” versus “Here the player can simply make a swiping gesture to the right to return to the previous screen”. People don’t read long documents, and an unread GDD may as well not have been written.
Stephen Caruana, lead designer, Pixie Software
- Many aspects of your game are constantly evolving, especially considering today’s design and development zeitgeist. So treat your GDD as an in-flux record of your current understanding of the game; start high-level and get into further detail over time. It needs to be regularly maintained and, importantly, easily accessible to all the team.
Kris Skellorn, studio design lead, Playload Studios
- Don’t expect them to read it more than once. Do not show every edit to your documents to your team and expect them to re-read slight changes to the same features over and over. When writing drafts, circulate them amongst a smaller group of other designers, project owners and / or producers for review, before passing it out to the rest of the team. If you are lucky, on the average project, your artists and coders will read some of your documents at least once.
Lisa de Araujo, Block N Load producer, Jagex
- Don’t write design documents. Obviously you must document designs for your quality assurance teams and your publishers, but design docs are almost impossible to keep updated sufficiently to be useful for implementation. Instead, consider taking an Agile approach and break your features into Epics and User Stories. Agile Design methodologies are great for game design and tools like Jira make managing iterative development easy.
Matt Molloy, lead designer, Climax Studios
- As you prove and disprove feature statements via prototyping and expand upon their design, be as visual as possible. A picture really is worth a thousand words. But more importantly, the more creative and visual your design, the more likely it is that people will read it, understand it, enjoy it and offer feedback on it. It is part of your job to get everyone on the same page and invested – which a design wall-to-wall with boring old words will never achieve.
Mark Simmons, CEO, Freejam
- The design document should be created with the core audience for it firmly in mind, contribute significantly to the conception process, and provide the audience with effective direction and specification that they need to achieve the creative vision. For example, in Robocraft’s case we created a lean design doc, with the high-level vision and objectives, for a relatively small feature set, to empower their creativity to achieve the build, measure, learn and iterate philosophy of agile development.