11 Useful Document Formats for Game Designers
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.
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.
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.
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
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
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
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.)
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”)
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
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/
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
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)
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
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.
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!
