When I first started working on Xero, I used sticky notes to help me get a sense of what it would take for us to build an online accounting system. After working on those sticky notes for about two weeks, we felt comfortable that we had a good foundation for the product architecture. Two weeks might seem like a long time to spend scribbling on sticky notes. But it was worth it. Those sticky notes are still a point of reference for us to this day – they still reflect the overall product structure and the product roadmap.
From our earliest plans we mapped out two major milestones: having a beta ready by November 2006 and having the product released by April 2007. We had a vague feeling that those two targets were theoretically do-able under ideal circumstances, but we all knew from our past experiences that theory and reality never align, and ideal circumstances only happen in theory.
That’s why I am so amazed that we pulled it off – hitting both targets to the day! Besides working with an amazing team of talented people, with all the hard work and some good luck, I think one of the most important factors that enabled us to make those targets has been our commitment to an agile design and development process.
If we would have done “proper†software specs for Xero we’d still be bogged down writing and arguing over use cases and flow diagrams to this day. Nothing would have even gotten designed or built yet. Instead, our specs process generally involves an hour at the whiteboard identifying the core requirements for an entire piece of functionality. From there, I go straight into prototyping.
My method for prototyping is doing rough screenflows. These are intentionally rough so that we don’t burn our time on low-level visual details, when we just need to sort out the high-level functional concepts. I quickly mock up screen layouts for each transaction in a typical user scenario, from the start of a task to the end, hitting every transaction along the way. It’s like storyboards for movies, scene by scene you see the plot unfold. I can build these prototypes very quickly, generating lots of ideas as I iterate through dozens of different designs in a few hours.
The screenflow prototypes are done as black-and-white outlines, similar to traditional wireframes. Except you move through it like a slideshow, seeing how one thing leads to the next, getting a feel for how it all flows. Traditional wireframes and written specs take a lot more time to create, plus they force you to intellectually resolve how it all works together in your head, instead of seeing how it flows on screen. Having to work it out in your head, instead of seeing it in action, leaves too many things open to misinterpretation, causing major confusion and delays.
With the screenflow prototypes we quickly evaluate what’s right and wrong about a design, what’s missing and what needs to be ripped out. We put the prototypes in front of users to get their feedback, which quickly gives us a good indication if we’re on the right track or not, and it provides us with some insights on how to make it better. Then we do more iterations.
This passage from an article written by the head of IDEO Tim Brown describes what I’m talking about really well:
People need to have a visceral understanding — an image in their minds — of why you’ve chosen a certain strategy and what you’re attempting to create with it.
Because it’s pictorial, design describes the world in a way that’s not open to many interpretations. Designers, by making a film, scenario, or prototype, can help people experience the thing that the strategy seeks to describe.
Build to Think
Design thinking is inherently a prototyping process. Once you spot a promising idea, you build it. The prototype is typically a drawing, model, or film that describes a product, system, or service. We build these models very quickly; they’re rough, ready, and not at all elegant, but they work. The goal isn’t to create a close approximation of the finished product or process; the goal is to elicit feedback that helps us work through the problem we’re trying to solve. In a sense, we build to think.
When you rapidly prototype, you’re actually beginning to build the strategy itself. And you’re doing so very early in the innovation cycle. This enables you to unlock one of your organization’s most valuable assets: people’s intuitions. When you sit down with your senior team and show them prototypes of the products and services you want to put out in two years’ time, you get their intuitive feel for whether you’re headed in the right direction. It’s a process of enlightened trial and error: Observe the world, identify patterns of behavior, generate ideas, get feedback, repeat the process, and keep refining until you’re ready to bring the thing to market.
The Prototype Tells a Story
Prototyping is simultaneously an evaluative process — it generates feedback and enables you to make midflight corrections — and a storytelling process. It’s a way of visually and viscerally describing your strategy.
On
New Zealand,
business,
design,
flash,
fun,
ideas,
lessons,
opportunities,
platform,
ux,
xero @ 23/04/2007 |
