The Dangers of Redesigning a Web Application

The web is such a transient medium that it’s common place to launch a site and then keep tweaking the hell out of it until you’re satisfied that the user is getting the best possible experience. It is, of course, one of the great strengths of the medium that changes, even seemingly large scale changes, can be made quickly and easily based on user feedback. It’s exactly this flexibility and publisher-friendliness that has lead to the web being such an accessible and easy publishing platform – you can try something out, and if it doesn’t work, no problem, you can change it. Try the same in print and you’d quickly run up bills of thousands.

This is something traditional software products have struggled with also. Get your user interface wrong and your product is difficult to use – sales decline, support costs spiral out of control, and you have to wait to the next revision until you can correct your mistakes. By this time, of course, you may have lost valuable customers who do not wish to upgrade.

When it comes software deployed on the web it would seem that these traditional problems are solved. As the interface for a web app is just the same as a web site you can fix any interface problems straight away. But the question is, should you?

Don’t go tweaking my heart

A piece of software, be it a traditional desktop app like Photoshop or a web base app like online banking, has to be learned. There’s no two ways about it – no matter how intuitive an application is, the user still has to go through a exploration and memorisation cycle in order to find their pace and use the app efficiently. The golden rule, in my own opinion, is that once you’ve encouraged someone to learn a process don’t go changing it.

Take Adobe Photoshop as an example. From versions 3 to 6, Adobe went through a strange phase of moving menu items. A tool would appear in one menu when new, move in the next revision, and then move back in the next. Clearly the engineers at Adobe had a great overview of the product and had excellent reasons for justifying each change, but for the user it was just confusing. If I learn where menu option x is, it no longer matters whether its placement is entirely optimum due to the introduction of additional, yet similar feature y, I just want it to be where I expect it to be. I’m earning a living here, and I charge by the hour. End of story.

The same goes for web applications. Conventional wisdom suggests that making lots of small tweaks to individual processes and interfaces won’t upset the user as much as a big uprooting. I assert that this is not so. Once a user has learned how to use an app, any small tweak is going to be unexpected. Lots of constant small tweaks lead to a general feeling of instability, no matter how well justified. Take my online banking as an example.

Small changes indicate instability

The bank I use have a very good online banking facility. It’s not fancy, but it’s reliable, solid, and works well with every browser I’ve tried. When I first started using it, I found the options for making payments to other parties slightly confusing. I had to select one menu option for payments to accounts with the same bank, another option for payments to accounts at different banks, and yet another for standing orders. This meant that the process for transferring money to my father (same bank) was different to the process for transferring money to my landlord (different bank). So that took a couple of times through before I got used to it, but that’s fine. Payments always worked.

Recently, my bank changed the payment process. Without notification or warning, the three menu options have been merged down into one with slightly different wording. Of course, the new process is far superior to the old and is probably how the payments always should have worked, but it seriously threw me. It was a sneaky change that I wasn’t expecting – turning a sixty second routine transaction into a five minute re-learning ordeal. The new process is excellent – but I’d already learned the old one, dammit.

Save all your kisses for me

It may be well to suggest not making tweaks to a web app once live, but this creates a tension, however. Both development and management want to fix up sub-optimal process or functionality in a web app as soon as possible, but I’m pleading with you not to force the user to relearn. So what’s a girl to do?

Obviously there are some changes that just have to be made. If a process is so drastically wrong that it’s preventing users from completing their tasks then something has to be done. But hopefully nothing that bad would ever get past beta testing. These should be few and far between.

The best solution I’ve found so far is to save up changes over a period of time and then make them all live at once. Make it a new version and announce it with a fanfare to the user. Spruce up the UI if necessary at the same time. So this still requires the user to relearn, but with the added advantage that:

The user has been told that things have changed and so are prepared and therefore unshaken when they notice the changes.
There is often perceived benefit and perhaps piqued interest associated with the concept of a new software version, which leaves the user more open to change (they feel like they’re getting something back).
All the changes are relearned together and in conjunction. Anecdotal evidence suggests that it’s easier to learn something new than relearn something old that’s just a little bit different. Old habits die hard.

Of course the frequency of new versions will very much depend on the application and its purpose. For online banking, I’d really rather not have to relearn more than once a year. For a daily-use app, a shorter rev cycle might be appropriate, but make it too short and the changes too small and you could risk confusing users and forcing them to relearn far too often.

So my message is this. Do everything you can, no matter how sound your reasoning, to group process and interface changes together into a package. Call it a new version or whatever and tell the user about the changes you’ve made. Be aware that every change you make forces the user to relearn and costs them time, no matter how sensible the change. Be aware that if a process can be refined to save the user a couple of seconds, yet it takes them two minutes to relearn, it’s going to take sixty times through that process before the user sees any time benefit.

Comments

§ David House: ‘If it ain’t broke, don’t fix it’.

I absolutely detest that expression. My theory is that if you don’t have a huge userbase, tweaking is acceptable (although not too frequently). Adding in new features, though, is a whole new kettle of fish (now there’s an expression I like :)). It’s generally fine, as long as it doesn’t get in the way of existing features, and is genuinely useful.
§ Drew McLellan: Well true, sometimes you have to grasp the bull by the horns and set the cat amongst the pigeons.
§ Kenneth: This is an article that decision-makers need to read. And, really, it goes beyond web apps to business web sites in general. I don’t know how many times I’ve gone to use some retail site to find that the path to the product I want isn’t the same path that it was last week. Changes, renovations, better code, better logic, these are all great; they shouldn’t be sprung on the user, though.
§ Bill Snebold: I have to disagree with you about calling the menu changes in Photoshop through the years as being “strange”. To me the changes were absolutely necessary in most cases. When Adobe added layers to PS, interface designers needed to reorganize the menus so they made sense in handling how users would now interact with the program. If they hadn’t done this, users would be forever looking around for where certain function were. The top-level menus would become irrelevant. Over time, the whole program would become a junk drawer.
§ Barry: Whilst I agree that changing your UI is going to cause problems, I’m not so sure that small incremental changes are going to upset the proverbial apple cart. If the UI isn’t intuitive to begin with, it’s broken before you start. If it’s already working, then small changes should be ok, especially if your regular web user hits your site frequently. The less they view your site, the more likely they are to pick up multiple ‘small’ changes that look like one big one. It is all down to release cycles.
§ Mike Johnson: I find that I always want to change my designs after they are launched. Usually, I am not completely happy with them until they are tweaked to perfection. I am sure this annoys the user, but who cares, it’s for their own good :) Something that I have observed is that spending time away from your design—not looking at it once—is very beneficial. You gain an additional perspective as a “user” as opposed to the “designer”. You notice little things that need to be fixed that perhaps you never noticed while making the original design. I call this “designer tunnel vision”. I think there should be a mandatory two week waiting period between finishing a design and launching it where you put the design away and keep it there. In a perfect world without deadlines this would be great!