geek2geek

Let me tell you a design horror story. It has to do with my first experience with the simple act of getting a transit ticket from a BART machine. First, let us contemplate one of the BART’s horrors:

Oh god, I don’t even know where to start either using it or explaining why it’s so horrifying. But this clunking horror is not the machine I have come to tear apart. I’m going to talk about one of their more modern machines. Unrestrained by a mechanical interface, with all the power of modern computing technology behind it, they chose to create… well, you’ll see.

You purchase travel cards with various amounts of cash on them. For a traveler just getting into the city that’s bad enough, I have no idea how the transit system works or what travel costs. First thing I have to decide is “how much money do you want to spend on transit”. I DON’T KNOW! I’m not thinking in terms of “$20 worth of travel” I’m thinking “I need to go from the airport to downtown”. It would be great if it allowed me to add money to my card like that. Push “airport to downtown”. Voila! The actions match my goal. But no, I have to translate my goal into a dollar value which as a new user of the system I have on idea how to do.

Please go on!

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.

Please go on!