Many Game Designers write bad documents; even more don’t actually use them.

They feel writing them is a massive waste of time, and every day they dangerously lean a bit more toward the “Documents are useless” group of people. But what if writing and using documents are not two separate actions? What if writing documentation leverages your thinking (and the one of your team) to create better games? This week we will look at 3 actionable tips to actively use Game Design Documents so you can make them part of your day-to-day work.

After applying them, the way you write them will change dramatically.

‍

Here’s what you need to effectively use Game Design Documents:

• Use Documents As Your Thinking Environment
• Make People Engage With Documents
• Make Documents Part Of The Iteration Cycle

Without further ado, let’s jump right in.

#1: Use Documents As Your Thinking Environment

The document page is your best thinking tool.

Every time you have an idea, it’s good to take Note of it so you don’t forget. That’s good, but if you want to take things to the next level, don’t think of it as a Note but as a Thought.

By using this mindset, you gain 2 primary benefits. First, you can see your idea in a different place than your brain. And second, you can free up your mind and actively think about it by connecting other thoughts. You’ve created your personal “Thinking Environment”, and your ideas will expand on the page like never before.

But how do you create that environment?

‍

Embed this mindset in your GDDs by creating your “Doc’s Language”.

By shifting your mindset, you’ve already done more than half of the work, but some tweaks will make it even more effective.

One of the easiest ones is using a Color Code to highlight different information like:

• Small work-in-progress ideas
• Placeholder values
• Not prototyped features
• Etc.

You create your personal language that makes you laser-focus and understand your docs in a blast.

Another powerful way to boost your thinking is to write down the design thinking process (the why behind your design decisions). Doing it gives you an archive of your thoughts that you can read whenever you need. It’s like uploading your mind to a computer.

Unfortunately, few people do all this because they believe you waste tons of hours writing. Their mistake is treating writing and thinking as 2 separate moments instead of creating their Thinking Environment.

But when you apply this to an entire team, it becomes even more incredible.

#2: Make People Engage With Documents

Collaborate to make the most out of ideas.

Building your Thinking Environment where you can leverage your reasoning at maximum is excellent. But when you create a Collective Thinking Environment, everything exponentially level up.

When everyone's ideas bounce between team members' brains, something magical happens. Ideas start to grow and connect to create something new out of it; that's serendipity at work. To do this effectively, you need to have a strong team culture.

If you do, it will be easier; if not, you can start planting little seeds with simple actions.

‍

Create a discussion around documents using a "Team's Language".

If you've created the "Doc's Language" we've discussed before, you're already halfway through. The next step is to turn it into a fully adopted "Team's Language" consistent with as many team members as possible (at least the design team).

But how do you make them adopt your language? Don't force it like a training program; trust me, it won't work. Instead, create a Legenda at the top of every document you write with your Doc's Language rules. Then ask for feedback from your peers and create a discussion around the document's content. Make them focus on the design content, not the Legenda.

Make reading the document a natural process. If you do it for enough time, someone else may adopt it, and, in the long term, it could become part of the teamwork dynamics.

It's not an overnight process, but productivity and design quality will significantly boost.

#3: Make Documents Part Of The Iteration Cycle

Don’t just write Documents; “work them”.

Any Game Designer knows that you can’t write the perfect feature document, create the prototype and then move to the next. You can’t do it first try; it just never happens.

For this reason, many designers start with the prototype and document everything at the end. That’s the wrong approach because you’re not using your documents; you’re passively writing them. To effectively use your documents, you need to “work them”, meaning that you must make them an integral part of your Game Design Iteration Cycle.

This is where many people go wrong. It’s not iterating on documents, but it’s iterating with documents on design features.

Let’s see exactly how to do it.

‍

Flash out an MFB (Minimum Functional Behavior) and refine it iteratively.

First things first, what's an MFB? It's the smallest behavior you can prototype and test (It could be a simple mechanic or an entire feature depending on your prototyping skills).

Follow these 5 simple steps:

1. When you have an idea, write it down and add details until you find an MFB.
2. Create a prototype, test it, and analyze what works and what doesn't.
3. Jump back on the document to fix the issues and add more details.
4. Then back on the prototype to refine, test, and analyze it even more.
5. Repeat this until you have a full feature (or even a complete game prototype).

As you can see, documents are not a parallel work chore you need to do.

You're actively using them to iterate on your design ideas to make them better each cycle.

Going back to Tip#1, "Writing = Thinking".

‍

Key Takeaways:

• Use your docs to create your Thinking Environment.
• Create a “Team’s Language” through documents.
• Iterate with the documents on design features.

‍

I’ve also talked about Game Design Documents in previous Game Design Compass episodes:

• 👉 What Documents Should A Game Designer Focus On?
• 👉 4 Reasons Why You MUST Write Game Design Documents
• 👉 Wiki Format In Game Design Docs: 4 Key Reasons It Outshines The Single Giant Document
• 👉 How To Build A GDD Wiki Home Page That Boosts Efficiency And Collaboration
• 👉 Game Design Document Formatting: 5 Critical Mistakes That Make Your Docs Ignored

Check them out if you want to dive deeper.