The Iterative Design Development methodology was born from the evolution of the design process required to produce B-Boy Brawl: Breaking Fingers.
B-Boy Brawl was inspired by a series of YouTube videos in which people were using their fingers as arms and legs, to recreate break dance moves on a small scale. Initially the aim was to teach people how to reproduce the moves, but as we discussed the concept, goals were introduced and the product became a game.
Through these early discussions we decided the game was to uphold some very specific design ideals:
These ideals were undocumented, but existed as aims for the project and became immovable, fixed necessities. Although we approached the project with the idea of organic development these ideals restrained and shaped the design in an unexpected and unwanted way; we had inadvertently fixed design, and thus a development path.
Through development some of these ideals proved to be in direct conflict with one another in both obvious and obscure ways. On the surface we may see that accessibility is at conflict with the user having to learn moves. However, much deeper conflicts exist between both of these ideals and adaptability. A comparatively non-prescriptive mechanic may seem desirable to increase accessibility, but in fact the opposite was proven true, as during testing it became obvious users required more firm direction.
Initially, I documented two prototype concepts: one which featured buttons indicating where the user's fingers should be placed, and decreasing circles to indicate timing, and another which featured a HUD displaying the beat and the present, past and upcoming moves.
Mocked shots of the two proposed prototypes, representing a button-orientated and a HUD-led design.
From simply looking at these prototype proposals, we made assumptions on how the user would interact with both. It was considered that having buttons would make the game too prescriptive and monotonous, destroying ideals of theatricality and adaptability.
More important, however, was what we did not consider: How effective each approach would be at serving the required information to the user and how they would interpret it. We were blinded by what we thought the user would want and so did not consider what the user could use.
We fixed the design through discussion and documentation and built an initial prototype of the game, where there existed two bars as the sole direction and feedback for the user: one indicating the beat, and one indicating the moves. Upon playing it the team was very happy with the results of their labor. The game played as we had envisioned and planned it, and we felt assured that, despite it being a little rough in its present state, people would enjoy it.
An early build of B-Boy Brawl running in landscape with the move and rhythm bar.