Prototyping for a Better Rich Internet Experience
I was asked today to send some explanation to a potential client about our unique processes at Rain (where I work as a producer). Since it’s something we’ve spent a great deal of time perfecting and something I personally feel very strongly about, my response ended up being rather verbose. But I feel that it’s a model more agencies should adopt and I feel the explanation is good enough that it warranted posting here, with some modification.
I think our discovery/prototyping process is something that sets us apart from not only other digital agencies, but also traditional software development agencies. Over the last ten years we’ve spent a lot of time perfecting our process with the single most important goal of making superior interactive experiences that we and our clients are proud and that users love.
The process, as we have it now, helps us dial in client and user needs prior to wasted development efforts. We’ve learned that clients and users never truly know what they want/need in a vacuum. It’s easy to make lists and requirements but, unequivocally, they will change during development and user feedback. If those changes come after scope has been locked down or formal development has begun it leads to three problems:
- Change management can easily put the agency and the client at odds, which is the worst thing for developing a superior user experience. As a producer, I want more than anything to worry about how to make the app the best it can possibly be for the client and user. I can’t do that as effectively if I need to constantly balance change-management against a fixed bid (scope creep). We need the flexibility during discovery to question everyone’s assumptions before we arrive at the best solution.
- The codebase infrastructure can be severely weakened if important features or user experience changes are introduced late or even early in the development and architecture process. This makes the cost/time of maintenance and debugging go up by by multipliers since extensive refactors were never in the original roadmap and architecture.
- With traditional methods the client does not get to see the finished product until it’s just about done. They may have seen some wireframes or comps, but final functionally is often what the developer has done is what they get. And while this will usually meet all of the scope requirements, requirements and implementation are completely different matters and the client is often very dissatisfied with the final outcome.
To avoid these issues we put a high priority thorough prototyping. Here is our process:
- Proposal: Business requirements / experience objective
- Prototyping phase
- Usability and prototype iteration
- Project requirements document and adjusted statement of work
- Development
- QA
- Deployment
Proposal: Business requirements / experience objective
These phases should be fairly self-explanitory, but the one I want to emphasize and discuss the first three. We first spend a lot of time getting to know the client’s desires and business model for the experience. We also spend a lot of time trying to understand the demographic and users’ needs. With the client we will then develop a proposal including our current understanding of objectives and business requirements. This will only serve as a guide as well as what we will use to come up with an estimate.
Prototyping phase
Once we have the estimate we charge the client a fourth of it to begin the prototyping phase. This phase starts with further definitions of business requirements, user persona development, and other preliminary documents that will guide the whole process. As soon as possible we’ll start throwing features down in wireframes and developing use-cases. At the same time we have creatives working toward branding objectives that will be merged with the wireframes once they both near finalization and approval.
Usability and prototype iteration
The end result of the prototyping phase (most of the time) is a functional, smoke-and-mirrors, prototype that give provides a real experience with as many as the main use-case flows as possible. We can use this with the client to make sure it meets their objectives and is exactly what they want. We also use it with users in formal usability studies. At this point it’s easy and cheap to question assumptions by adding or changing features and we welcome this. This is imperative to make sure the experience is the best possible before we’re locked into development.
Project requirements document and adjusted statement of work
When we have sign-off from stakeholders on the prototyping and accompanying documentation we feel good about beginning development. We also are then able to dial-in the cost of development accurately whether up or down based on inevitable changes.
Development, QA, Deployment
The point of the above verbiage is to show the imortance of solid prototyping. Once that is done effectively, the development, QA, and deployment process can follow any number of agile methodologies with similar or varying effectiveness and outcome. But delving into these is not in the scope of this discussion.
Tags: change management, code refactor, development cycle, discovery, process, protoyping, ria, scope creep
Andy Branch is a project manager/producer at