11 Useful Document Formats for Game Designers

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:

  • What design docs are for
  • When you should use them and a word of caution about overuse
  • General rules
  • An overview of several types of useful design docs
  • Deeper dives into each doc type

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:

  • When you’re trying to figure out the details of a design for yourself
  • When you’re pitching a concept to someone (your teammates, stakeholders, etc.) to get feedback or get them on board with an idea
  • When you’re explaining an important concept (like how a feature / system works) to someone who will need that info in the future. It might be an engineer who’s building a system you designed two days ago or it could be future you three years from now and trying to remember how this system worked so you can build the sequel.

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.

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:

  • Who this doc is for: If you’re making a doc, it’s incredibly important to remember who you’re building it for. If your document is a detailed description of how you want a new tool system to be built, save the artists on your team some time by labeling the document “For systems programmers on [Project Name].” Likewise, making the distinction that a pitch doc is for internal rather than external use can save you a lot of headaches. In addition to helping out the people who’ll be reading the doc, it’s a good thing for you to make a conscious decision for before you even start writing the document.
  • Main point(s) of contact: When you’re in the thick of a project, it’s easy to forget about the state of things in the future. Months (or years) from now, you or your coworkers might not be on the team anymore. Someone on another team might have built a system half a year ago, but now you’ve got questions about some of the finer points for the polish/QA part of the project. If you or someone on your team in the future has a question about the doc, make their (and your) lives easier by putting the doc’s main author(s) near the top of the doc.
  • Last edit date: Docs can go out of date incredibly quickly. When you’re in the thick of production, you might even make multiple docs on the same topic as new decisions get made. When you’re sifting back through eight conflicting versions of “[Project Name] Narrative Outline,” you’ll go a lot faster if you can easily find the “Last Edited” dates.

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.

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:

  • Pitch Doc
  • Pitch Presentation
  • Pillar Posters
  • Mood Board
  • Art Reference Board
  • Storyboard / Flipbook
  • Feature / Scene Map
  • Feature Spec Doc
  • Technical Design Doc
  • Content Doc
  • Hotlist / Feature Priorities List
  • Post Project Overview Doc

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.

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:

  • Short presentation or doc (e.g. Google Slides/Docs, Word, etc.)
  • 1–3 pages
  • Can stand alone without a presenter
  • SHORT
  • Focuses on audience, platform, mechanics, high level game flow, tech considerations
  • Should look visually appealing
  • A few touchstone pieces of art; maybe a concept piece
  • NOT the time for elaborate story/worldbuilding
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:

  • Slides (e.g. Powerpoint, Google Slides)
  • Strong hook + easy-to-remember keywords
  • More in-depth info about target audience, platform, gameplay, etc.
  • Depending on who the pitch is for, might also include more specific info about market research, cost / time estimates, known risks, background on your team, any other info that they might want to know before investing time in your idea
  • Extra reference slides for questions (this is where story stuff, game lore, market research, and any other “not the main path but might come up during questions” goes)
  • If it’s an internal doc, sending it out in a format that allows commenting (e.g. Google Slides) is a big plus; teammates can more easily ask questions or point out concerns on a slide-by-slide basis
  • Gamedocs.org has a lot of good examples of publicly released game pitches
  • There’s an excellent GDC talk called 30 Things I Hate About Your Game Pitch that can help you avoid common pitfalls
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:

  • Google Slides / physical posters
  • 2–4 posters
  • 1 image + 1 SHORT sentence per poster
  • These are HARD to make (pithy statements are hard, especially for a team)
  • Great to use as a compass: are we still building what we set out to build?
  • Pillar posters are a living doc: pillars can change over the course of development if your team agrees a change in direction
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:

  • Pinterest / Google Slides / Mural / physical pictures / Photoshop doc
  • Designers can make design notes on mood board (e.g. “this level should have a lot of references to the cat god because it’s going to be the next big boss later in the map”)
  • Can have a more specific focus (e.g. lighting, main scene color, stylization reference, historical research, etc.)
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:

  • Pinterest / Google Slides / Mural / physical pictures / Photoshop doc
  • More specific than a mood board; more focused on specific details of an object/scene that you want to use to build assets
  • Designers can make design notes on mood board (e.g. “the door can look like whatever you like, but it has to have a clearly visible keycard reader”)
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:

  • Google Slides
  • Sketches / diagrams / snapshots of a game system
  • Short descriptions of what’s happening in each frame
  • Highlight what player interacts with and how it flips to the next frame
  • Bonus points if it’s a doc with comments so stakeholders can respond with questions/concerns
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:

  • Google Drawing / Sketch / Whiteboard drawing
  • Can focus on all sorts of things: player progression, layout options, locked areas, whiteboxing notes, how this map connects to other maps, number/layout/types of enemies/power ups/collectables, etc.
  • Examples of this kind of design doc are easy to find online
  • You can find a lot more info about this kind of doc at sites like https://www.worldofleveldesign.com/
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:

  • Google Slides / Google Slides
  • Overview of the feature: what’s it supposed to do?
  • Case study: step-by-step example of how it might be used
  • A detailed breakdown of all of the buttons, knobs, and dials you’re going to need
  • Notes about any aspects of the feature that may need to change / expand / be built on top of in the future
  • Diagrams/visuals/sketches/wireframes/charts are super helpful
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:

  • Google Doc (optional bonus: video stepping through how to use the tool live)
  • Overview of what the feature does
  • Table of contents — e.g. “Getting Started,” “How to make a new character,” “Editing an existing character,” “Character data management”
  • Easy to follow step-by-step instructions
  • Pictures + gifs are great
  • Tested out by content creators; this doc is useless if people can’t easily follow your instructions (and they’ll come bug you to help them instead)
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:

  • Usually a spreadsheet (or other format for keeping track of data)
  • Easy-to-grock headers for key pieces of information (e.g. “Character name,” “Weapon type,” “Enemy type,” “Item type,” “Starting quantity,” “Base speed,” “Line count,” “Asset creation status,” etc.)
  • Often has columns for tracking status (e.g. “Not started,” “Needs writing pass,” “Needs implementation,” “Needs balance pass,” “Ready for director review,” etc.)
  • Can sometimes be built so that QA can use it to test if the content is showing up correctly in the game
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:

  • Spreadsheet is best for easy sorting/filtering
  • This method is best for smaller teams; if you’re on a larger team, your production team will probably want to use a more robust system instead(e.g. Trello/Jira/etc.)
  • Tasks/features sorted by priority (color-coding higher prio)
  • Who’s in charge of finishing each item
  • Item status (not started, in progress, blocked, complete (might have more for QA / director sign-off))
  • Notes column for any extra information / questions
  • The Red Line: anything below this line in the doc isn’t going to get fixed/implemented. Are we okay with that? If so, let’s use this doc to see if there’s anything we’re cool with cutting/reprioritizing.
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:

  • List-based Google Doc
  • 1–20 pages
  • Brief description of the project
  • Contact info for all key team members / feature owners
  • Links to any important documents (pitch, design/tech docs, marketing materials, features that might be revisited in DLC)
  • Write it assuming that a stranger’s going to need to read it in 5 years
  • Make life as easy as possible for your future self

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!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Marlena Abraham

Marlena Abraham

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