Upgrade or Change?
What does it take to upgrade the user interface in your application? Before you worry about this you should ask yourself what the difference is between a change and an upgrade. If the change you are making adds value for the users then it is an upgrade. If you are changing it just to make a change, then it’s probably not a good idea. That tired old UI might look bad to you, but remember that you have been looking at it more than your users have and you have gotten used to it. Get some other opinions before you devote effort to changing it.
Upgrade Risk
I was at a fast food chain recently that had a new coke machine with a touchscreen for choosing a drink. As I waited in line I noticed that the man in front of me was just looking at the main screen but not choosing anything. I reasoned that he must be making his mind up still. The main screen displays four options in large circles: “All Drinks,” “Low Calorie,” “Caffeine Free,” and “Fruit Flavored.” Inside each circle, under the label, the drinks scroll by from right to left to give you an idea of what will be in the submenu. He apologized that it was taking so long and then turned back to the machine. As he turned back the Coca Cola logo was passing through the “All Drinks” circle. He stepped towards the machine just as it scrolled out of view and he stopped, “Darn, I have to wait for it to come around again!”
After helping him to his beverage I thought about what I had just seen, and what it could teach me about software. This man was used to taking his cup to a row of labeled faucets and putting it under the one he wanted. All of a sudden this upgraded fountain drink dispenser was causing him problems. With these new machines you need to wait until you see the drink you want so you can click on it, he reasoned. The “All Drinks” button doesn’t look much like a button and I wonder how many people have come to the same conclusion as this man. No matter how creative your feature may be, the end user will find more creative ways to use and abuse it.
These are the risks you take when you upgrade. Someone will always find an unexpected way to look at the new user interface. In the case of the coke machine, I think the benefit outweighs the risk because the new machines provide many additional flavor choices by mixing drinks based on your selection. Most users will be educated as they use the machine, even if it is confusing at first.
The decision to upgrade something should be made with the original goal in mind, adding value for the user. If the value is just visual, like a new color scheme or new buttons, be careful to minimize the changes you make to the function of the UI. Avoid moving buttons around if you can leave them be. Try to keep the basic structure the same, so the user can find the things they need in the same location on screen even if the look has changed.
If your change includes new features, be sure that the value of the change is greater than the burden it will cause. If possible, add new tools in a way that won’t disrupt the old tools. The changes you are making may be great to you, but they must be sold to the user at runtime.
What about changing the visual structure of a page? These updates are a mix between function and appearance. These changes usually involve moving a button or changing some menus around. In a 2011 interview, Joel Spolsky warns against making these kinds of changes:
There was a lot of blowback in the office toolbar (they rearranged all the toolbars and menus) and at that point people did not need a new version of office. Everybody that I knew would have been perfectly happy with Office 95, Word 95, Excel 95. They were fine, those were awesome versions … but nobody needs anything that they’ve done in the last 15 years, so the changes they’re making can only be negative, all you can do is ruin their experience that they were already having, which was a perfectly fine experience.
Planning for changes
It is exciting to get started building a large web application. The beginning of the build is a time of tremendous opportunity to get everything right or wrong. The code you write at the beginning will determine the quality of the code, the product, and your life in the future.
The most dangerous risk when upgrading a feature is in changing the visual structure of your UI. For this reason, I recommend starting out with wide open pastures. This means that when you are building the initial design, you are imagining space for all of the buttons and menus that will be needed in the future. You can’t think of every feature you will ever dream of, but you can leave a place to put all of the buttons and controls. One of the clearest examples of this is in menus. When an application is new it might only need a few menu categories, which will lead to dropdown menus containing a few items. But think about the future because the last thing you want to do is move an item from one menu to another. For example, you might have a Guide button (without a dropdown menu), which leads to some documentation you wrote instructing users about your site’s workings. Instead, make this a Help menu with a Guide button. Why? Because someday you may want to add a button for Feedback, FAQ, About, etc… If you left Guide as a main menu item and added this Help menu later then you need to decide between moving the guide onto the Help menu, and confusing users when they are looking for it, or leaving it out on the main menu where it really doesn’t belong. These types of decisions are not hard to make as long as you take the time to dream up what kinds of things might be in the UI later.