Tags:, , ,

It was inevitable that this blog would drift from human -to-human communications to device-to-human communications aka interfaces. Since we design the devices, and whether we intentionally design it or not devices have interfaces, interfaces are just human-to-human relationships one step removed.

That’s the justification, but really I just like to go on about interfaces.

Over on hates-software, Nicholas Clark is busy hating ATM interfaces.

…why use 3 of the 8 buttons to give me the options cash/balance/something-I-forget, and then add a whole extra bloody screen of “would you like a receipt?”.

Just make that 4 options up front - cash with/cash without

Maybe they got their programmers from McDonald’s - and it was only QA that stopped it saying “would you like fries with your cash?”

Why not indeed? Turns out, for once, the software got it right-ish. Nick is thinking like an experienced ATM user who has used their interface dozens of times and trained himself to its idiosyncrasies. He’s looking to make the experience as fast as possible for the expert, a classic programmer desire. But ATMs have to work first for the random guy off the street who’s never used this particular ATM before, then for the experienced user. The two are not mutually exclusive.

There is an interface design principle where a decision tree should be narrow and deep (or shallow and wide, but that’s another post). Each step should require a simple decision be made by the user, and compound decisions should be avoided.

narrow and deep

You generally want to go narrow and deep (many screens, one decision per screen) for the interface which produces the least slips — user knows what they want (their goal is correct), user hits the wrong button (their action is wrong) — with an untrained audience. This allows the user to think about one decision at a time (I want cash) and just skim the choices to find the correct action (push “Get Cash”).

The worst would be to combine the two choices together to have “balance on paper”, “balance on screen”, “cash with receipt” and “cash without receipt”. This defeats skimming. One can’t just think “I want cash” and press “cash”. You have to decide between two very similar looking “cash” buttons and examine them slowing the process down until you’re trained which one to push.

Then the bank will go and redo the design, reordering the buttons and rewording the labels so you have to start your rote learning all over again.

shortcuts for experienced users

Sometimes you can get away with this, like a “Fast Cash $40 From Checking” buttons on the first screen. That’s providing convenience for experienced users. Every one of these increases the amount of reading that must be done, and it’s very important that it looks very different from the other buttons. The other button to get cash should look different. “Get Cash” is good, it’s visually distinct by being much shorter and having a different first letter.

address the user’s goal first

The Washington Mutual ATMs make the mistake of asking “do you want a receipt” first thing. This is wrong. It derails the user’s thinking. They’re all thinking about the goal: “get cash”. The fATM should address that goal as quickly as possible, not ask about a secondary option that can wait until the end. It’s like walking up to a fast-food counter thinking “burger and fries, yum!” and the burger slave starts with “is this for here or to go?” Totally derails the customer’s thinking.

ATMs and fast food joints do this for technical reasons. ATM hardware often prints as they go rather than all at the end. Fast food joints want to streamline their ordering systems by being able to assemble the order while the customer is still deciding what they want, and the first thing they need to know is if it’s going in a bag or on a tray. Good for them, bad for the customer.

yes baby, do me shallower!

However, deep should be avoided where possible because it’s time consuming and asks too many questions. Reducing depth without increasing the complexity of each choice is optimal. One way to do this is to only ask questions when the user needs to make the choice. This would be the ATM asking about the receipt at the end, but then it’s still always asked.

Another is to assume some defaults and only ask when a user indicates they might like otherwise. You might assume most customers don’t want their receipts (check the number of receipts in the ATM trash slot vs the number of receipts printed) so by default they don’t get one. How does the user ask for one? With a human, the user just asks. But an ATM machine is a one way conversation, the machine is asking all the questions. One solution is to put a “receipt/no receipt” toggle on every screen, defaulting to “no receipt” but now that clutters up every screen and it’s even more for the new user to worry about on the screen and learn to filter out.

questioning eyes

A user *can* ask a machine questions, they ask with their eyes. When a user looks at the cash slot they’re saying “I’d like my money now”. When they’re looking at the card slot they’re asking “where’s my card?” And when they want a receipt they look at the receipt slot. And that’s where you put your “print receipt” button, right next to the receipt slot. Now the user drives the depth of interaction and they’re the one who knows what they want best.

Of course, this requires hardware modifications on an ATM so it’s unlikely to happen. But some gas stations employ it, remember that next time you hit “print receipt”.

PS Dear readers, this post could be a lot more interesting with some pictures. Send me in some pictures of ATM screens, would you? Also transit ticket machine screens, too.

These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Reddit
  • del.icio.us
  • Technorati