Why keeping it simple would be a better choice for TransferWise

Overview

In the world of web application development, we sometimes face technical decisions whose trade-offs extend beyond the technical. Those non-technical trade-offs can be subtle, and perhaps difficult to identify, yet critical to the business.

In this article, I want to highlight as an example my experience with the TransferWise payment system, in which technical decisions ultimately work contrary the core of the product.

Background

In the early days of web applications, browsers like Firefox and Safari could only render web pages whose contents were structured in HTML and possibly styled with CSS. Any “logic” that formed part of the application had to be executed on the server.

Whenever you clicked a link on a screen, you’d experience a page refresh as the browser sent the request data back to the server, waited for the server to perform any necessary checks and calculations related to the request, and then your browser would display the HTML/CSS that was returned by the server.

So in those days, your browser only displayed things; any “thinking” happened on the server.

Time progressed, and browsers gained the ability to execute JavaScript software, thereby opening the door to implementing “logic” that gets executed within the browser client itself.

One of the most common first uses was in signup forms, as the browser could check that your entered-twice passwords matched, without requiring a page refresh and request to the server application.

Things got even more sophisticated when the browser could make a server request that’s transparent to the user. You’ve probably seen that when entering your username in a signup form, seeing a small spinner appear to the right, followed by a green checkbox informing you that, “Yeah, that username is still available!”

As “front-end” technologies continued to evolve over the years, we’ve gotten to the point where entire web applications are implemented in JavaScript, and run within the browser.

So, today, a fundamental decision to be taken by a developer when he or she implements a web application is:

Should I implement this logic on the server, or in the client?

The argument I want to make in this article, is that often this decision should be taken by the organization, and not simply left to designers and developers.

Context is everything

The benefit of using client-side logic is generally a smooth and seamless user experience, since the user doesn’t have to wait for page refreshes. The trade-off, however, is the risk of bugs in the user interface, since the JavaScript and rendering engines between different browser (and even different versions of the same browser!) can vary considerably.

There are some application contexts in which the risk of interface bugs is compensated by the value of a seamless and interactive user interface:

  • For example, if you’re developing a fast-paced interactive game, it could well make sense, in the interest of a smooth user experience, to implement the entire product as a client-side application.
  • Or let’s say you’re implementing product that’s likely to be used by your customers several times daily. In that case, saving a few screen refreshes might materially improve the experience when compounded daily over the period of an entire year.

At the same time, there are some application contexts in which a seamless user interface does not compensate the risk of exposing the user to interface bugs. And, here, I want to highlight an example of a company that has absolutely taken the wrong decision in this regard.

Disruption of an industry

In the past, it was terribly expensive for me to pay European contractors from my American company. First, the transfer itself would cost about $30. But then, I’d lose over 3% with respect to the market rate when the bank would convert my USD source funds to the destination currency of Euro.

TransferWise completely disrupted the market of moving and transferring money internationally, charging a fraction of what banks charge. They do this by taking advantage of volume to avoid even having to make transfers, i.e. if Customer A in the US transfers $100 to someone in Europe, and Customer B in Europe transfers the equivalent of $100 to the US, TransferWise can make the two transfers happen simply through off-setting accounting entries, using Customer A’s money to pay Customer B’s recipient, and vice versa.

What is the TransferWise product?

So what is the TransferWise “product”? If you ask me, it’s the saving of tremendous time and costs when making an international transfer.

And here’s where TransferWise have really messed up. They additionally view their “product” as the experience of making a transfer, and from a front-end technology perspective, they have decided that a slick user interface compensates the risks of exposing their user to bugs associated with the heavy use of front-end technologies.

To be specific: The process of making a transfer with TransferWise involves five steps:

  1. You specify the source and destination currencies, and the amount to be transferred.
  2. You choose who is sending the money (in case you happen to have both a personal and business profile on record).
  3. You choose a recipient from a list of existing contacts, or create a new one.
  4. You choose how you’ll get the money to TransferWise, e.g. through an ACH or wire transfer from your bank.
  5. You review the transaction, and confirm if everything looks good.

