Getting Used to Features

People like features. People look at features when they’re choosing the software. People get used to features. Then, they’re not features any more – they’re obvious functionalities.

Vendors like new features. Vendors sell their software showing their new features. Vendors get used to features. Then they’re not features any more – they’re just part of legacy code. And occasionally they’re removed or changed.

I’ve once upgraded my Firefox from version 1.5 to 2.0. And then settings connected with a way the links are opened have changed. They’ve taken away my feature. It’s the easy case because I could change browser options, although it’s been quite ambiguous. However I’d gotten used to the “feature” so I wouldn’t even ask if my new browser can work the same way.

Few days ago I got a new notebook. On the old one I had Clear Type turned on. I wasn’t aware how I got used to it unless I saw crappy fonts on the new machine. That’s another easy case because I could quickly install Clear Type Power Toy without even going through Windows configuration. However in both cases I was confused. Hey, wasn’t that already on the board?

Things get harder when you develop your software for a bunch of companies and hundreds of users. You quickly pass the border when you can’t know every scenario the users will follow. You can quite safely assume that at least several of people adopted every single feature of the application, no matter how crappy they can be. They came to like features. They got used to features. They don’t consider them as features any more.

Here’s the trap. Now, you’re a hostage. You can’t change them and even improve them because you’ll piss off you users than. And, let me guess, you don’t want to piss off your users, do you?

That’s why you have to remember about boring check list every time you prepare upgrade for your application:

• Configurability. When changing the way some process works, add an option in configuration and let the user choose. It’s also a good resolution when you face two groups of users who want the function to work in two mutually exclusive ways. One time we even wanted to add an option where the user could choose how the feature should work: either “ambiguous” or “wrongly”.

• Defaults. OK, you’ve added dozens of settings in your configuration window. Congratulations. Now, all defaults are set in the way that will show all new features, right? Wrong! It’s the perfect way to take away functionalities people got used to. With default configuration the new version should work in the way the old one would, at least in areas which were altered by the upgrade. You have to find another way to show off with your new stuff.

• Basics. Things like navigation, especially my favorite keyboard navigation, main functionalities etc. I wouldn’t mention them if I haven’t seen companies violating them.

• Inform and help. When you don’t have a choice or you consciously decide to change old features being aware of consequences, try at least to reduce users’ frustration. Inform them which features are being changed. Help with adjusting the application to work like it used to. If you can ask them before the change if it’s OK to implement planned changes. We’ve done that once and at least it was a kind of justification for making a change we had to make because of architectural reasons.

That’s of course just elementary, but it’ll help you current users to feel familiar with the new version. You don’t have to follow, just ask yourself if you do care about that.