Iterative design process

This article is a draft. You can help by editing it or discussing in the comments

click here to edit!

A game's purpose is to provide the experience to individual performers, but it will depend on the actions of all participants. These two factors lead to a complex environment and stop game designers to ever consider the game finished without trying it out, regardless of how much prior thought was given to the project.

This article will first provide basic information on iterative design process, a few more advanced ideas from different sources are discussed in iterative design extensions article.

Structure of the process

After having your game idea, shape it into a form precise enough to play and make a prototype. Then, after playtesting you'll learn what choices players tend to make and how they feel in situations that the game provides. So the basic design loop is:

Game Idea - (Rules - Prototype - Playtest - Revision).

There are some exceptions from the most common path in the loop. Usually, your revisions will result in adjustment of the rules but sometimes it's the game idea that requires modifications. You may also occasionally skip a stage if new rules need exactly the same game components, or if your test was not conclusive towards the rules, but showed that players are confused by the prototype.

Let's now have a closer look now at all of the stages.

Game idea

Interestingly, in games, an idea is not glorified as much as in some other art fields. Main reason for this is a difficulty of evaluating it — despite the fact that many very creative people come up with ideas for games all the time, no-one will be 100% sure if the idea is good until it is tested, which for each case requires work and time.

Specifying the rules

Testing rules in their written form will be done at final iterations, but at first the game designer operates more often with verbal explanation. Most importantly, you need to clearly define what players are allowed to do and how their actions are structured in time, and consider stating also goals and the end condition.

Preparing a prototype

The best practice of making a prototype is to put minimum effort into it. This may sound paradoxical, but the reason for that restrain is due to the iterative nature of the process. Aim for visual clarity, but apart from that, you should assume that changes in the game will indeed occur — it's possible that many components will be of no more use, don't make it harder than necessary as for your emotional attachment.


Playtesting is the most important phase of the iterative design process. It may provide you both general orientation about the game system and answer specific questions. Consider why do you playtest and with whom. You may soon find that a willing playtester that have never played your game might be especially valuable. First impressions are very important — don't run out too quickly of possible providers of that.

You may gather information from asking questions, from observing the non-verbal reactions and also from additional measures, like keeping the scoring notes, clocking the stages, or taking photos for later analysis. The usual process has designers actively testing at the early stages, and then possibly refraining from participation not to influence the process of playing.


The factors that should encourage you to playtest are:

  • replayability,
  • multiplayer gameplay,
  • game goals / win condition…

There are game pieces that have none of the above, which are extremely open, and generally operate in a more conceptual area. These usually won't be meaningfully playtested (but they are also at the peripheries of our wiki's scope).

For more, check iterative design extensions.

If you think anything should be added to this subpage, please drop a hint or a link for future editors.

Unless stated otherwise Content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License. See licensing details