In most cases it’s essential to do some design work before you can begin implementation. Typically the artifact coming out of this is some form of documentation about the game or feature to be implemented. In traditional games development this usually involves generating a massive tome explaining every facet of the game in detail. This approach is also a massive waste of time for several reasons:
- It is necessarily incomplete and as such will require revisions as flaws and unexpected problems are found.
- It is incredibly hard to maintain due to the volume of material and references between elements, even in a wiki system.
- Being hard to maintain means it gets out of date quickly and loses coherence.
- No one will read it as they are generally too big, verbose and dense to be used day to day.
- It’s completely open to interpretation as it’s a description of something rather than a concrete thing itself.
This sort of documentation does have one use. Theatre for managers and publishers. It provides a nice cozy, false sense of security that everything is fixed, known and contains as few risks as possible. Sadly this is usually deleterious to the actual goal of managing project risk.
Why do we design?
To answer the question of “what should agile design docs should look like?” I first need to step back a stage and question why I design things in the first place. The answer I like best is simplicity, the goal of design is to provide the simplest solution that solves a particular set of criteria well. This is not necessarily the most intuitive solution and therefore it is important to spend some time making sure that I understand the problem before we go ahead and implement a solution.
I value simplicity because it usually provides a solution that is conceptually easy to understand for both the people implementing it and the person using the resulting feature. Simple solutions also tend to be robust as they have a low number of moving parts. Simple solutions are easier to modify later to add more complexity if required. Overly complex solutions can be an absolute nightmare to detangle at a later date.
Why do we document design?
If the simplest solution is not necessarily the most intuitive that means I need to be able to communicate the problem, the solution and the reasoning behind selecting the solution to other people. Usually in the case of design documentation that’s to the people implementing it, even if that person is me. It also means it needs to be easily digestible and relevant only to the current context. This is the great failure of monolithic design documentation.
Making an idea easy to question is also a vital part of communication. The creation of a design artifact is emphatically not a hand-off procedure but one part in a continuing collaboration to create a great product.
Agile Documentation
The main measure of progress in Agile is the state of the working product, for games means a playable game. Design artifacts therefore are not a measurable form of progress in themselves. They are however incredibly useful in moving forward more rapidly towards a working implementation. As such design artifacts must be “Just Barely Good Enough” that is they provide enough detail to start implementation with the expectation that design questions will be answered whilst the implementation is in progress. The level of detail entered into and type of design artifact generated really depends very much on the context of what is being designed. However all design artifacts should generally answer three points.
- What is the Problem Domain?- What problem is it we are trying to solve? What are the goals we want to achieve by solving this problem? Why is this a problem?
- What is the Current Best Solution? – A description of the solution adhering to the constraint it must be just enough to begin implementation. This could be anything from a photo of a whiteboard sketch through text documents to a mocked up video or animation. All depending on context.
- Why? – How does the solution meet the goals and sort out the problem we are trying to solve?
We also need to deal with one more issue. Most products including games are broken down into various smaller chunks for implementation and still need documentation about the project in totality to keep things coherent. Particularly in the early concept stages where different avenues are generally being explored. The good news is that this documentation approach is applicable at that level as well. It’s useful to have a simple, easy to digest and question synopsis of exactly what the game is supposed be and how to achieve it. The trick again is to provide just enough documentation to get started and to answer questions as they come up.
Next up how do you go about creating these design artifacts?
meheleventyone 