Archive for the ‘design’ Category...

burned by an ATM

Monday, August 25th, 2008

About a month ago someone stole $300 out of my account. I carelessly left my ATM card in a machine at Wamu and walked away, and whomever noticed it stepped up and did the wrong thing.

Cold hearted, cold cash.

If it wasn’t for my online banking - I checked it that night, I would have never caught the extra transactions and reported my card stolen so quickly. I was pretty lucky I guess - I wasn’t mugged… and it was only $300, all of which my bank reimbursed.

But still it really disturbed me that night. I don’t know what upset me more, the fact that these two women, living in my neighborhood, stood right beside me and made the withdrawal, or the fact that I got burned by an ATM machine.
Yes, you heard me…it wasn’t completely due to my error, but because of the machine’s design! I think I told that to the Customer Service rep on the phone too, he wasn’t listening.
Here I side with the school of Donald Norman, who says that we are not at fault for mistakes or errors ,usually, but that we are mostly the victims of poor design. Just remember the last time you went to pull a door with a huge handle that screams Pull Me! when it was meant to be pushed or vice versa.

I know I’m not the only one. Many people I know have given their cards to machines and then walked away. Fortunately, if it was the end of their transaction, the card is just left hanging, then it gets sucked back into the machine and returned to the bank.
In my scenario, I know that nobody saw my pin number. So I assume that the screen was hanging there with my card saying:

Can I help you with anything else?
Can I help you with anything else?

I get this screen from time to time and think - “How thoughtful. Yes, I’d like to do something else….”
But this is the screen that allowed someone else to pretend they were me. This is the step that burned me. The last things to come out of the ATM were my receipt and cash, which are usually signals for Transaction Complete (especially the receipt). So out of habit I left the ATM, and this screen was waiting for the next person.

To check on this sequence I returned last week and made two tests to try and replicate the events that day.

The first time I didn’t get the outcome I expected. I knew I had made a deposit and then asked for cash, but when repeating these steps in Trial 1, my card came out at the end along with my cash and receipt.

But it could have went differently. During the ATM sequence, towards the beginning, the system asks if you would like to see the balance of your account. I chose this route for the second trial (Trial 2) and this is how it panned out:
Physical actions are bold. The highlighted steps are the shifty ones.

Physical actions are bold. The highlighted steps are the shifty ones.

That’s what happened! The end - or what seemed like the end - of the transaction came : I was given a receipt and cash. But the machine still kept my card and wanted to know if it could “help [me] with anything else?” “Let someone steal my money” or “Feel like an idiot” might as well have been options for me here.

A couple things I don’t understand from this sequence. Why would the fact that I look at my balance at the beginning of the transaction trigger a different series of events? Did the designer think that because I was doing more than the average customer at the ATM that I’m the kind of bank user that needs to do several more things?
In my mind, receipt + cash = done. Its a signal (I’m a lot like Pavlov’s dog). I wasn’t thinking about the fact that I didn’t get my card back yet. I get a receipt at the end of every other buying experience I have. Why should this be different? And again, I don’t know why I should get two different outcomes.

I wonder if they tested all these user paths for error. I would think that since it is a money-dispensing machine that is not intended for long-term use that they would design it to be totally fool proof. The fact that I know several people who have made similar mistakes means they must have not tested enough.
The last thing - I promise - that comes to mind is the ATM you find at your local deli - small screen, out of service at times, and always charging fees. They may seem like shitty little machines - but I will never lose my card at one. This is because most of these machines have a kind of a forcing function:

It’s called the SWIPE.

The card never goes into the machine. It stays in your hand! Either a) its cheaper to make machines this way b) they are not as rugged as the ones that take your card at the branch c) the designer just thought a little more about it.

Whatever the reason, you’ll never leave the machine with the card still in it ready for your, or the other guy’s, next command.

But if it falls on the floor, I guess you could say that it’s out of the system’s scope.

Taking the plunge into the Desktop

Wednesday, June 25th, 2008

I have recently decided to shift gears in my career path a bit. The few jobs I’ve had in the professional sphere have been in web design of some sort - either visual, markup, or ui/interaction. I did some client-side programming in Javascript, but now I’m deciding to take a bite out of Cocoa and Objective-C and try my hand at becoming a “User Interface Developer”.

One of the biggest changes is that I’ll be spending at least half (if not more) of my time writing code - that means staring at syntax-highlighted text files, compiler progress, and error messages. Although I did go through at least six months of this kind of work on the GMT, Objective-C seems (note I say “seems”) like much more of a serious undertaking than Javascript does.

One of my major motivations for this change of scenery is that I hope this development experience will make me more literate when it comes to evaluating and adopting new frameworks for my own projects (e.g. Noesys). The design patterns and algorithms I will (hopefully) learn will also help me better architect my own applications.

My other motivations deal with interaction and interface design. I have been reading about and trying to practice methods that lead to good goal- and user-oriented design. The web design that I have been doing lately hasn’t allowed me to follow these methods to their end. My present work is more about informational sites/portals, which focus on IA, site flow and presentation, less so on interaction and use cases. Advertising and click-through factor heavily in this world - sometimes at the expense of the experience.

Previous to this, I worked on the GMT which, as a web application, had a more task-driven design process. However the tasks and users were still loosely defined, in part are users were nobody, since we really didn’t have a client, and partly because are users were everybody - the app was primarily for searching and reading news stories, which can appeal to a wide variety of users and goals.

I see my new job as a more serious interaction design challenge, since I will be designing an application for a defined set of tasks and for a specific profession. This application will also be sovereign one - the users will be using only this application for an extended period of time. They will also be using it on a weekly basis (hopefully), so I will be able to consider most of the users as intermediates, rather than always as beginners (as is the case with kiosks).

The bottom line is - this application has to work well for people that will be using it often, and more efficiently than its competitors. I know that sounds obvious but I’ve never felt this burden of proof so strongly in anything I set out to design. My team mates and I will really have to strive to take into account facets of the users’ tasks and goals that other applications that do similar things may be overlooking. I will have to bust out all the tools I have learned in order to find out what users’ really need (not what they say)… code something that we think answers those needs, then test it to make sure it does. There’s no hiding behind entertainment, coolness, or sales numbers.

The other aspect I am thrilled about is that I will be doing some coding, which is necessary to me. I know I brought this up earlier, but when it comes to interaction design, it is important for my process. I need to see the behavior and try the alternatives. Its the same as a graphic designer being able to move type into different positions in Photoshop, step back and see if it works visually. Being able to make adjustments on the fly also shortens the design cycle, making room for more iteration (the guys at FAW summed it up nicely) We shall see.

So I may be saying goodbye to the web for a while. I don’t know how I feel about that. In a way I am very excited to learn something new (Cocoa) and really test my knowledge of design methodology. On the other hand, I’m going to miss things like CSS, browser idiosyncracies, and trying to fit everything in a 1024×768 screen for the masses.