Getting to this goal required a change to our workflow. The traditional approach of separating tasks by disciplines into progressive phases would not work for this type of project; we had to adopt a more agile approach.
Traditional vs. Agile
In a traditional workflow, tasks are based on disciplines and are scheduled one after another. First the analysis and planning is completed, followed by design, development and QA. The finished product is then presented and delivered to the client. Although there are rounds of feedback, revisions and collaboration within this workflow, for the most part each discipline is tackled separately until completion before the next task can start. Progress is measured by which activity has been completed.
In an agile workflow, instead of planning around one complete deliverable, this process breaks down the requirements into key features. Workflow is managed by the priority of features, which are iterated and built on rather than creating one final product. Each iteration is shared with the client to review. Progress is measured by how many features have been completed. Tasks may still be separated by disciplines but can be worked on concurrently.
- Being able to use dynamic content makes it easier to identify functionality issues and see how the designs work in context.
- Different activities can run concurrently, tasks can overlap. There still needs to be some lead time between tasks but not as much as required in the traditional flow.
- Code is not used to fake the functionality of features just to be tossed out and replaced in production. Instead, the code is written to be production ready and can be delivered and used as-is.
- If cost or time becomes an issue, thoughful decisions can be made about which features can be left out.
- If there are changes to the project timeline, the prototype may not have all of the planned features but will still be functional.
All of these things let us make decisions by actually using the product. Usage is oxygen for product design.
- Getting used to tearing down code and designs, rebuilding and redesigning over and over again is a hard adjustment. You have to learn how to be flexible and expect the inevitable.
- Deciding where to draw the line between creating a pixel perfect prototype versus a functional prototype when time becomes a factor can be tough and often happens on a case by case basis.
- The project team and client have to have the resources to create and maintain the technology used.
Managing many concurrent activities and making informed tradeoffs takes a lot of executional discipline.
As with any process, tool or technology, one solution may not work for all situations. There needs to be some experimentation to find the right fit. Despite some of the challenges using a different approach, the project was a success because the final deliverable had more value than what would have been accomplished using the traditional approach.
We’re excited to continue in this direction because we strongly believe it will help us get better at making digital products and services that people love and want to use.