The Interactive Development Process
This is a very simple introduction to a development process that has been developed over years of work at vivid
studios. It started out as a book, developed for Apple Computer's Multimedia Developer's Program, entitled,
Multimedia Demystified. This book covers the general development process in some detail. As both the process
itself and our application of it to online media have evolved, we have refined this process to what you see above.
This, of course, is a fairly shallow explanation of it.
The process chart above covers the interaction of the major development steps and teams. The development
process itself is actually wrapped in a management layer responsible for the meeting of deadlines, schedules,
budgets, and the building of teams and relationships. During this phase, several members of the various teams
may be involved, but the goals are to create or respond to a Request for Proposal that succinctly outlines the
needs of the project from the client's views. Included in this (as a part) may be a simpler Client Brief and,
hopefully, some semblance of a realistic Schedule and Budget should be developed. If these are not realistic,
this should serve as the first warning flag and should be addressed immediately.
Concept + Planning
The first real development step toward the solution takes place during the Concept + Planning phase. This is
where the Goals, Messages, and Audience for the project are explored and decided. These are the most
important questions that must be addressed and make the most impact on the project. These cannot be
described too well. Often, they are not described at all and it is surprising how few clients are ready with these
answers when they are asked. Market Research can sometimes provide parts of the answers but the overall
goals and messages must, at least, be decided consciously by the client.
Many times a Proof of Concept is a valuable part of the development, to both help visualize the purpose of the
project as well as use it as an internal selling tool to gain support and understanding for the project. Usually,
proofs of concepts are not used outside a company.
Lastly, the Requirements Document should address all of the design requirements for the project, including
any metrics for how the success of the project will be measured when completed. At the very least, the
Audience(s) needs to be carefully described, as well as the Goals of the project and the Messages intended for
the audience. This sounds simplistic and obvious, but it is hardly ever done adequately. Every decision from this
point forward will be derived and affected by these decisions. Part of the Requirements Document should
address the proposed Technology for the project, the Market, and the Competition. The most difficult part of
this phase is convincing clients that these questions are tantamount to answer as they will be eager to move
forward and see "work" (meaning screen designs) and often grow impatient with these "distractions."
Design, Prototype, + Specification
In this phase, the first examples and solution are derived. It is the most intense, complex phase and involves the
most creativity, coordination, and inspiration. The Requirements Document from the previous phase should
provide all of the answers as to why the project should be, but it is in this phase that the development team
develop the how answers (in other words, the solutions).
This phase will see the development of many prototypes, often the first merely in paper and sketches, while the
later ones might be more elaborate. Also, there may be two semi-parallel tracks of development. For example,
the experience team may be tackling the interfaces while an engineering team may be prototyping actual
engineering solutions. Ideally, both teams work together, but depending on the size of the project, it's complexity,
and the amount of cutting-edge technology involved, the interface team may need to develop and prototype the
experiences, formulate a preliminary specification and hand-off to the engineering team while they explore how
to make it work. Prototypes, for the most part, are examples and not the final solution. They are usually hard-
coded, that is, they don't actually work as intended, only appear to. They are simulations when it comes to the
interface, but the engineering team may need time to develop and plan the feasibility of these solutions before
Production can start.
These prototypes should be tested with potential users to determine if they really meet the needs of the
audience. User Testing is too often forgotten or under-utilized. It is essential that assumptions are tested and
problems are corrected. Even the best development team cannot plan for everything nor out-guess everything
that the audience may encounter. Also, past this point, user testing will be useless, meaning that it will not be
possible to address anything that user testing identifies once a project is in production.
At the end of this phase, the Final Prototype needs to be accompanied by a Functional Specification that,
together, describe every aspect of the final product. This is what the Production team will use to produce the
entire project. Also needed before production can start is a Visual Design Specification (a detailed description of
the intent of the visual design) as a part of the overall Func. Spec. and a Production Matrix. This later part
describes every element that needs to be produced and where it fits into the whole project. This is what will be
used to determine the budget, scheduling, and team during Production.
While this is a busy period, all questions should have been answered by the Func. Spec. and prototype. Any
detailed, residual questions should be answered by those that served on the team during the Design phase. Now
big revelations should occur that change the scope or nature of the project. If this happens, however, it may
send the project back to the Concept + Planning phase (that is, if the goals, audience, or messages sufficiently
change). This is why it is so important to get those answers right at the beginning.
As the project comes together, it can be "built" into temporarily working instances called "builds." These builds
will go through many iterations before complete, often labeled Alpha 1, 2, 3, etc.When production is finished, the
project isn't yet. It still needs to be tested and made live. At this point, everything should be finished and
integrated into the Beta build.
This is the phase most likely to be forgotten, understaffed, under-scheduled, or under-budgeted. However, it is
essential that everything is tested adequately before it is made live. Testing here does not refer to User Testing
but to component testing or Quality Assurance. Every element and link must be checked on every page in
every browser on ever platform, etc. It is detailed, laborious work, but it is essential to creating a professional
site. Each series of testing, fixing, and rebuilding is labeled with a new release: Beta 1, 2, 3, etc.
The Production Matrix from the previous phase is now reused as a Testing Matrix, for helping track all of the
tested elements and components. The Test Plan needs to encompass all testing objectives and coordinate
multiple testers working independently.
At the end of the Testing phase, the project can launch, but this is not the end of the project. In many ways, it is
only the beginning as the site will need to be maintained with new content and interactions for as long as it is
live. While minor additions can be added seemlessly, major ones will need to be added carefully and may
require a new approach to be developed during a new design cycle (back to Concept + Planning).