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

Last week, I got off the train in the morning and there was a TV reporter that jumped in front of me with a few questions about fare increases. I immediately sensed that she was trying to wind me up, get me irate. But I felt like I was mild mannered and not falling for the bait.

ME: “I can accept the price increase because I know they’re buying new trains, which we really need badly. So as long as I can see the results I’m okay with it.”

TV LADY: “But what if they don’t add the trains? Are you seeing what you’re paying for?”

ME: “I’m not seeing what I’m paying for yet, but I know they’re in the works.”

TV LADY: Strange devilish smile. “What if they raise prices again? Would that make you stop taking the train?”

ME: “No. They basically have me over a barrel. I don’t want to pay for parking, I don’t want to pay for gas, I don’t want to deal with a car. Maybe I could ride my bike sometimes, but not in bad weather. So for me the train is still the best option.”

TV LADY: Looks at camera man with a huge grin. “Thank you.”

Now watch how it was presented on air.

That’s not the angle I was expecting.

Everyone at work was mocking me for being the angry American.

…things-with-stories sell faster than things-without-stories. How much faster depends on the story.

…

The value of an item – in the mind of a consumer – is simply the difference between the anticipated price and the price on the tag. When the anticipated price is higher than the price tag, it’s a “good value.” When the anticipated price is lower than the price tag, it’s a bad value. Good stories raise the anticipated price.

I would also add that good stories get repeated.

Speaking of good stories, below are some from my reading list, via Good Reads (I’ve tried most of the competitors and this was my fave). I need a new book, so I would love to get your recommendations.

This SlideShare presentation by Peter Merholz of Adaptive Path is mandatory viewing for anyone interested in product design and marketing strategy.

My take aways:

• Why user experience is the differentiator
• Experience first, then features, then technology
• A real vision focuses on the user experience
• The value curve of the Wii vs. Xbox and PS3 proves: experience matters, technology doesn’t
• Leverage the system, place functionality where appropriate in the ecosystem
• Products are people – what kind of person is your product?

Agile Usability Testing

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!

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.

My favorite bits:

• involve users in your web application’s story
• make growth a social aim for existing users
• talk to your users (bad news > no news) … more likely to tolerate growing pains
• embed your service in others

(thanks Adam)

Found via (via Edurev via Reemer)

Here is the back story and source of the video. They’re currently making an updated version and they want you to contribute your thoughts and questions.

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.