Looks simple enough, but there’s quite some logic that has to happen:

  • You have to compute the amount of the conversion from the source to destination currency, based on the current rate.
  • You have to alert the user in case that rate expires during the process of setting up the transaction (i.e. if they take too long.)
  • You potentially have to walk the user through the “new contact” workflow.
  • You have to flag the user if the chosen receipt doesn’t have address details on file.
  • You have to walk the user through the “link new bank” workflow in the case they want to do an ACH transfer with a bank that wasn’t previously associated to their account.
  • You have to exclude the ACH option if the daily limit has already been exceeded.

So the process of initiating a transfer can get surprisingly complicated.

TransferWise’s flawed decision

Well, TransferWise decided to implement the entire workflow in one single web page, in which each step in the process is contained within its own component, that opens and closes accordion style.

The consequence of this approach, as opposed to pushing all the logic and checks to the server in page refreshes, is that during the entirety of my use of TransferWise, over the past few years, I have ran into user interface bugs probably more than 50% of the time.

And sometimes we’re talking about showstoppers—i.e. bugs that, in the name of a slick user experience, actually prevent me from making a transfer!

For example, the day that the confirmation button simply wouldn’t activate. Or the day when state wasn’t tracked across components and the confirmation button didn’t provide on-click feedback, such that multiple clicks of the confirm button suddenly skipped you multiple steps ahead in the process, leading to all sorts of chaos.

Or, what happened to me today…

I use TransferWise once a month to pay my European contractors. Since the only thing that changes each month is the amount I pay to each, I could really use “payment templates”. But since those don’t exist in TransferWise, the next best thing is to click “repeat payment” on some previous transfer, and then change the amount.

But it would seem that this isn’t the intended purpose of “repeat payment”, since clicking the option takes you directly to the confirmation component of the transaction screen. You can click back into Step 1, in order to change the amount, but I suspect my particular use of this feature is what caused me to see this, when finally returning to the confirmation component:

Try what again? Going from Step 3 to Step 4? Everything looks fine. What’s the problem?!

Neither refreshing the page, nor clicking “Confirm” removes the error message or allows me to proceed As with most of these UI errors at TransferWise, it would appear that I’ve reached a dead end.

But, in this case, guess what? When I return to my accounts page, I see that the transaction was successfully processed. So the error I was shown—i.e. the one that blocked the whole process—is itself erroneous!

Again, it’s all about context

So let’s backup and think about this.

  • Once per month I need to make some transfers.
  • I use TransferWise for this because they are fast, and save me a lot of money.
  • I do not use TransferWise because their transfer creation workflow is better than my bank’s. I don’t give a shit about that. If this were something I did 12 times per day, then maybe; but this is something I do 12 times per year.

Of course, it’s not impossible to have a reliable application that’s front-end heavy. It’s just that it’s much, much easier to have a reliable application that’s not. And in the case of TransferWise, a slick front-end doesn’t contribute to the core value proposition of the product, and my own experience demonstrates that there’s definitely inadequate value compensation in unnecessarily taking the risk.

Conclusion:

The very very last thing I want to experience in this context, are bugs that prevent me from making my transfer.

For the past year or so, each time I’ve experienced a UI bug, and have reported it to TransferWise, I’ve also take nthe opportunity to encourage them to reduce their dependence on front-end technologies, and give priority to making the process of creating a transfer as reliable as possible. But each time, missing the forest for the trees, their team have instead focused on trying to track down the particular bug I’m reporting (Have you tried that in Chrome?)

And so my hope is that through publishing this article, the larger issue might cross the radar of someone in TransferWise management, who’s in a position of considering the broader product goals.

The design of one-click feedback

Today I received helpful support from Kimberly Castleberry, who works at Yoast. At the bottom of her email was a mechanism to provide feedback:

I’m busy, but at the same time do want to “give back” in appreciation to Kimberly, because lord knows how shitty customer support has gotten these days.

So what’s my expectation—or rather hope—when clicking on this button? That it’s a one-click operation, just like unsubscribing from most email newsletters. But even then, those one-click email unsubscribes aren’t truly one click, because you still have to close the “You’ve successfully unsubscribed!” window.

