An interaction designer tries to make a bank transfer

I just wanted to send some money to a friend in need. How hard could it be?

I live in Norway. My friend Hester is moving from Spain to Sweden. We both have British bank accounts. So if I want to send her money, the easiest way is from my UK bank account to her UK bank account. Yes?

No. Here’s what happened.

Dumb gadgets

My UK bank, Smile, started out as the UK’s first online-only bank. Sadly, they then sat on that competitive advantage for around 20 years without significantly upgrading the user experience, while all other online banking experiences overtook theirs. This means that among other sub-par user experiences, I still need a little device that looks like a small calculator, into which I have to put my bank card, physically, like an animal, if I want to authorise unusual payments or new payees.

But when the topic of sending Hester money first comes up, I’m away from home. And as someone who’s now lived and worked in Norway for two years, I’ve long since stopped even thinking about carrying that crappy little device around when I travel. So first I have to wait three days before I can get anywhere with this.

But now I’m home again, so let’s send Hester some money.

Step 1: log in to online banking using details that are sufficiently complicated to require a password manager (you’re using a password manager, right?).

Step 2: add in payment details to move money. I had to google the IBAN system to understand how IBANs are constructed, so I could work out from her IBAN (a) that Hester’s account actually is a British one, and (b) which bits of the IBAN are the sort code and which are the account number. That whole system could be way more human readable. But alternatively, if we just used IBANs for all transactions, I could enter the whole lot and let the bank figure it out, instead of having to do the heavy lifting myself. Do the hard work to make things simple.

Step 3: put card into device, then work through a sequence of low-accessibility dance moves involving inputting and retyping of poorly-formatted numbers (eight digits in a row without spaces, really?), a screen that is hard to read, and more. Break up long strings of digits into easily-read groups of two, three, or even four. Design processes that are robust to poor lighting conditions, and you will also be helping people with low vision.

Cooperative, my ass. And no, it doesn’t get any more readable.

… and that’s as far as I get, because, unlike in the above picture, the battery in the device is dead. No readout.

I manage to buy batteries (the flat round ones that look like coins) a day or two later. Then, using the world’s smallest screwdriver (how many people even have these? I’ve adjusted glasses with bigger), I take the device appart and replace the old batteries. The screws holding the device together are so freaking tiny and fiddly that I choose to wait until the weekend for daylight to put everything back together, because evening light and household lighting are not really good enough. Accessibility score: 1/10.

Okay. Now I have a working card-reader device, if by “working” you mean “something that is hard to read and hard to use”.

Comedy of errors

I log in. I’m all ready to go. I enter all the payment details, but the system throws an error because I missed one of the fields I was supposed to fill out. Guess why? Because the field already had words in it, so I just blew right past. Default-selected or prefilled fields seem to deflect people’s attention; also don’t use placeholder text instead of a label.

But okay, now I can put the card in the device and do the dance of super-carefully checking the correct digits and correct order to type them in (and no, that device display is not easy to read under, well, any lighting conditions) and … oh. An error. Specifically, an incompletely-written error that directs me to “check the following fields”, without then specifying which fields are a problem. But I’ve filled all the fields in! Always write error messages that let users recover.

I try again. Again, I fall foul of the pre-filled field (really, this is not a good interaction design pattern), but okay, I correct myself. And again, the transaction fails and just gives me the same error. And yes, I even try it again while remembering to interact with the easy-to-overlook field, to make sure I haven’t thrown an error before attempting the transaction. Nada.

At this point, I don’t think the problem is clumsy fingers or the occasional transposition of digits that my brain likes to do, you know, for yucks. But! My bank has recently started offering a new Live Chat feature. This seems like a good time to try it out.

Time out, time out

I wait. I am number 1 in the queue (the advantage of doing this on a Sunday evening). Am I now being served, or still waiting? There’s a clock icon; maybe that means ‘wait’. I wait. Design user flows that make explicit what is happening, and what to expect next.

After a few minutes, I get a message from ‘John’. We go back and forth in the chat window as I explain my situation and he asks follow-up questions — maybe he’s working a flow-chart.

Maybe John is also simultaneously working other customers, or is a slow typist, because everything takes a bit longer than you’d think it might. Which means that after a few minutes, I get a timeout warning from my bank in the main browser window. I do what any sensible person would do: I panic. I mash the mouse pointer over the “Stay logged in” button. Doing this brings the main browser window into focus — and my chat window disappears.

