Should I avoid changing a "clunky" UI?

Question

This seems like a broad question, so I'll outline my specific example.

I support an old Windows program. And I mean OLD. It originated as a 1997 rewrite of ever older software. It's a kind of diagnostics and monitoring software for a network of devices. In one central part of the app, these devices are organized in a tree. It's essentially an MFC Single-Document Interface wherein users select a "document" (a device) from their current network. This works well, and users are used to this interface.

However, there is one small annoyance that has existed for some time in this interface. To open a context menu on an item in this tree, that item must first be selected by left-clicking it, before right-clicking it. I've recently corrected it by making it so that, on a right-click, the tree control will assume you want to select the object you right-clicked on, then it will bring up the context menu for it, and so forth.

• Optimistically, this corrects the old annoyance, and users greet the change with an "Oh, isn't that nice. I don't have to left-click before right-clicking anymore!"
• Pessimistically, this introduces a new annoyance--the key word being new. They were used to the old way, and this change makes them adjust again. "Arrgh," the user says, "it used to be I could right-click anywhere, now I have to make sure I'm pointing at the right thing!"

This wouldn't be a concern if this was done right from the beginning. But even if it's wrong now, is it better to correct a clunky UI or avoid painful changes?

Answer 1

I think whether or not you should change this particular behaviour depends on two things:

1. The severity of the impact on users
2. The turnover of users

If the current behaviour has a negative impact that is severe enough to cause mistakes, loss of data or wasted time, it is certainly worth making a change if it would solve those issues. It would force experienced users to adapt their way of working which may cause some initial frustrations, but the benefits are clear in the long term.

Also, if the turnover of users is reasonably high (new people start using the product frequently and other people stop using the product) it may be worth making the change now and causing some initial frustration for experienced users for the benefit of new users moving forward.

If however the user group were known to be small and stable (the same group of people has been using the product for years and there are rarely new users) there is probably little value in forcing those users to learn a new way of working, even if it is less clunky.

Answer 2

People don't like change because they fear loss of control over what they're used to know. We are creatures of habit but you always find the bold ones who will love and fight for the new feature, even within the existing user base.

These are the ones - let's call them fans - who will help increasing the acceptance of the changed functionality. See the 'stubborn' users as a true opportunity: if you listen, understand and communicate to them the right way, the 'converted' ones will be your comrades-in-arms. Also for future changes when they know you do everything to the benefit of the users.

This may seem obvious to you, but don't underestimate communication: If you communicate the change by declaring the actual value of it, your users will still feel competent since they will discover the advantage of winning time in the long-term.

Back to the core question:

"Is it better to correct a clunky UI or avoid painful changes?"

No, it is in no way better, not even for the users. Else you re-iterate what is simply wrong. Sometimes you have to decide for the user by swimming against the flow for the greater good, for the sake of simplicity, for the sake of making software better. Just make sure the change isn't too painful - as mentioned above through appropriate communication, winning fans and making sure that even in the face of a temporary efficiency drop in some cases, it's all in the best interest for the user: The next generation will thank you for that.

Answer 3

I understand your concerns about introducing new functionality even if that will be a clear improvement. The benefits of the new functionality should far exceed the inconvenience of changing an old habit.

In your case though I believe that the old habit will change quickly for the following two reasons :

• The right-click select it is today a standard functionality, and probably your users are already using it at home or at other office software, so they have to shift between the two ways of using the context menu.
• The new functionality is more intuitive than the old one. You right-click on the item you want the context menu to be activated.

Answer 4

Either way can be fine.

With however one caveat: if there is not enough dead space in a typical document so you'd have to hunt for dead space then the original behavior is preferable. This is particularly true when the context menu is the only way to do certain needed actions (and as such is used often).

Answer 5

you've answered your own question when you said the interface is clunky

you must ask yourself which scenario, once learned is the better user experience and unquestionably that is your solution.

UX is not just about learnability

Answer 6

You should pick the way that is intuitive to a new user of the system, so probably your unclunky version. Point out to compainers that this how standard software like M$ or Apple something does it too, show it to them.

If there really are complainers afterwards, offer them to use either the old version or make it a setting to switch between the two.

And I mean a real setting, one that is bound to the user account, that follows him on every machine. If you force them to activate it each time they start the program, they will kill you. :)