While at my local bank today, I had an unpleasant end-user experience with the user interface for their automated teller machine.
My goal was to deposit 10 cash bills into my account, an action I have performed many times before.
This series of lived-out Use-Cases started out well: a blinking light prompted me to begin by inserting my bank card in the adjacent slot. Very nice and clear. I entered my PIN on the large-button key pad and successfully and easily logged in.
Next, I used the touch-screen to select my action (Deposit), my account (Savings), and the deposit format (Cash). The ATM promised to count the stack of bills and determine the exact amount of the deposit.
That's where the problems began.
The "Deposit Cash" sequence of events now expects the user to insert the stack of bills into another slot, indicated both graphically on the touch-screen and by another blinking light.
But when I inserted my stack, whose total number of bills was well under the posted maximum number of bills the slot can handle, the hardware failed to draw them in for analysis and recognition. The mechanism that drew them in successfully pulled in the top bill, but only partially accepted the remaining ones.
The ATM switched to Error mode and its Return Cash use-case, so I took back the bills that had failed to insert and, after a few seconds, it returned the one bill it had captured.
I backed up in the process, smoothed the bills, and tried again. Same result. I gave it a third attempt with the same failure result again. In good baseball fashion, I considered three strikes to be out.
Problem #1 was a hardware failure to accept the stack of bills. In their favour, the error produced a clear message and easy restoration of the start state.
Problem #2 was that, unfortunately, there were no indications of what I could do to avoid the error and get the machine to accept my cash. I retried exactly the same thing 3x because it gave me no instructions on what I could do differently.
Problem #3 was a lack of other options. I like the high-tech ability to do a no-envelope cash deposit, one that promises easier and quicker access to deposited funds with less time that the bank considers the finds on hold.
But by going envelope-free, there were... no envelopes. I don't think the ATM even had a slot for such an input. It had to accept my cash or my deposit would have to wait until I could deal with a human teller, a privilege for which some banks charge a small fee. if the technology rejects the deposit, how can it be completed?
I decided to try one more time, but this time I would take my small stack of bills and insert it in stages, as even smaller stacks of bills.
Aha! Success! I fed half of them, 5 bills, in the first try, and the ATM accepted them, correctly identified and summed them and displayed my deposit total.
But when I readied the second set of 5 bills, I discovered that I could not add them to the same deposit. There was lots of screen space to add more entries, but the use-case flow as implemented required that I Confirm the deposit amount, Choose whether or not to print a Receipt, and Choose whether or not I had any other transactions to do.
For the second half-stack of bills, I had to start the Deposit process all over again. For the 5th time.
Problem #4 was that the deposit sequence accepted only a single bunch of things. It did not allow for a deposit of mixed modalities - e.g. Cash and Cheque; it did not allow for multiple stacks of cash.
I can imagine there are real reasons for many of these limitations I encountered today, but I was left frustrated that the sleek machine, touch screen, and user interface forced me to start over so many times.
An exercise for the reader: How would you design differently the processes involved in this scenario?
My goal was to deposit 10 cash bills into my account, an action I have performed many times before.
This series of lived-out Use-Cases started out well: a blinking light prompted me to begin by inserting my bank card in the adjacent slot. Very nice and clear. I entered my PIN on the large-button key pad and successfully and easily logged in.
Next, I used the touch-screen to select my action (Deposit), my account (Savings), and the deposit format (Cash). The ATM promised to count the stack of bills and determine the exact amount of the deposit.
That's where the problems began.
The "Deposit Cash" sequence of events now expects the user to insert the stack of bills into another slot, indicated both graphically on the touch-screen and by another blinking light.
But when I inserted my stack, whose total number of bills was well under the posted maximum number of bills the slot can handle, the hardware failed to draw them in for analysis and recognition. The mechanism that drew them in successfully pulled in the top bill, but only partially accepted the remaining ones.
The ATM switched to Error mode and its Return Cash use-case, so I took back the bills that had failed to insert and, after a few seconds, it returned the one bill it had captured.
I backed up in the process, smoothed the bills, and tried again. Same result. I gave it a third attempt with the same failure result again. In good baseball fashion, I considered three strikes to be out.
Problem #1 was a hardware failure to accept the stack of bills. In their favour, the error produced a clear message and easy restoration of the start state.
Problem #2 was that, unfortunately, there were no indications of what I could do to avoid the error and get the machine to accept my cash. I retried exactly the same thing 3x because it gave me no instructions on what I could do differently.
Problem #3 was a lack of other options. I like the high-tech ability to do a no-envelope cash deposit, one that promises easier and quicker access to deposited funds with less time that the bank considers the finds on hold.
But by going envelope-free, there were... no envelopes. I don't think the ATM even had a slot for such an input. It had to accept my cash or my deposit would have to wait until I could deal with a human teller, a privilege for which some banks charge a small fee. if the technology rejects the deposit, how can it be completed?
I decided to try one more time, but this time I would take my small stack of bills and insert it in stages, as even smaller stacks of bills.
Aha! Success! I fed half of them, 5 bills, in the first try, and the ATM accepted them, correctly identified and summed them and displayed my deposit total.
But when I readied the second set of 5 bills, I discovered that I could not add them to the same deposit. There was lots of screen space to add more entries, but the use-case flow as implemented required that I Confirm the deposit amount, Choose whether or not to print a Receipt, and Choose whether or not I had any other transactions to do.
For the second half-stack of bills, I had to start the Deposit process all over again. For the 5th time.
Problem #4 was that the deposit sequence accepted only a single bunch of things. It did not allow for a deposit of mixed modalities - e.g. Cash and Cheque; it did not allow for multiple stacks of cash.
I can imagine there are real reasons for many of these limitations I encountered today, but I was left frustrated that the sleek machine, touch screen, and user interface forced me to start over so many times.
An exercise for the reader: How would you design differently the processes involved in this scenario?