11 Useful Document Formats for Game Designers

A colorful splash background with “Useful game design formats” in the foreground
Background images in this article by Jimena Catalina at https://www.slidescarnival.com/eglamour-free-presentation-template/1938

A game designer’s job is usually a combination of three things: coming up with a design, getting everyone on board with it, and implementing it in whatever game engine (or other medium) that their team’s using. While I’ve seen tons of articles on game design best practices and tutorials for implementation, I haven’t seen a lot of specific info about the middle bit: getting everybody on board.

At a high level, you can absolutely find information about how to be a good teammate, but what about the boots-on-the-ground logistics? If you’re a new designer, how do you communicate your designs to the rest of your team?

That’s where design docs come in. From napkin sketches to feature deep-dives, design docs are a crucial part of a game designer’s arsenal. Important as they are, though, most new game designers only end up learning about the various formats for conveying their ideas on the job.

With that in mind, this guide is going to cover the basics:

Let’s get started!

What Are Design Docs For?

Design docs are a very flexible set of tools, but generally you’ll end up using them for one of three reasons:

A Word of Caution

Design docs can get a bad rap in the game industry, and often for good reason. A lot of documents are too long, too undirected, or too out-of-date for the team to actually use. Game developers will make the (often correct) argument that instead of valuable development time “actually making the game,” designers spend it updating documentation that has little to no impact on the game itself.

A caution sign
A caution sign
Photo by Markus Spiske on Unsplash

Before you spend the better part of your afternoon (or your week) making a design doc, remember that the worst doc is one that nobody ever uses. Don’t spend time make docs unless it has a direct impact on your team’s present or future work.

If you’re not sure, do a quick gut-check. Would it be easier/simpler/faster to make a doc or try out your idea in engine? Do you need a doc or would a quick five-minute conversation work? Does your doc need to stay up to date or can you just archive it after it’s served its purpose? At the end of the day, design docs are just a tool in your arsenal; use your design sense to figure out if they’re the best tool for this particular job.

General Rules

Before we get into specific doc types, here are some general guidelines for doc-making to make your team’s lives easier:

The “Back of the Book” Info

After a project’s been going for a while, the documentation tends to start piling up. If someone (you included) needs to go diving for one particular feature description in a sea of spreadsheets and presentations, make it easier for them to quickly find what they’re looking for by putting your key info at the top of each doc you write:

Make It Short, Sweet, and To The Point

You might’ve heard this Mark Twain quote before: “I apologize for such a long letter — I didn’t have time to write a short one.” Being concise and easy-to-read takes work, but it’s also one of the best ways to make sure your document is actually useful. Your teammates are busy, so they’re much more likely to skim through a quick, bullet-pointed, well-diagramed one-pager on a new feature than a heavy eight-page treatise.

Gut Checks With Your Team

Before you get too far along in your doc, (or maybe even before you start), get a teammate in your doc’s target audience to give it a quick check on the content and format. Ask them questions like “Is this something that would be useful to you?” “Can you find the information you need here?” and “What other info do you need from the design side before you can get started?” It’s a great way to cut down on the amount of time you’d spend writing down info that, when it came right down to it, nobody needed to read.

A spread hand of cards
Photo by Ali Kazal on Unsplash

Document Types

This is by no means an exhaustive list, nor are the formats I’m suggesting the only way to make these docs. Every designer’s style is different and every project’s needs are their own. That said, over the years, these are the types of documents that I keep coming back to in my game design practice:

As you can see below, these docs are ordered (more or less) in the chronological order that you’ll find yourself needing them over the course of a project, from before pre-production up through project wrap-up.

The previous list of documents laid out in chronological order, from “Pre-production” to “Wrap-Up”
Design doc formats in chronological order
A cartoony mock-up of a pitch one-sheet describing an imaginary game called “Spookytown Madness”.
Simplified pitch doc example

The Pitch Doc

Who makes it: Designer, signed off on by team

Who it’s for: Potential teammates, investors / publishers, company higher-ups

What it’s for: Giving the reader a basic overview of what the game you want to build is. This can be a response to a professional RFP (request for proposal), an internal pitch to studio higher-ups, or an overview of an indie project you’re pitching to potential teammates.

Pitch Doc Specs:

A simple mockup of a pitch deck, featuring key art, high level design bullet points, and charts for market analysis
Simplified pitch presentation example

The Pitch Presentation

Who makes it: Designer, signed off on by team

Who it’s for: Execs, people who can give you funding, members of your team

What it’s for: Pitching a game, feature, solution to a problem, etc. to either a live audience or team members who can give feedback asynchronously

Pitch Presentation Specs:

A simple mockup of two pillar posters, one of which reads “trick the tricksters.” The other reads “Work together or perish.”
Simplified pillar postern example

Pillar Posters

Who makes it: Directors, signed off on by team

Who it’s for: Your team, your clients