Am I still chatting with John? I take a punt on pressing the Live Chat button in the main browser window, and up pops the window containing John, and our chat. Phew. But come on: if you have a live chat service, at least integrate it with the system that monitors timeouts.

This happens two more times while John is trying to find out what is wrong. Each time is stressful: I do not want to get logged out and have to start over explaining everything to someone else.

John cannot solve my problem; there is no record of my transactions having gone through. He suggests trying again tomorrow, and not to try again tonight in case anything has gone through.

When choosing to leave the chat, I get a system-level dialogue that doesn’t fit into the chat window, cutting off most of the “OK, quit” call to action — see screenshot below. I squeeze my mouse pointer into the narrow band of pixels that ought to be an easy touch target. Pro tip: make sure system-level alerts work in your mobile-sized chat window.

Yes I ould like to end this chat, but I’m having great difficulty icking O. (Avbryt is the Norwegian for Cancel, by the way — I’m using my Mac in Norwegian.)

The same chat window then asks me for feedback on the Live Chat service. I start typing something about my frustration with nearly getting logged out several times. Fittingly, at that moment, the timeout dialogue comes up again. I mash it to make it go away and … now my chat really has disappeared, along with the half-written feedback. Good job, Smile.

I’m sufficiently pissed off now that I go looking for an alternative feedback mechanism. I click on the Help page and start reading, but then something even better happens: an actual survey window pops up.


I click on the Complete Survey button. Nothing happens. I click again. And again. I click repeatedly. Nothing. After a few more seconds, the popup disappears. I have missed my chance.

Oh, just insert your own Charlton Heston GIF in here, I don’t even care anymore.

Per John’s suggestion, I try making the transfer again the next day. I try a couple of times, in fact, but I just keep getting the same unhelpful error. At this point if it were anything else (a charitable donation, say, or buying something), I would give up. But I really want to send Hester some money.

Taking my business across the North Sea

I log in to Gjensidige, the bank I use here in Norway. This just became an international money transfer, but that’s a pretty easy option to find in the menu.

I start entering the requisite information, but quickly run into trouble when “recipient” turns out not to mean “person” but “IBAN number”. Obviously. ?

This is a field marked “Recipient”, but what the bank means is “IBAN”. Why isn’t it just called “IBAN”? I am approaching this task as a human sending money to another human, and I expect field labels to reflect that.

Originally I wrote Hester’s name under “Recipient”, but it was only after I then filled out the “Country” field that the “Recipient” field validated against the country. The error message reads “Account number is not in the correct format, we only accept IBAN-numbers for transfers to Great Britain”. Always put dependent fields after their dependencies, otherwise you are setting up interaction-design pinball, with your user as the ball. And yes, this only gets worse for users of assistive technology like screenreaders or screen magnifiers.

Of course, when I get to the bit where I fill out the recipient’s personal details, then suddenly ‘recipient’ does mean a person. Use labels consistently, and call them things that make sense to users in the context of their tasks.

Oh NOW a “recipient” is a person. And stop yelling at me if I fill out fields in a different order from you (all I did was shift focus out of that first field, to take a screengrab. Way too shouty).

Because this is now an international bank transfer, I also need a postal address for Hester. I assume this is something to do with blah blah money laundering European Economic Area blah. But what to type? Hester has a UK bank account which might be registered to a UK address, while she is moving from a Spanish address to a Swedish one. The postal address has to be the one registered to that bank account.

Fortunately for me, Hester checks her email.

Boom. Done. FINALLY.

Good gravy, people.

Solving the simple matter of sending money to a friend took me, in between travelling and working, 10 days. TEN DAYS. I could have walked from Oslo to Stockholm (for 16 hours a day) in that time, and handed Hester the money in person. Because when I started this process, Hester had yet to move, and by the time I was finished, she’d moved. And I had really, really wanted her to get the money beforehand.

Alternatively, I could have walked into any money transfer service in Oslo and wired the damn money — I’d have paid much more in fees, but I wouldn’t have felt like I was wasting my time or raising my blood pressure unnecessarily. I wouldn’t have added to my already heavy to-do list, or spent a week repeating variations on the thought “oh crap, now I have to…”.

I’m left kind of exhausted by the whole thing. Hester gets her money much later than I originally indicated. And anyone with low vision, poor fine motor function, or who relies on assistive technology to use a computer would have failed on something that really should have been a simple task: transferring funds to a friend. Is this the best we can do?

If you liked this, you may also like An interaction designer books a holiday.

Author: Chris Atherton

Collect by: