Making Changes: Be Assertive, Be Attentive

Changes in UI are made in order to introduce a new or improved service, fix problems in the existing interface or keep up with developments in design and technology. In some cases changes are born out of a new manager’s (capricious) desire to make his or her mark on the organization, but we won’t get into that here.

Naturally each new or altered interface comes with a learning curve and it’s impossible to avoid user response and enquiry entirely. When someone moves the cheese in your fridge to a more logical location, your automatic response is to scream that your cheese has been moved rather than go look for it in its new, improved place. As Amir Dotan pointed out in his analysis of Nana10’s failure to change its UI, “Users may be loud, critical, cynical and angry, but they’re still the only customers we’ve got.”

The first thing to consider is the amount of customer enquiries that all changes (even good ones) are bound to generate. Keeping the learning curve as short as possible will minimize these enquiries.

Nowadays there are plenty of inexpensive apps that provide easy user assistance. When a customer visits a changed page they’ll be offered a guided interactive tour which will explain the changes. The user will then be able to close or reopen this tour application at will.

It’s also possible to produce a short video explaining how to perform specific actions in the new interface. Not every action requires a video – focus on the most common ones. Additionally you can offer an online chat service, an expense that will still be cheaper than dealing with a flood of customer enquiries.

So far, so good. The problem starts when a few choice complaints (usually made by the CEO’s relatives) make it to the marketing or service director’s office and cause them to lose their nerve. The director will demand another change in the interface and the rushed job will likely lead to total chaos.

There’s more than one way to build a good user interface, but if your changes are well planned and bug-free (I refuse to acknowledge beta versions) and if you’ve carefully prepared for their launch, there’s no reason why you should succumb to these hysterical whims. Be assertive and back it up with methodology and data.

Relenting to these requests will invite other people, usually the kind who rarely use their own company’s website, to constantly interfere with your work. Then your job as a UI architect will become a completely technical one and lose all professional meaning. Even worse, the website or app is bound to suffer.

If your scientific explanations fall on deaf ears, if your requests for patience until customer enquiries die down only antagonize, if your data on good response from focus groups remains ignored – it may be time to look for a new client.

Nevertheless, you should still be attentive. Monitor the amount and type of enquiries as well as your traffic. User enquiries and complaints will help you identify oversights or confusing wording.

Member of