What it’s for: A clean, catchy visual reminder of the most vital core aspects of your game that you can reference throughout development. During production, you and your team can compare new features/mechanics/visual touchstones to your pillar posters and ask yourselves, “Does this match what we’re building?” They’re great for settling arguments about new features.

Pillar Poster Specs:

A simple mood board example, featuring a number of spooky pieces of artwork (spiders, skeletons, fireplaces, etc.)
Simplified mood board example

Mood Board

Who makes it: Usually the Art director / lead artist(s), but occasionally it’s useful for designers to contribute to these

Who it’s for: Mostly the artists, sometimes designers

What it’s for: Reaching an agreement across the team: what’s the general visual style and mood we’re going for?

Mood Board Specs:

A mood board on Pinterest featuring apartments, skyscrapers, robots, and trees
A mood board I made with my team for an indie project a few years ago
A simplified art board featuring a number of pictures of potions
Simplified art reference board example

Art Reference Board

Who makes it: Artists (lead/concept)

Who it’s for: Mostly artists, sometimes designers

What it’s for: Like an art reference board, but more detailed; reference to help answer questions about specific art pieces

Art Reference Specs:

A Pinterest board of old-fashioned medieval to Georgian rural kitchens
Visual reference for old-fashioned kitchens for one of my indie projects
A simplified flipboard of images showing how a user would use arrows to navigate
Simplified storyboard/flipbook example

Storyboard / Flipbook

Who makes it: Designers, UI/UX leads

Who it’s for: Programmers, artists, other people implementing the design in-game

What it’s for: Modeling a feature step-by-step for the people critiquing/implementing it (can also be used for pitching a solution to a specific gameplay problem)

Storyboard/Flipbook Specs:

Six slides describing a journal-based game interface
Six slides describing a journal-based game interface
Example of how a flipbook might look for a journal-based interface
A simplified top-down map of a game level, complete with labeled points of interest.
Simplified level map example

Feature / Scene / Level Map

Who makes it: Designers (system, level, etc.)

Who it’s for: Designers / content folks

What it’s for: A top down, high level view of a scene in the game; important landmarks, what features go where, etc.

Feature / Scene / Level Map Specs:

Sample CS-GO map diagram from https://www.worldofleveldesign.com/categories/csgo-tutorials/csgo-how-to-design-gameplay-map-layouts.php
Simplified example of a feature spec doc for “Enemy Spawning System,” featuring enemy types, spawning triggers, etc.
Simplified feature spec doc example

Feature Spec Doc

Who makes it: Designers

Who it’s for: Programmers

What it’s for: Clearly explaining the purpose of a feature that needs to be built; going into great detail about what it needs to do so that a programmer can build it

Feature Spec Specs:

Sample design flow diagram for a gardening feature
Sample design flow diagram for a gardening feature
Sample design flow diagram for a gardening feature
Simplified technical design doc describing how to use the enemy spawning system (getting started, adding a spawner, etc.)
Simplified technical design doc example

Technical Design Doc

Who makes it: Systems designers / systems programmers

Who it’s for: Anyone who will be using the tool/feature to make content

What it’s for: Explaining how to use a particular feature/tool to create content

Technical Design Doc Specs:

Simplified content doc, in this case listing voice over lines by character, tone, line content, etc.
Simplified content doc, in this case listing voice over lines by character, tone, line content, etc.
Simplified content doc example

Content Doc

Who makes it: Content designers

Who it’s for: Content designers

What it’s for: Writing/designing content outside of the engine, keeping track of that content as production continues, and occasionally exporting that content directly into the game. The content of this doc will depend on the content type of your game, but I’ve seen it used for keeping track of dialogue scripts, voice-over lines, weapon/enemy stats, puzzle formats and solutions, etc. Depending on your pipeline, your tools engineer/team might hook up these docs to the game engine itself for easy export and implementation.

Content Doc Design Specs:

Simplified hotlist with a red bar in the middle showing what tasks are expected to be completed
Simplified hotlist example

Hotlist / Priority List

Who makes it: Producer / Designer / Directors

Who it’s for: The team

What it’s for: Keeping track of remaining features/bugs, prioritizing them, and estimating what pieces of the game you can finish with your remaining time

Hotlist / Priority List Specs:

Simplified post-project overview featuring info like points of contact, important docs, etc.
Simplified post-project overview example

Post Project Overview

Who makes it: Designers, directors

What it’s for: Anticipating the needs of someone who revisits the project a year from now and needs to change something: if I need to find something in this project, where is it?

Who it’s for: Anyone who might need to work on / reference / update / apply fixes to the project later

Post Project Overview Specs:

To Wrap Up…

Design docs can get a bad rap, but used in the right way they can be a powerful set of tools in your design arsenal. There’s no right way to design your game, so treat this general overview as a sample of what kind of tools are out there — feel free to mix and match!

What design docs do you use in your game design practice? Are there any doc types you’d like to know more about? Let me know in the comments below!

Game Designer & Storyteller. Narrative + XR + location based + emerging tech. Indie game community organizer. Twitter: @marlenaabraham