Of course, as one door opens another one closes (to mangle a cliché). DNA has been a fantastic experience, and I thank them immensely: they’re a bloody talented bunch doing great work for clients they really care about. I will undoubtedly miss the place a lot. But it’s exciting times ahead for DNA with new blood and fresh ideas, and I’ll be watching on with interest.

So, on to business: you know how internet banking could be better? Email me.

Check out this screen capture of the feature in action – in the first attempt I accidentally roll over the ‘Darryl Gray’ menu. I then reactivate Spotlight and try the exact same thing again:

Brilliant!

But it gets even better: I have been showing this feature to a bunch of colleagues, demonstrating the simple-but-cool artificial intelligence involved. But because I have now ‘accidentally’ deactivated Spotlight on so many occasions, my computer thinks I am such a dullard that it will no longer allow me to deactivate Spotlight via mouse roll-out. It has revoked this simple feature because it is clearly well beyond my hand-eye coordination abilities. Fantastic!

This simple feature will have saved thousands—probably millions—of moments of annoyance. It could easily be done using JavaScript in the web world too. So why don’t we see this kind of stuff more often?

Well-structured agile projects with strong leadership will almost always produce superior results to the traditional ‘waterfall’ method, but the biggest downside to an iterative approach is that very few people know how to work effectively that way. Before you know it, you’re stuck in endless loops of iteration without getting closer to a result. Budgets blow out, projects are not delivered, and the bosses are not happy.

So how do you avoid this trap? Here’s a simple rule set that’s worked well for me:

1. Come up with a basic design
2. Figure out the three greatest risks in your design (e.g. does that typeface work? Does the navigation need to be bigger? Do we need a graph?)
3. Develop prototypes that address those risks (could be sketches, graphics, working code, etc. – whatever it takes)
4. Test these prototypes
5. Come up with a refined design based on the test results
6. Go to step 2

It sounds totally obvious, doesn’t it? This basic outline was formulated by Barry Boehm in 1986 (he called it the ‘Spiral Model’); it wasn’t the first iteration model ever developed, but it was the first model to explain why the iteration matters (check out the Wikipedia entry on Spiral Models if you want the whole guff).

The beauty of the steps above are their simplicity and focus. I personally like picking the top three risks at step 2 and focusing on nothing else. In most cases, the smaller things will sort themselves out anyway. The secret is to make many small iterations, all of which refine the previous design using a feedback loop.

Give it a go – I’m sure you be amazed how quickly you get to a good result!

This is exactly what I imagine happened to Telecom Mobile‘s ‘call back’ feature. The idea is great – I miss a call from someone and can call then back with a simple key press. I personally want to use it whenever I’m very pushed for time or don’t have a pen and paper handy.

Here’s how it goes: after listening to a message, my first option is “To call back the caller, press #”. So far, so good. Then, at an agonisingly slow pace:

[long pause] “The system will now connect you to phone number [pause] … 0 … 2 … 1 … 7 … 5 … 4 … 8 … 3 … 7 … [pause] please note that call back calls are charged at your normal mobile rate, plus any applicable voicemail retrieval charges. To cancel call back and return to your messages, press *” [very long pause]

That takes 28 seconds! If I’m running to a meeting or waiting at the traffic lights then 28 seconds may as well be 28 minutes. And the crazy thing is that almost every aspect of the message is useless:

• [long pause] – Okay, the system is connecting or whatever. Fair enough.
• “The system will now connect you to phone number …” – Jeez, are you kidding me?! Does anyone really need to have the term ‘call back’ explained to them?
• “0 … 2 … 1 … (etc.)” – I’ve never met a customer who wants this information repeated to them. Sure, there’s a chance you’ll be calling Kazakhstan at $9.20/min or something, but its an edge case.
• “Please note that call back calls are charged at your normal mobile rate, plus any applicable voicemail retrieval charges.” If I’m in a hurry, I don’t want to know about this. Anyway, I assume this is all in the small print of the contract I signed?
• “To cancel call back and return to your messages, press *” – Okay, this is useful, but the term ‘the straw that broke the camel’s back’ is springing to mind.

So, I never use the service – either because I don’t have 28 seconds to wait, or because it’s quicker to find a notepad, or because it’s quicker to hang up, check my call history, and dial back from there. And that is highly stupid.

Compare this to Vodafone – their voice is much snappier, more urgent:

“Received from 0-2-1-7-5-4-8-3-7 – to dial now, press #. To dial another number, enter the number then press #. This call will cost your normal airtime charge, plus your voicemail access charge. To cancel, press *.”

Hallelujah. The whole thing is actually only a few seconds shorter than Telecom, but at the 8-second mark I am given the option to connect the call by pressing #. That’s smart – all the lawyer-speak and other options are left to the end, where the user doesn’t have to suffer them.

There’s still room for improvement, of course:

