← Igor Arterchuk

How I work

Working with documents

Design documentation that supports clear decisions and shared understanding.

Documentation alongside prototypes

Even though I prefer to make a prototype whenever possible, documents are always part of the job. Each feature needs to be described, and the systems around it need to be structured clearly.

Feature and system documentation.

The right format depends on the reader

The format and level of detail depend on who will use the document: another department, people within a team I lead, a producer or a publisher. It depends not only on their role, but on the particular person.

In some teams, we preferred a simple document with bullet points and talked through the details by voice. In others, the best approach was to capture as much detail as possible, then add more after questions came back.

Some teams were full of creative people who knew the project well enough to make design and UI decisions themselves during implementation. In that kind of all-star team, there was no need to document every detailed layout and edge case.

I do not believe there is one correct way to document work. It always depends on the situation, and I stay flexible.

Methodology follows the project

The methodology also depends on what the project needs. More often, I work from a small set of core pillars and aim for emergent gameplay.

Iteration is key. I treat the ability to iterate quickly as something to design for: cutting or smoothing away anything that gets in the way of the process. I am not especially drawn to player-centric design as a complete methodology. Its moment-by-moment analysis is valuable for study and polish, but it can become too narrow and lose sight of the whole game experience.

Different formats

In some cases, documents are my only input to the design process, without touching the game code at all.

Some documents work like mind maps: a way to hold the structure of a system in one place.

A design-system mind map.

Others are simply a large body of text and numbers.

Detailed design documentation with text and numbers.

Some documents use many schemes and visual references to communicate the idea.

A design document with schemes and references.

The most useful documents usually belong to a project or its team, so I cannot publish them here. My own project documents are not always presentation-ready either. For now, this page shows the working formats; later I will make a dedicated example.