Don't upgrade Web software, just keep improving it

When I logged in to my bank’s online system to pay some bills last night, I was greeted with the following message: “Bill payment system upgrade completed.”

Uh-oh. That’s a message I don’t want to see.

Thin-client software delivered through the Web can improve gradually and continuously, and that is one of its greatest virtues. When we could ship upgrades only once every year or two, we had no choice but to batch up the changes in ways that were guaranteed to disrupt the work habits of the people using our applications. But now we can trickle-feed those changes so that people can gradually adapt to them and we can more carefully monitor and adjust their experiences.

Unfortunately my bank’s bill payment service provider doesn’t operate that way. Along with a big-bang release of its back-end service, which added a variety of new features, it switched to an all-new Web interface. As a result, it took me a surprisingly long time to rediscover how to do the most basic thing -- namely, pay a bill.

Hint: The link that leads to the bill payment window should probably be labeled “Pay bill.” Or, at the very least, that link’s anchor title -- that is, the text that pops up when you hover over the link -- ought to say “Pay bill” rather than “Opens a new window.”

It gets worse. The old system would queue up payments from multiple accounts in a single screen. The new system, with “simpler navigation that makes paying bills easier,” won’t let me do that. Now I have to make payments from my household account in one batch, and from my business account in another. The forklift upgrade didn’t just temporarily disrupt my online banking experience, it permanently subtracted value from it.

As we’re all painfully aware, many of the Web applications pasted onto legacy systems present badly designed interfaces. When you analyze what’s wrong, it’s tempting to catalog the design errors, relate them to well-known principles and commonsense best practices, and suggest point-by-point fixes. But there’s also a systemic problem here. If you make a big-bang release, one that rolls up a bunch of new back-end features and delivers them in an all-new interface, you’re asking for trouble.

Sometimes there’s no alternative but to rebuild a system from the ground up, or to deliver a cluster of new features that, because they’re heavily interdependent, can’t be pushed incrementally. But that wasn’t true in this case. There was no necessary connection among the various new features: showing available payment dates on a calendar, improving the mechanism for adding billers, providing payment confirmation numbers. Nor were these features necessarily bound to the drastically altered portal interface.

The central tenet of modern test-driven development is continuous improvement by steady accretion of small, incremental changes, with continuous evaluation of the effects of each change. This model should apply not only to the unit-testing of modules of code but also to the field-testing of aspects of user interaction.

Businesses born of the Web, such as Amazon and Google, have always known that it’s now possible to evolve systems in this fluid way, and they’ve always made the most of the opportunity. Many businesses that predate the Web, though, still cling to anachronistic methods dictated by constraints that no longer apply. It’s not a winning strategy.