• Why not use the same key to select and confirm a call back. With Vodafone, ’0′ is the option for call back, while ‘#’ connects the call. Why not ’0′ then ’0′, or ‘#’ then ‘#’ so the user doesn’t need to think? Even better, advanced users could connect a call instantly by pressing the same key in quick succession.
• Structure it even more efficiently: start with “Press # to connect to …” so I don’t need to hear the number.

This happens way too much. Sure, I know from experience that a million things can go wrong, there are all these technical constraints, blah blah … but none of that matters to the user of the feature. So: why did we add that shiny new feature, again?

TIP #1: TO SHOW HIERARCHY, TRY CHANGING TYPE ONE ASPECT AT A TIME.

The theory is: to differentiate one piece of type from another (e.g. a heading from body copy), you only need to change one aspect of the type. In practical terms, this means you can change the heading weight (e.g. normal to bold), style (e.g. normal to italics or caps), typeface (e.g. Arial to Georgia), colour, or size … but you only need to change one:

But if the body copy will contain bolded/italicised/capped text (for emphasis, quotes, etc.), and most apps/site will, then you’ll need to change one more aspect of the heading to differentiate it:

One of the most useful real-world applications of this tip is designing left-hand navigation. There is typically three to five levels of hierarchy in the left hand navigation of a big site, so you need to be very disciplined with typography. A simplified example is shown below, with some body copy on the right.

In the first version, all the type is the same (apart from the links being blue). In the second version, the navigation’s current page (‘List item 1′) and the sub items have been changed by one typographic factor each, as has the body copy title. The third version adds one more typographic change to each element. In theory, this is now the most efficient way to show the relative hierarchies of the page elements. [Note that there are several 'most efficient' ways, depending on which particular factors you choose to vary (weight, style, etc.)]

TIP #2: TRY TO LIMIT YOUR DESIGN TO LESS THAN FIVE TYPOGRAPHIC STYLES

This tip evolved from print design, where the rule of thumb is no more than three styles per design (usually for posters or similar ‘one-page’ pieces). But large-scale websites or complex web applications usually require more than three styles, because there is so much to communicate on a single screen. Someone suggested five, and it seems to work. Sometimes it’s inevitable that you’ll need more, but the most important thing is to be disciplined in your approach. So if your design is starting to feel haywire, check how many levels of type you have – can you re-use some styles elsewhere, or merge some styles? It’s actually not as hard as it sounds, and 9 times out of 10 you’ll get a better result.

BUT REMEMBER:

There’s nothing wrong with breaking these rules! The design should always ‘feel’ right, no matter what the rules say. However, the better you understand these rules, the more effective you’ll be when you decide to break them. Check out some of your favourite apps/sites/designs and see if they adhere to the rules above.

And if you try these tips, let me know how you get on!

There are two types of failure: (1) ‘bad’ failure, where failure is the outcome or final step in the process; and (2) ‘good’ failure, where failure is part of the process that leads to success. So failure is a positive experience if we can learn from it and/or if we can progress from it. For example, the game designers of Team Fortress 2 (a shoot-‘em-up videogame) found that they could change a player’s feelings about game death from negative to positive just by providing information about how they died, and how they could improve.

So, how can ‘good’ failure be used to similar effect in web applications? Here are a few clever examples:

• Google’s ‘Did you mean:’ search feature. Google recognises common spelling errors and offers a correct spelling, allowing me to learn something. By also providing a link to search the correct spelling, they have ensured that my search process won’t end right now with a ‘bad’ failure (ie. failing, with nowhere to go). The icing on the cake is that they’ve sped up my process by offering a couple of search results from the correct spelling. Smart!
  
• Twitter’s ‘Fail Whale’. When there’s an outage on Twitter, users see the ‘Fail Whale’, an illustration of sleeping whale being blissfully whisked away by little birds. It’s quirky, unexpected, and abstract – and that’s the genius of it: we don’t really learn anything except that Twitter is broken, but the mysterious image begs our minds to imagine what might be happening behind the scenes. And because the Fail Whale is so different to a standard error page, it became popular to ‘tweet’ about it once Twitter was back online … which means that the Fail Whale allows you to continue the Twitter experience, even when Twitter is broken!
  
• Wishlists. When Amazon.com popularised the online ‘Wishlist’, they smoothed over a traditional area of online failure: point of sale. Point of sale failures are slightly different to the examples above because (usually) the user chooses to abandon the sale, rather than the system letting them down. Wishlists made it okay for users to earmark an item as a future purchase or gift, and continue shopping. On a psychological level, clicking the ‘Add to Wishlist’ button also allows the user to mentally complete their interaction, which is an important aspect of good user experience.

But most web apps are missing opportunities to create good failures. The one that often irks me is online banking (NB: I haven’t used every bank’s online service recently; some may be doing this well already). Consider this scenario:

