To wit, the following is an overview of our agile design and development process, focusing on how rapid prototyping fits into our product development cycle.At Xero, we’re building a robust SaaS platform at lightning pace. To make it happen, our design and development process, along with our documentation, is extremely lightweight.
These days, many developers have adopted some form of agile development. One of the core tenets of agile development is that you only scope, plan and build what’s absolutely necessary to produce working software.
WorkingSoftware != UsableSoftware
One big problem with this approach is that too many people define “working software” in purely technical terms. That’s like making food and judging it by whether it’s cooked, not whether it’s edible or delicious.
If nobody wants it, it’s useless. You end up wasting days/weeks/months of effort.
Design is key to making things that people want. At Xero, we’ve taken the approach that design must come first. We make sure our software is easy for people to use before we build it.
Our design approach is also key to building software quickly with minimal documentation. We don’t waste time writing use-cases and specifications. We design and rapidly prototype our use-cases. It allows us to communicate, evaluate and improve our solutions before a single line of code is ever written.
ThePrototype == TheSpecifictaion
In our methodology, the prototype is the specification. It speaks for itself. Our developers use the prototype as their blueprint throughout the development process, all the way through to final QA testing.
It’s important to clarify what I mean by prototypes. We don’t create working prototypes. We create design prototypes called screenflows: click-by-click simulations of the user experience, showing every interaction necessary to complete a given task. A screenflow is based on a scenario of a person completing a common task. We simulate all the screens, all the clicks and all the data entry necessary to start and complete the task. The result is a slideshow that simulates somebody using the software.
Screenflows are an ideal blueprint for developers. They make it obvious what needs to happen, when, where, how and why.
Documentation == Ill Communication
Screenflows leave nothing to the imagination, since they detail every click and every interaction. I recommend avoiding written specifications as much as possible – the screenflow should be the spec. In some situations, a few bullet points are necessary to outline some underlying business rules. If the business rules require anything greater than a few bullet points then it’s best to show it in the screenflow, rather than using words to explain the solution.
Show it, don’t tell it.
Using words to explain a design solution invariably leads to misunderstandings and poor implementation.
Through this prototyping methodology we can makes dozens, even hundreds, of small and large refinements and fundamental improvements to a solution very, very quickly. We achieve a level of efficiency and effectiveness that could never be done through written specifications or even code level prototyping.
Design != PrettyGraphics
One dangerous misconception is that design is simply styling – choosing colours and making shiny graphics. Colours and graphics are important to the user experience, but the true purpose of design is to guide people through a process, making the process obvious and simple.
In the case of software, design needs to guide people through the process of managing information: entering data and getting data in return. Design guides people through the process of knowing what information to enter, where to enter it and what to do next. More than colours and graphics, it relies on information design and interaction design – strong visual hierarchy, simple language and obvious visual feedback.
By doing design prototypes you can develop the user experience with much more precision and far less effort than writing pages of specifications. That should be music to your ears. Unfortunately, many project managers, business analysts and information architects still cling to their documentation like a bad habit.
If you embrace design-led rapid prototyping I guarantee that your software (and web sites) will become dramatically better and your development time will be drastically reduced.
If (Useful) PleaseComment
UPDATE: You can see my slides here.