Skip to content

One secret to our success

I’ve learned a lot by listening to people like 37Signals and Doug Bowman share the secrets to their success. I’m hoping others can learn from the secrets of our success with Xero.

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

If you find this interesting please let me know. If so, you should come along to my session at Web 2.0 Expo and workshop at Web09 that goes into much more detail.

UPDATE: You can see my slides here.

 

Read more about Technology, Design, Development

 

18 comments

Miki Szikszai
26 March 2009 #

Philip

Killer post – love it.

Do you think this process is just as applicable to hardware as well as software?
What do you need to look for in terms of people to establish this type of capability in house – my assumption is that this will be somewhat un-natural for lots of people, business oriented and technically oriented. Do you have to go through a ‘everything you have learned, you need to unlearn’ experience to make this work?

Cheers

Miki

Chris
26 March 2009 #

Great to hear a bit more about how you develop, I love this approach. Could you expand a bit on what tools you use to create your screenflows?

Thanks
Chris

Richard Clark
26 March 2009 #

Do you guys use tools for doing the screen flows or just write ‘em up manually? There’s quite a few interesting toolkits out there but I admit none of them have really caught me yet.

[...] Excellent post by Philip Fierlinger’s post on the Xero blog. He discusses the Xero approach to software, being agile, design led, and using rapid prototyping. [...]

Sandy Mamoli
26 March 2009 #

Really cool post!

Thanks for writing it … :-)

Philip Fierlinger
26 March 2009 #

@miki Great questions. This process actually came from hardware. I have a degree in industrial design, a field that pioneered rapid prototyping (just replace screens with foam models).

Prototyping is just a way to communicate an idea so that other people ‘get it’. Anyone with an idea can do a simple prototype and achieve wonders.

To do a refined, production ready prototype does takes design skill. But you always get a designer to design, right?

Some people learning this method are suspicious that anything so fast and easy can be effective. Those who have tried it, swear by it (developers, designers, project managers, clients alike).

Philip Fierlinger
26 March 2009 #

@chris @richard We use Flash to do the screenflows. You could theoretically use tools like Photoshop, Visio, PDF or Powerpoint.

The reasons we use Flash:

• It’s a great drawing tool, so you can do simple graphics for lo-fi prototypes, or pixel perfect hi-res, production ready graphics

• Flash is timeline based, so you can preview the user experience from start to finish as if it were a movie or slideshow. This makes a HUGE difference when you’re developing and refining concepts.

• Flash has an object Library, so you can re-use your common design widgets (menus, buttons, images, etc) and edit them across your entire prototype in an instant.

• Flash files are easy to publish and share over the web. At Xero, we built a wiki where we publish and share all our prototypes. So anyone on the team can just fire up their browser and easily view the prototypes.

The way we use Flash for screenflows utilizes only a tiny fraction of the simplest features in Flash. The only code we write is gotoAndStop(“frame”) to navigate back/next through the screenflow.

Hope that helps.

[...] best application user interfaces, talking about one of the secrets to their success on their blog, One secret to our success. To quote: In our methodology, the prototype is the specification. It speaks for itself. Our [...]

Adam
28 March 2009 #

Awesome write up. I’m looking forward to seeing the videos of the Web2.0 conference talk.

Maybe a time-lapse screen cast of the process from beginning to end?

Having worked in both the Xero and Agile methods, I far prefer the Xero approach… less PM heavy, and giving more power to the creatives (developers and designers).

[...] employed an “agile design and development” process to build their business. I like their story. Doubled their client base in the last 6 [...]

Karl Hardisty
12 April 2009 #

Philip, an excellent write up, which is easy to understand and stays on topic.

Interesting to see that 37 Signals is an inspiration to you (as they have been to us). We use 37 Signals products ourselves, and have recommended them to many of our clients, friends, family, and helped people get going with them. We will take a closer look at Xero, and this may well be the next SaaS product we’ll be recommending.

[...] without having been to the session, but lots of people have asked me to share it. Read this post on agile design for a more detailed description of our process. Rapid Prototyping Using Flash at Web 2.0 Expo View [...]

[...] different technologies and applying them to complex interface problems (usually brought on by our design team). Fortunately for me I absolutely love trying to solve [...]

Bethany
28 May 2009 #

What??? Think through your vision BEFORE burning through lots of cash in development? (sorry)

I loved the post. Getting entrepreneurs to actually do this is another story. Kudos to Xero!

[...] without having been to the session, but lots of people have asked me to share it. Read this post on agile design for a more detailed description of our process at Xero. Rapid Prototyping Using Flash at Web 2.0 [...]

[...] One secret to our success L’auteur dévoile ici la méthodologie qu’il utilise dans le cadre du développement d’une application web complexe. Cette méthodologie est basée sur un prototypage rapide à partir de screenflows, sans jamais rédiger de spécifications. [...]

Fletcher Cargill
7 January 2011 #

21 months later, it is evident in using Xero how much care and attention goes into the usability and design of the application, and how this care extends not only to the HTML but also to the runtime Flash that Xero’s customers see and use every day.

In this age of commodity Flash component libraries, how do you ensure that the prototype you design can be effectively implemented, without either compromising on the design when using off-the-shelf components, or compromising on the timescale/cost through having to develop your own Flash components? In particular your zooming flash charts are such a huge boon to usability it is difficult to see how your design could do without them, and yet I’m just not sure such things are available from component vendors.

Add your comment





We welcome all feedback but prefer a real name and email address.