Let’s talk about documentation for a moment. A lot of you will go “we don’t need no stinking documentation!” because documenting things is boring and not very exciting when it comes to the design process. Let me gently correct you on that point. There is a reason why we document things, and one of them is “you can’t sneak stuff past the chain of approval”.

As a game developer and a former producer, in my experience, one of the most problematic aspects of game development is that if we do not document what a feature is, feature creep is more likely to happen. Why? Because we forget what was said and how it was said in meetings and in design conversations. Let me break it down.

• Design decisions are lost – Game development typically takes place over several years. What was true at the start of a project may not be true at the middle or at the end of it. Game engines are continuously updated, which means that a back end limitation that was the basis for a decision may well not be an issue at the end of development. This goes equally for design decisions. Maybe we made a decision before the game pivoted in some way and now the basis for making that decision is no longer valid. Unless you have someone with a steel trap mind and an objective perspective that is also present in all meetings (hint: you don’t), people will forget about why a decision was made. Hence. Document it.
• Feature intent is lost – Knowing why you build a feature is important, at least from an experience perspective. Why are we doing this? What are we hoping to achieve? How do we know when we have achieved it? Document these things to have a good way of following up on intent.
• Communication across large teams – A lot of studios still operate under the misconception that what the director knows is what the team knows, but there’s no real need to actually tell the team anything. I’m sorry if that is a bit salty. Actually I’m not. Communication is one of the hardest things in large teams. Keeping a joint vision is not easy. Having documentation makes it less hard. Also people leave, new people come onboard. Having clear ideas of what a feature is makes it harder to mess it up. Also, new designers on an ongoing project have a tendency to be somewhat disruptive. Knowing what a feature is, and why the decisions that were made were made, is a good thing, because it decreases disruption.
• More efficient process – This is my pet peeve. We’re really crap at signing off on features in game development. I’m not saying a design document fixes this, but it certainly improves it. If you’ve gone over the design with all stakeholders, they’ve said yes and the design is documented, it will be a lot harder for people to backtrack or claim they were unaware. Feature creep is less likely. Not unlikely, it always happens, but this way at least when the feature drags out and becomes a monster, you can point at a document and say “yeah, well what you told us to do and what was actually put in the schedule – based on this document that you approved – are two different things.”¹

I usually document features in two steps, depending on the type of development I’m dealing with. One concept, which is a shorter and less detailed design document containing a brief overview of the intended design without detailed wireframes or any prototypes made. This is the sketch. It is a useful document in large teams (100+), but in smaller teams, it can be skipped.

Why do we need this document?
The intent with a concept document is:

• To give us an idea of what the feature is and contains – the outlines of the feature. What is it? What is it NOT?
• To create a joint vision of what the feature should be in the game – How does it manifest in game? VFX, SXF, UI, animations, art etc.
• To understand the intended outcome of the design – How will my players feel when they engage with this feature? Happy? Excited? Frustrated? (Yes, frustration is a valid design choice if the feature is something like, say, a boss fight. Don’t @ me.)

Feature design documents are where things get fun. A feature design document is a detailed description of what the heck you are about to do and how to implement it. It contains references to technical issues and performance problems, it contains every edge case you can think of and a solution for it and it also contains any dependencies you may have. All the design decisions are in there, as is all the changes made to the feature until it reaches implementation.

The intent with a feature document is:

• A clear idea of what the feature is and isn’t. Isn’t is just as important as is in some cases, otherwise people might imagine that the feature can handle more than it can.
• An understanding of what data is required to support the feature. You want to know how a feature performs. You want to know what players do with it or in it. You want to have telemetry hooks so that you can adjust functions based on playtests and usability tests. Data is good. Data is your friend.
• An understanding of what technical dependencies the feature has. In some cases this will be a short paragraph. If it involves putting several characters in a UI space while a live game is going on behind the UI space, we’re talking probably a tech design document and many gray hairs for lead programmers all over the place. Knowing your engine is important even if you don’t know how to implement in it (Hello FrostBite. What was that? Do I miss you? Uh… I plead the fifth…).
• Any additional dependencies on features outside of the UX discipline. Sometimes we need help from animation. Sometimes we need help from VFX. We always need help from Audio (love you audio peeps), and we also need to know this and document this, because otherwise you can bet your sweet butt that these aspects of a feature are forgotten in the maelstrom of development.
• Any additional dependencies on technical systems outside of the UX discipline. Online. Hello. I know we had a falling out, but if you just let me explain… usually what happens is that we have a huge need to negotiate access to CPU, GPU, why on earth there’s no kerning in the native UI engine of the game engine, that yes, kerning is actually needed for a game that contains a lot of text and that scrolling, while unimportant to the game at large, will make it much easier to not show all text in a tiny font or overflowing the menu screens.
• A clear understanding of how the player accesses, interacts with and experiences the feature. This is the more UX-y part of things. How do I get into the feature. How do I get out of it. How do I interact with it. This is where the wireframes and prototyping comes in.

Just to give you a handout, I have appended both a concept design template and a feature design template to this post. Have at it. These are templates that I’ve been using since I started out in game design, and I’ve found that they are helpful in focusing my efforts. I think my first actual template is from 2002… Hmmm… I’ll have to dig it out. Also, thanks to Ericsson Mobile Communications and a game design book I can’t remember the name of and has since gotten rid of for the idea of templates. Ericsson is guilty of the version control. The rest is experience.

UX Concept Design Document
UX Functional Design Document

1. What do you mean “are you speaking from experience?” Don’t be absurd…