There is very rarely progress without some cost. I was reminded of this recently by the news that a new piece of railway line - the Ordsall Chord - will cut off the world's first passenger railway station, Manchester Liverpool Road, from the main line and affect 30 other "heritage assets".
While changes to user's experience of software products is rarely as substantial or irreversible as this, the same concept applies: even improvements have a cost. And that cost is, very often, to your current users.
The Staircase of Competence
I was introduced to this concept a few years ago by Jared Spool, and it's a powerful one. Based on the idea that people move through four stages of competence as they master something, it then considers what happens when changes occur.
Imagine that someone is at the top level of competence - unconscious competence. That is, they can do the task quickly and effectively without conscious thought. Users, especially those in the enterprise, can often reach this state for some of their tasks - tasks they do repetitively or have done for a long period of time. They know keystrokes, the location of icons, the order of screens, and so on. They're on the top step.
What happens when you change their experience? You knock them down a step - or two. Perhaps they have to start thinking about how to use the software now, but they can still get by. Or, worse, they can't figure out how to do something that they knew like the back of their hand. When this happens, those users are likely to be fairly unhappy. It's easy to find examples of this in the consumer space - see pretty much any substantial change to Facebook.
Maximising the benefit & minimizing the cost
Despite the risk though, we must keep making progress. Just as the High Court weighed up whether the benefit of better train services in the future was worth the cost of damaging a global heritage asset, everyone who makes a change to a user's experience should consider whether the benefit of that change outweighs the cost. And, how to minimize that cost.
There are several ways to approach this, but all of them involve understanding your users. Work with them to understand how they work today; test the changes you're going to make with them, and see what difficulties they have and how you can fix them; communicate with them to prepare them for change and the reasons for it.
It may be that the change you think is an improvement isn't worth the cost: that even though it seems on paper that it should make your software, process, or website better, it reduces your user's competence too much. Or it might be that it is worth it, but by thinking about your users you can reduce the impact and maximize the benefit.
