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).
www.nathan.com | experience design | thoughts | projects | inspirations | photography | me