|
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.
Project
Managing the Iterative Design Process
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.
Scope
and Suitability of the Iterative Design Process
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.
Conclusion
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.
|
This crucial bit is quite understated. Keeping a team's "democratic" dynamics at this stage can really be the sink-or-swim for the prototype.
However, it was great to see all of the usability testing that was done and - more importantly - how you analyzed what the real problems were, even if part of your ideals had to be sacrificed for a better game experience. It's so easy to get caught on a particular mechanic and really _want_ it to work when... well, it just isn't appropriate or good for the game experience.
All the focus groups *hated* it.
Herman Miller said screw it and released it anyway, according to their original design.
It became a best-seller.
Why?
Because "users" often dislike that which they can't understand. But the problem isn't *it*. It's merely unfamiliarity. Discomfort with something that is new.
This is why sometimes suspension of judgement in the face of a design spec can be just as important as listening to the players.
There isn't a right answer. It's a dilemma.
The group is not always right. Sometimes the individual is.
I'm sitting on an Aeron chair right now and I like it. However when we bought them, the distributor offered a free of charge training session to every user because their operation is not very self evident. To get the best out of them, you need to know how to set them up properly. Usability testing might have made the adjustments of the chair easier to use. Do you see the distinction yet?
I get what you mean though and the best quote for debunking *focus* testing is the Henry Ford one - "If I relied on my customers to tell me what they wanted they'd have asked for a faster horse!" Also, Pixar's leadership are infamous for saying "You need marketing on the bus but sat somewhere near the back". : )
@Tim Carter and Jason Avent: The focus of our tests was equally about the player's enjoyment as it was their ability to actually use the product. As I mentioned we went in to these tests without any strongly defined metrics and we don't see market appeal and playability as completely exclusive from each other. If someone mentioned they didn't like a certain theme or a style that was as important as them finding a certain move too hard.
We're a small team and don't have a marketing department to do focus groups, so these test have to be as holistic as possible. But we also didn't blindly follow the testers' comments, the approach is really to be reactive. But, certainly, I think you're right Tim to say that it's not that the players wouldn't have enjoyed the first design of BBB, but that they were unfamiliar with its mechanics. However, it was so inaccessible for players, most wouldn't have ever gotten to the point of enjoying it.