Iteration is the key to good game design.  Everyone knows this, not just designers.  Artists, programmers, even the producers in charge of the schedule acknowledge that iteration is a necessary evil — a gullet of unknown appetite that must be sated.  However, this abstract understanding breaks down almost immediately when faced with this inflexible reality:  If our plan is to iterate on the design until the game is fun, it will not be fun when we begin, and will not be fun at any point in the iteration process until literally the moment before we are done.  Successful designers have accepted this reality to some extent — they have to.  But non-designers, deprived of both visibility into the iterative process and ultimate responsibility for how it turns out, have not been forced to come to terms with this uncomfortable truth, and so they get nervous.

It is in the designer’s best interest to minimize the impact of their own uncertainty on the rest of the development team.  Some of them do this through bravado — how dare you question my ability to produce results?!  Others present design as a black art, with arcane secrets known only to themselves — an illusion which a perceptive non-designer can dispel with a few well-considered questions.  Many use this uncertainty as camouflage, avoiding direct conflict by constantly iterating without revealing their ultimate goals.  The problem with all of these techniques is that they can be used not only to reduce the team’s discomfort with iteration, but to conceal a lack of design discipline or creative horsepower.  It becomes impossible to discern the difference between a good designer protecting the team from the difficulties of iteration and a bad designer hoping to stall long enough to get lucky.  What is required are methods to iterate quickly while minimizing the team-wide anxiety.

Continuity of Iteration

If a designer stops iterating on an element or system for more than a week, other team members will assume that they are done with it.  They will evaluate it as if it was finished and assume that the designer is satisfied, even though it is clearly not fun.  Left unchecked, this chain of assumptions will lead them to distrust the designer’s abilities and judgement.  This happens almost entirely subconsciously, so communication to the contrary is rarely effective.  The only real solution is to keep iterating, even when the correct next step is unclear.  Just change something so that bystanders will postpone their evaluations.  This also avoids the problem of inertia, where developers — even designers, sometimes — grow accustomed to an element’s broken state and no longer notice that it isn’t fun.

Tools and Systems for Iteration

Any non-designer that is an integral part of the iteration loop will be exposed to the chill of uncertainty on a daily basis.  So the simplest way to reduce their unease is to make sure the tools for iterating don’t require their constant support.  With the proper tools, a designer should be able to experiment entirely on their own, without external resources.  If these tools are unavailable, it may require the designer to broaden their skill-set until they can hack together what they need.  That’s why most experienced designers have a working knowledge of so many tools — 3D modeling software, source code editors, Photoshop, etc. — not because they can produce shippable content or code, but so they can try off-the-wall ideas without needing help from outside the design team.

Private Iteration

Another benefit of tools that designers can use on their own is that they allow for private experimentation.  Sometimes the iteration process is random and goes through an enormous number of bad ideas before discovering a good one.  Again, since most non-designers are not confronted by the constant, unmitigated stream of failures required by the iterative process, watching the ones responsible for the ultimate quality of the game appear to be blindingly incompetent for months on end can be… unsettling.  It takes an emotional toll that can be avoided when a designer does most of their failing in private, witnessed only by other sympathetic designers.

Herald Milestones

Of course, chronically working in private has one major disadvantage — nobody sees your successes, either.  Since a lack of perceptible progress can be as damaging to team morale as public regression, it is crucial to announce any concrete improvements as soon as they happen.  No need to wait for an element to be complete, so long as a decision is reasonably certain and isn’t going to change immediately, let people know!  “The speed of the tank has been decided!”  “Jump is definitely going to be on the ‘A’ button!”  Pointing out these small, but measurable, signs of certainty will give the team a sense that there is light at the end of the iteration tunnel.

Even permanent failures can result in more certainty.  “We have given up on the hovercraft!” “We are no longer working on the Shadow Beast!”  The objective is not to demonstrate the perfection of the design team, but to show an inexorable drive toward closure.  The team must understand — not just intellectually but in their bones — that if the iteration process continues as it is, at some point in the future, the game will be done.