Iterative Design in Games: Prototype, Playtest, Revise, Repeat

Iterative design is a way of creating games in repeated cycles: you build a quick prototype, playtest it with real players, revise it based on what you learn, and repeat until the game is fun and works well. Each cycle is called an iteration. The word “iterate” simply means “to do again”, and the aim of each round is to get a little closer to the best version of the game.

In The Game Design Process: RAD vs Waterfall we compared development models. Iterative design is at the heart of Rapid Application Development and of almost every modern game studio, because fun is hard to predict on paper – you have to play it to know.

Diagram of a looping development cycle with planning, analysis, implementation, testing and evaluation
Figure 1 – The iterative development model: planning and requirements lead into repeated cycles of design, implementation, testing and evaluation before deployment. Image: Aflafla1, CC0, via Wikimedia Commons.

The stages of iterative design

1. Rapid prototyping

A rapid prototype is a quick, rough version of an idea, made in hours or days rather than months. It can be a paper prototype (cards, dice, drawings) or a digital prototype with coloured boxes instead of art. The only question it must answer is: does this core idea work and is it fun? Keep it cheap so you are not afraid to throw it away.

Hand-made paper game board and cards laid out on a table as an early game prototype
Figure 2 – A paper prototype of the game Diamond Trust of London. Paper prototypes let designers test rules and balance before any code is written. Image: Jason Rohrer, Public domain, via Wikimedia Commons.

2. Playtest

In a playtest, real players try the prototype while the designer watches. Good playtesting habits include:

  • Test with people who match your target audience, not just friends who love your idea.
  • Explain as little as possible – if players need you to explain, the game needs to explain better.
  • Watch and take notes: where do players hesitate, get stuck, laugh or lose interest?
  • Ask open questions afterwards (“What was confusing?”, “When did you feel most excited?”).
  • Record data if you can: time to finish a level, number of retries, where players quit.

The Extra Credits video below gives excellent advice on getting useful feedback from playtesters:

3. Revision

Revision means changing the design in response to what you observed. Group the feedback, look for patterns (one player’s opinion is a clue; five players stuck in the same place is a problem), and decide on changes. Sometimes a revision is a small tweak – slower enemies, a bigger button – and sometimes it means cutting a feature entirely.

4. Repeat

Then you repeat the loop with the revised version. Early iterations test big questions (Is the core idea fun?). Later iterations test details (Is level 7 too hard? Is the menu clear?). Each round the prototype becomes more polished, moving through alpha and beta towards the gold release.

5. Iterative design as a mindset

Finally, iterative design is an attitude: accept that the first version will not be perfect, test early and often, and let evidence from players guide decisions instead of guesses. It saves time and money because problems are found while they are still cheap to fix.

Common mistakes to avoid

  • Polishing too early: spending days on art for a mechanic that playtesting later removes.
  • Testing only with yourself: designers know the answers, so they cannot see what confuses new players.
  • Defending instead of listening: arguing with testers wastes the test; just take notes.
  • Changing everything at once: if you change five things, you will not know which change helped. Change a few things per iteration.
  • Never stopping: set a deadline or a “good enough” target so iteration leads to a finished game.

Example

A student team is making a Scratch game where a hummingbird collects nectar while avoiding rain drops.

IterationPrototypePlaytest findingRevision
1Paper version: a counter moved on a drawn garden; a die decides where rain falls.Players enjoyed dodging but found collecting too easy.Flowers now open and close, so timing matters.
2Scratch prototype with coloured circles, no art.Controls felt slippery; the bird overshot flowers.Reduced momentum; added a small hover when touching a flower.
3Added simple art, sound and a score.Players did not notice when nectar was collected.Added a “sip” sound, sparkle effect and +1 pop-up.
4Three levels with increasing rain.Level 3 was too hard – most players quit.Adjusted rain speed; added a safe leaf to shelter under.

After four iterations the game was far more fun than the first design – and none of the changes could have been predicted without playtesting.

Exercise

  1. Name and describe the stages of iterative design in your own words.
  2. Make a paper prototype of a simple game idea in under 30 minutes using paper, pencils and a die or coins.
  3. Playtest it with at least three people. Record what they did, what confused them and what they enjoyed.
  4. Write an iteration table (like the example) showing two rounds of revisions and the reasons for each change.

Next: Game Mechanics Explained: Rules, Players, Avatars, Game State, Game Views and Goals

Syllabus link: This post is relevant to the CAPE® Animation and Game Design Syllabus, Unit 2: Interactive Design and Game Development, Module 2: Game Design and Development – Specific Objective 6 (“identify the stages/steps associated with iterative design”).

Attributions to media used in this post:

Iterative development model.svg – Aflafla1 – CC0 (via Wikimedia Commons)

Diamond Trust of London – Paper Prototype.jpg – Jason Rohrer – Public domain (via Wikimedia Commons)

© 2026 Vedesh Kungebeharry. All rights reserved.