That might seem insignificant, but that one little extra step actually registers a small amount of irritation in my mind. I’m not sure why, but perhaps it’s because I hate wasting time, and closing the window triggers an awareness of the cumulative amount of time I lose in a valueless component of the process of unsubscribing from the countless newsletters I somehow get signed up for.

But back to this feedback workflow: Yoast use HelpScout — and I love HelpScout! We use them too, so no knock on them—and after clicking the smiley face, I again registered that slight feeling of irritation having landed on a page where I have to take at minimum two further actions: (1) clicking the “Send” button and (2) closing the window.

The unfortunate consequence is that I’m unlikely to participate in those types of feedback opportunities again, so this is an area I feel could use some workflow design improvement, targeted towards making it a truly one-click, friction-free interaction.

End botched training data with auto-stop on loop

This morning, when my wife and I took off on our trail run, I started my exercise timer app. A few hours later, we returned to the starting point, got in the car and drove home. Pulling into the garage, as often happens, I realized that once again I’d forgotten to stop the timer at the end of our run.

Yet another set of recorded training data messed up.

Whether it’s Strava or RunKeeper on my iPhone, or my Garmin Forerunner device, this problem happens so often that it got me wondering about possible solutions. Since the great majority of my routes—whether running, hiking or biking—start and stop at the same location, this particular problem could be solved if GPS device and app makers added a simple “looping auto-stop” setting that automatically stopped the timer whenever I returned to my starting point.

So simple, yet effective! I’m going to forward this article to the folks at Garmin and Strava, in hopes they’ll add this feature to their products. And if you like the idea, maybe you can do the same.

(Of course, it’d need to be an optional setting, to allow these devices and apps to be used in multi-lap events.)

Hours of lost time because Delta airlines do not validate new account email addresses

A few months ago, a frequent-traveler named “Matthew Henderson” from New York City signed up at Delta.com, accidentally providing my Gmail email address instead of their own (which is likely some minor variant of mine.) Since then, I’ve been the lucky recipient of nearly weekly email notifications regarding Matthew’s ticket purchases, travel plans and seat upgrades. Next week, in fact, Matthew is traveling to Cancun—lucky guy! Continue reading Hours of lost time because Delta airlines do not validate new account email addresses

Pausing the Cloud

We have three Macs at home, which run an assortment of cloud-backup and synchronization apps—including Dropbox, CrashPlan, BitTorrent Sync and Arq.

Whenever any one, or combination of, these apps saturates the ADSL upload bandwidth, downloading then becomes very difficult. And that presents a big problem when trying to do things like watch content on iTunes, or have a conversation over Skype.

These apps all try to address the problem, but in collectively (and sometimes individually) ineffective ways:

  • They all provide for bandwidth limitation through configuration. That doesn’t help, though, when you have multiple apps trying to upload at once. And who really wants to limit upload bandwidth during the 95% of the day when it wouldn’t matter anyway, just to address the 5% of the time when it’s needed?
  • Some provide for automatic bandwidth reduction when detecting that the network—on the given computer—is busy. But this doesn’t help when you have the apps running on multiple machines on the network.
  • All provide for manual pausing. Only Arq provides a means of pausing through scripting (or via a command-line interface); the rest require manually clicking their menu-bar icons. Only Arq and CrashPlan allow you to specify the amount of time to pause; for the others, you have to remember to unpause them. And BitTorrent Sync’s menubar icon doesn’t even have a “paused” state (like Dropbox’s), which nearly ensures that an unfortunate event—like realizing the file you’re working on isn’t up to date—will be the thing that reminds you that it’s not running.

Although I’d love to find a single-interface, elegant solution to the problem, life right now would be much easier if:

  1. All such apps provided a means of scripted pausing. That way, using my iPhone while sitting on the couch, I could connect to Keyboard Maestro and run a macro that would pause every app on every machine on the network.
  2. All such apps provided timed pauses. That way, I wouldn’t have to remember to unpause them. And for those that don’t provide timed pauses, for goodness sake, at least provide a paused state of your menu-bar icon.