Once the initial prototype is created, then the iterative design process may begin with the Prototype Refinement Phase; each cycle of this process can be considered in a similar manner as a SCRUM Sprint, where the Product Backlog taken in to a Sprint is, in this instance, a list of Proposed Solutions i.e. alternatives to elements perverting the experience which have been isolated via the interpretation of a test.
The test process and the extraction of feedback from it is very key to producing a meaningful interaction. You may choose to focus group test the product or to pass it around between peers or others you know casually.
It is important not to have strongly defined metrics heading in, but instead to observe the user and their actions, as well as what they say. This is because metrics suggest a predetermined idea of issues within the functionality of system, but, from my experience, you are, as the builder of the system, unable to predict what elements within it which may hinder the desired interaction.
The interpretation of feedback from play testing is a skill which could be covered as an article in itself; however, the ability to listen, common sense, and an understanding of the functionality of video games are all invaluable skills.
Once the team has agreed that the prototype functions as it should with placeholder content, or delivered a vertical slice (a complete playable section of game indicative of final quality), the team must move on to the design and implementation of additional content. The length and complexity of this phase is dependent on the type of project.
Once the content has been designed and implemented then begins the Content Refinement Phase. Dependent on the project this may take more or less time than the Prototype Refinement Phase, but uses the same principals focused purely on how the content functions within the parameters of the core mechanics, as defined during the Prototype Refinement Phase. Large changes to the gameplay should not be made unless absolutely necessary.
After this phase the product is in a strong Beta state and should enter QA with a focus on bug fixing only, after which it is suitable for release.
This methodology focuses on producing a product of high quality, however due to its particular efficiencies it can, when correctly project managed, do so within a controlled time and cost.
The main risk when attempting to scope a project using the proposed methodology is that the time each refinement phase will take is an unknown. In an unrestricted implementation each cycle within a refinement phase is of an indeterminate length and there are an unknown number of iterations.
However, to stop both the time and financial costs of production from spiraling out of control it is suggested that the number and length of cycles with a refinement phase are agreed and fixed prior to the start. Therefore, it is important that before a new build in a refinement cycle is started that all Proposed Solutions are prioritized and then completed in that order so as the most important functional changes are fulfilled first.
However, all other phases, such as content development, can be managed using a traditional waterfall model. By defining strict time frames for each refinement phase (as described above) the project manager is able to give a very defined timeframe and cost for the project.
Although this methodology is proposed for small teams developing unique video game experiences, it has the flexibility to improve the quality of the experience of much larger, more mainstream video games too. In a larger project, the emphasis would be change -- perhaps more toward the Content than the Prototype Refinement Phase.
However, this methodology could suitably be applied to the creation of a proof of concept demo by a small team as a precursor to a larger project, with the feedback from testing placeholder content in the Content Refinement Phase, informing the design of future content.
Its implementation is something that is able to improve the quality of a product in a number of scenarios, however it must be done with thought and concern for the type of team and desired outcome.
Iterative Design Development focuses small, talented teams on finding the correct design to realize a unique and innovative product by building fast and failing fast.
It offers a relatively large freedom and flexibility early on in a production cycle, allowing for a quick and reactive approach to design. It also encourages the collaboration of all disciplines from the start, meaning that teams can start producing straight away, as opposed to one being dependent on the other to finish a task.
It is offered as an evolution of processes refined by Mobile Pie following the construction of numerous products and is informed by our successes and failures, before and after the formation of the company, as well as academic design theory and Agile project management methodology.
I hope that this framework is of use to others in our position and that they may refine and discuss its merits and implementation, further evolving and tuning it for more efficient design development.