For the inaugural Wellington Web Meetup I did a presentation on how game mechanics and the human need to play can be applied to interaction design to transform tasks that are painful and dull into experiences that are fun and addictive.

Here are some more great materials I’ve been collecting on the subject…

• My blog posts on the topic of games
• Other people’s slides on the topic of games and interaction design
• My bookmarks relating to game design

It’s been my mission with Xero to make the user experience a bit like a game. Money essentially is a game. It represents your score, your points and your power in the game of life. Yet, for most people managing money is a painful chore that is dreaded and avoided.

The latest update to Xero includes new functionality and design ideas that really begin to exhibit what I see as a game play experience. For instance, we’ve designed the bank reconciliation so that it’s fun to use, it’s an experience you actually enjoy and look forward to.

With the bank rec in Xero your job is to match transactions coming in from the bank with transactions you have recorded in Xero. Often Xero can predict the match for you, so with one click you can easily clear a row. You get a big green tick and away it fades, bringing up the next line – the next little piece of the puzzle – to be matched. It’s a bit like clearing rows in Tetris (as seen in the short video above).

Our new ‘fast code’ design lets you do it even quicker, by letting you create an instant match, on-the-fly. After that, Xero learns how you code your transactions so that the next time it already has the details filled in for you. Pretty soon all you do is: click, click, click down the page and you’ve cleared away a whole bunch of rows, knocking them off in rapid fire.

It gives you a real rush of instant gratification.

When you come across a transaction that reconciles to multiple items you go into “find and match” mode, tracking down the transactions that add up to the one bank statement line. It’s another type of simple puzzle that gives you an immediate sense of satisfaction when you find the exact match.

With Xero, we’re now getting into a phase of the product design and development where we can really start to optimise the work flow across the system to make the experience smarter, faster and genuinely fun.

I love seeing it all come together. It’s even better to see how much customers are loving it.

After seeing my talk somebody pointed me to this video: “The Science and Art of User Experience at Google”. It’s a presentation by Jen Fitzpatrick, manager of the user experience team at Google, talking about their interaction design process. She shares some really interesting examples of how they collect user feedback, particularly how they track usage patterns and monitor support queries.

A usability note on the actual video file: it contains a caption overlay, which is really useful, but it would be much more useful if that text was available to read/search/copy!

In a last minute change up, Rod won’t be able to make it to Queenstown to present at the Web on the Piste conference. I’ve been asked to take his slot. Sometimes you just have to take one for the team.

Please let me know if you’ll be going.

And in case you’re like me wondering what piste means, thanks as always to Wikipedia.

I’ve been invited to speak next month at UPA events in Wellington and later in Auckland.

I’ll be talking about and showing the interaction design process used to create Xero, providing some insights into the different design techniques used to build a complex online application quickly, yet effectively. I will also discuss how those techniques are evolving as the company and the software grows.

Web 2.0 debate

Last month, I participated on a panel debate at Webstock, arguing the merits of Web 2.0. I thought about making my presentation silly, but I couldn’t help myself and ended up creating a genuine analysis of what Web 2.0 is really all about, what makes it so significant, and why it’s important to understand. I think my slides do explain it pretty well.

I have to admit that our opponents did a much better job of making their case, using their rye cynical wit and deft charisma. Their tactics were extremely effective, but ultimately they were fighting a hopeless cause.

You can watch the full antics here.

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.

So how did I get roped into designing an accounting system? I’ve wanted to develop a web product ever since I started Turntable. I came up with various concepts and prototypes over the years, but for a host of reasons I was never quite ready to make it happen. With web 2.0 fever in the air, I once again got the strong itch to build a product. After brewing up some ideas, I approached Rod Drury with some of my ideas, just to see if I had anything worth pursuing. I only knew of Rod from reading his blog, but everything he wrote resonated with me. We met for coffee and we hit it off immediately. The next time we met, Rod blindsided me with an offer to join his new venture as one of the founding team.

