Types of design documentation

There are three major types of design documents, each serving their own specific purpose during different phases of a project. Making sure you use the right type at the right time will make sure you work as efficiently as possible, while not boring your reader to death.

Concept Pitch

Before any project or feature design can take flight, writing a concept “pitch” document is key. This document has the sole purpose to sell an idea to anyone. It doesn’t matter if you’re an end-user, a VP of finance or a seasoned game developer, anybody should be able to read this document and come out thinking the idea presented is great.

It’s also important to understand that a concept pitch can be about an entire game as well as a single mechanic, depending on which phase of the project you’re in. Selling ideas to people is a game designer’s core business at all times.

• Presentation format – You don’t want people to have to read paragraphs of text.
• Audience = Everyone – Anybody should be able to read your pitch.
• Fewer words, more imagery – A picture says more than a thousand words…
• Short and to the point – If you can’t sell a concept in two- or three sentences max, the scope is too big or the concept isn’t concise enough. Yes, even a full game pitch in two or three sentences.
• Don’t get stuck on details – This document is about why something is great, not how you’re going to build it

When you’re knee-deep in development later on, being able to fall back- and refer to the original pitch is extremely valuable!

High Level Design

People are sold on an idea, so now we’re moving to how we’re actually going to build it. The high-level design is a document where we define the scope of the game or feature and go into a level of detail where we specify out more what is needed. What does the idea entail in more detail?

What is important to note here is that this is not the full-detail design yet. The main purpose of this document is that it provides a more detailed talking-point list to start discussing with other departments. What do the coders need to know about the feature? What do the artists need to know? You will work together with them to flesh things out more, so leave a lot of room for their input.

• 4 to 6 pages max – Stick to the scope and requirements of the feature,
• Audience = Other departments – Coders, animators, artists, etc.
• Use examples – What references do you have? Other games? Movies?

Low Level Design

You’ve gotten input from all people involved and now you want to start building a prototype. And for this we need a lot more detail. This document will become the manual and reference for all departments when they start building the design. Without this document, your developers are blind. It’s the single point of truth for everyone.

This document is not a fire-and-forget document! It evolves over time as you start actually building the feature and things will change. A lot of designers don’t like updating their low level designs during development, but it’s key for when you go into the testing / quality assurance phase. But more on that in a different blog.

• Structured and concise – Focus on the nitty gritty details, stay away from “selling” things
• Technical focus – This is not a novel, it’s a technical manual
• Track changes – Keep a clear log of what changes over time and update your team regularly
• Reference other docs – The pitch and high level design will stay relevant throughout; reference them!

If you manage to utilize these three types of documents effectively and update them as your design develops, you’ll be well on your way to a more efficient development path and much higher quality end results! Good luck!

Want to dive deeper into the different types of design docs there are? Contact me for a 1-on-1 coaching session!