• You’re making a bill payment via online banking. At the end of the process, the system tells you that you have insufficient funds to complete the transaction. This failure point (currently ‘bad’) is the perfect time to do two things: (1) Offer some help or advice on how to avoid this problem in the future (allowing you to learn something); and (2) Offer the opportunity to transfer funds, or apply for an overdraft, etc., in order to complete the payment (allowing you to progress). This exact moment is also when you’re most receptive to an ‘up-sell’ like an overdraft or credit extension – it’s timely, relevant, and in context.

These are just a few of the many examples out there. Do you have any examples to share, good or bad?

A while ago, Air New Zealand launched their ‘Nothing to Hide’ campaign, a series of videos featuring actual AirNZ crew wearing nothing but body-paint and big smiles. The style is light and fun, and naturally anything too revealing is out of shot or obscured by a piece of luggage, armrest, inflatable life vest, etc. in a sort of Benny Hill style.

Of all the videos, it’s the safety demonstration that’s stuck in my mind. Most safety demonstrations, as carried out by the ‘live’ cabin crew, are surely a waste of time – how many people have you ever seen paying attention to one? Not only is the delivery robotic and unengaging, the content is too familiar to warrant our engagement (and, besides, it’s borderline uncool to pay too much attention!). That’s why the titillating AirNZ safety video is genius:

• Because the videos feature an all-nude cast, most people can’t help but look. Even when you’ve seen it a several times, you still look (just in case you missed something!). So at least some of that safety stuff must be going in.
• Switching to video must equate to more efficiency – not only do the crew not have to take positions, etc. but they can now continue on with their other pre-flight tasks. By my reckoning, this could save us 5mins of sitting in the plane before take off (or give them a 5min buffer, thereby decreasing risk of delays, etc.)
• The videos are well executed and fun to watch – they make AirNZ seem professional, caring, and cool, and they’re a nice way to start a flight.
• Because the videos are on screen, it’s more socially acceptable to watch and there’s no risk of making (uncool) eye contact with the demonstrator.

I’m not sure whether the above benefits were serendipitous or excellent experience design (probably a bit of both); either way the results are better for both AirNZ and their customers, and that’s got to be good.

This is a fairly new concept, and like all new concepts, one of the hardest things is telling potential customers exactly what you do and where you fit. You really want to reinforce who you are and what you do at every opportunity – so why not get the main navigation to pull its weight too?

The new Powershop.co.nz website

For example, the main navigation on the old site was:

• Home
• Why Powershop?
• How it works
• Pricing
• Demo
• Sign up
• Login

Looking at that, I have no idea what Powershop does or why I’d care. But armed with our ‘telling our story’ angle, we came up with:

• Home
• Better service
• Greater savings
• Smarter power
• Switch now
• Login

Putting aside a couple of structure and content differences, I think the wording in the revised navigation starts to really tell the Powershop story – (1) it’s about power, and (2) they’re sharper, cheaper, and smarter than normal providers. I think ‘Switch now’ is fantastic too, using a term (‘switch’) that is already very strongly associated with power but also clearly the main call-to-action.

Of course, solutions like this need to be sense-checked against other important factors such as search engine optimisation considerations, brand alignment, usability, etc. They should also be tested, varied, and retested to see what works best. But most importantly, does it give the viewer the desired experience? If not—no matter how clever—kill it.

You might only have a couple of seconds to entice a prospective customer before they lose interest. If they scan the navigation, and most will, why not use it to your advantage?

Basecamp's old sign-up link

Basecamp's new sign-up button

I wonder if we’ll start to see others move away from the standard Take A Tour/Sign Up For Free model. The new model has some interesting benefits:

• The ‘Plans and Pricing’ wording better aligns with most prospective customer’s next mental step – they probably want to check out the pricing before they sign up.
• Putting a ‘Sign up’ button on the homepage (even with a ‘free’ tag) might put up a reasonable psychological barrier to a customer: sure, it makes it clear that the key thing to do is sign up, but it also applies subtle pressure to decide whether they’re going to sign up. Making the button less confrontational and less demanding invites customers to explore further without making a mental commitment – kind of like the car salesman putting the keys in your hands before asking you to buy. [Incidently, the pricing page is a nicely executed sales funnel that visually pushes Basecamp's Goldilocks pricing model.]
• I reckon 37Signals have probably A/B tested this a lot. I doubt they’d make a change like this without the data to back it up.
• It still has the supporting line ’30-day free trial, sign up in 60 seconds’ – if the viewer is looking for a sign-up button, they’ll almost certainly click here.

Aside from obvious business goals, putting a sign-up button on the homepage has a lot of benefits – it orients the viewer about what we ultimately want them to do, and it’s useful and reassuring to know where the button is should they eventually want to proceed. The 37Signals approach is worth analysing because it opens the door in a more welcoming way to the customer, which might lead to more conversions.

Of course, there are a few other changes (good or bad) that may affect conversion rate: the sign-up ‘colour’ has changed from yellow to green; the links have changed to a button; and two distinct actions (‘sign up’ and ‘plans and pricing’) have been consolidated into one button.

What do you think?