When Rod pitched his idea to me, a “web 2.0 accounting system”, I didn’t have to think twice about it. I hate accounting. Obviously, accounting is a major factor in determining whether or not a venture will be successful. Yet, it’s such an excruciating process. I know that first hand from running my own business. So it was immediately clear to me that this was a perfect opportunity to design an accounting system that I could love rather than hate, while at the same time learning the ropes about building and running a software product from the best mentor in the business.

It also appealed to me because it’s a major business problem that’s begging to be solved. Accounting is something that every business must do. Literally, every business is required by law to do it! There’s no need to convince or educate anybody. Plus, most businesses hate the options that are on the market now. Meanwhile, nothing on the market is taking full advantage of network effects.

Finally, I was on board because Rod had the resources (aka cash) to do it right, to hire the best of the best designers and developers so we can build a great product and build up a strong brand very quickly.

So that sums up why I got involved. Next, I’ll write about how we got things off the ground.

Since July 2006 I’ve been working on Xero, an online accounting system. I can hear your internal dialog now, “A business accounting system? Gee, that sounds real fun.”

Believe it or not, it actually has been lots of fun. Seriously. I rate it as one of the best, if not the best, professional experiences of my life. That’s saying something, considering some of the projects and clients I’ve been lucky enough to work with over the years.

How could it be so fun? For one, the people involved are a true joy to work with. And, two, as Todd Dominey stated so eloquently, “Client / service work has its advantages, but there’s something to be said for pouring all your heart and mind into a product people use and enjoy. It’s the most satisfying work I’ve ever done.”

Last week, we officially launched, moving out of private beta into public release. I have to say that I’m extremely proud of the work we’ve done. Doing an accounting system certainly is a major challenge, so it’s a big thrill to get the get the response we’re getting.

Over the next few days I’ll post some details of how and why I got roped into designing an accounting system, how it got off the ground, and some of the techniques we’ve used to get it done.

Our holiday up north was perfect. In addition to all the other fun things we did, we also managed to squeeze in some fishing, sailing and snorkeling in the Bay of Islands. It truly is paradise up that way (except this week).

On the drive back, Hadley and the kids dropped me off at Kiwi Foo Camp in the delightful town of Warkworth. It was a bit of a shock going straight from holiday to the non-stop uber geek fest shop talk marathon.

Highlights for me were:

• Lobbying Telecommunications Minister David Cunliffe to make peering a priority. The point came across loud and clear.
• Getting the low down on Firefox 3 (scroll down to items 3.5 and 3.6). Lots of goodness in the works, but most importantly is the offline caching for web apps. I think it strongly supports my prediction that in 2007 the browser is more important than the OS.
• Good design discussions on faceted navigation and ambient signifiers.
• Seeing the OLPC in the flesh. It’s the type of device that makes you wish you were a kid again. Nevertheless, I’m still highly dubious about the UI. As Che noted, “That’s what you get when you have Flash designers create an OS”.
• Most of all, meeting and spending time chatting with some super smart, super nice people. Old friends and new friends alike.

Oh yeah…being able to show Xero was thrilling and scary. Fortunately, the response was awesome! Foo represents a very tough crowd. Seeing their excitement over Xero makes me really proud. I wish more people showed their projects. I happen to know quite a few people who have some very interesting developments in the works that didn’t get shared. Foo Camp seems like a great place to get extremely valuable feedback.

When Foo ended I caught a ride in Rod’s Maserati down to Auckland to join up with the family. They were staying at the Quest Ponsonby, which I highly recommend – great accomodations in an ideal location. We even ate real Northern California quality burritos at Taqueria (I’m wiping saliva off the keyboard as I write). It was actually quite strange being in Auckland, almost like being in another country. It caused me to question the much bandied slogan “nothing beats Wellington on a nice day”.

Having said that, it was nice to come home to such an easy going city on such a beautiful day.