How can you change a poor design without alienating experienced users?

Question

I work for a company that produces a large, 13-year-old web application. Lately, I've taken on the task of trying to get some kind of User Experience guidelines going for the system - something that hasn't really been worried about here before (Pretty much everyone here is a backend developer, no one has ever really worried about UX beyond "is it somehow possible to do what the user wants to do?").

One problem I've identified is our use of buttons, and it's giving me some trouble.

As we know from various design principles, having a whole bunch of options for a user that all look the same, but do different things, is bad. Cool.

Here's what part of our system currently looks like (Button names substituted, obviously):

^{download bmml source – Wireframes created with Balsamiq Mockups}

This is just one, fairly minor example (we've got much worse) of a pervasive problem across our system.

I should note at this point that our system is mainly used by highly inexperienced computer users, who will not necessarily be familiar with common UI conventions. However, it forms the core of our users' day to day job, and they therefore become very familiar with the particular part of it that they use.

What changes can I recommend to our approach to using buttons that:

1. Would make pages such as the one above much more clear in their purpose.
2. Would allow much quicker use of the system with less effort.
3. Doesn't alienate the highly experienced users of our system who - while very knowledgable about the way our system currently works, are not fast to learn "new" systems, or adapt to change in our product, at all.

For bonus marks: in the general case, how does one alter bad design (that is understood and used fairly efficiently by experienced users simply due to their massive amounts of repetition of a task) without alienating experienced users in favour of inexperienced ones?

Answer 1

Whilst not a design feature I suggest once you get some mock ups you contact some key clients and have some meeting with them to help you get the right design for them.

Once this is done put a flag on the current system telling clients a new version is coming and when. This means there is not a sudden shock of a new site.

If the actual database and interaction is not changing ideally you would do a 'soft rollout' to those users who you worked closest with to design it and you know will accept some teething problems of 'early adopters' because you can test to your hearts content but there will always be something!

Answer 2

Applying (or creating) "User Experience Guidelines" to an existing system is a great idea. However, from your post, it's not clear what problem you're trying to solve.

Are you going through this exercise because you've been asked to? Or because it's your job to review UX company-wide and this is the next area for review? Or are you doing it because there is some perceived or actual issue with the system you mention?

If everyone's been using this system quite happily for 13 years; if it enables them to do their job in an efficient and effective manner then maybe you're trying to fix something that isn't actually broken. I've heard of a case study whereby an airline upgraded their ageing check-in software, only to find that the new system was slower to use by maybe 15 or 30 seconds per customer. When processing a large queue of people at the check-in desk, this added up to many, many minutes. They reverted back to the old system (temporarily, at least). I've looked, but unfortunately I can't find a reference for this.

If, on the other hand, the experienced users complain that the system is awkward and slow; if they often end up clicking on the wrong buttons by mistake; if it takes new users ages to get up to speed; if users have to complete tasks in an order that seems back-to-front to them (etc. etc.) then you have a problem that you can work on.

If there's a problem, see if you can gather some more information (subjective and objective). Can you speak to (or, even better, just spend some time watching) the existing users? That can often be very enlightening. If you ask people about how they use software, they'll tell you what they think they do, which is often different to what they actually do. Can you spend some time with a new user who's learning / recently had to learn the system? Any problems they encountered will probably be fresher in their memory. As people get used to a system, they easily forget the things that they found so hard to start with. If new users are frequently joining then it may be more important to design for learnability. If this doesn't happen very often, then it may be less important.

Are you able to get any objective data (e.g. average time to perform a certain task; number of errors made due to people clicking the wrong button by mistake; time or cost involved in correcting any such errors etc.)? This will give you a baseline to work from. As @indofraiser suggests, sharing mock-ups with key individuals could be a good starting point, but the real measure is whether any of your data metrics improve once the new design is implemented. If the new design enables users to complete the same task in 30% less time and / or the error rate goes down then you'll know the improvement has worked, and by how much. This kind of information is really useful when reporting back to your seniors about the monetary (and other intangible) benefits to the organisation of your UX changes.

I guess this reply is less about the specific example you posted and more about the general approach that you might want to take. However, I've based this on the fact that the UI in your original post was only one example of many areas of the system that didn't fit in with best practice guidelines.

Also, as others have said, users are often better able to adapt to several incremental changes than one big change. This also means that you can start releasing the changes sooner and (hopefully) reaping the benefits quicker.

I wish you the best of luck!

Answer 3

I recommend grouping.

^{download bmml source – Wireframes created with Balsamiq Mockups}

There are still lots of buttons - so the functional requirements are maintained. But for a given task (which you'll group buttons for) there are less buttons.

So if previously the user chose one of fifteen buttons, they would now choose one action, and then one of five buttons. (so nine less options, in this example).

This way you avoid radically changing the UI. Which for legacy users, could be.. radical.

Answer 4

I'm not sure if this is helpful as I am new to UX, but have ten years of experience dealing with users and communities. It sounds like you and your colleagues really want to change these buttons, and from the standpoint of attracting new users, it would probably be a great idea. Why don't you reach out to the most experienced users beforehand to show them a safe version of the plan to roll out so that they have knowledge ahead of time and feel like they are part of the process? They may even be able to help new users learn the system, and you get a free focus group. Good luck.

Answer 5

The key is incremental improvement. Unfortunately you have 13 years of that not happening. It's akin to trying to slightly improve a Motorola StarTac in the age of iPhone 5s.

It's a daunting task and one that I fear has you set up to fail.

That's not to say you can't do incremental improvements. But if the current UI is that old, that not-thought-out, yet so ingrained in your users, you may need to treat this like a band-aid instead. Rip if off all at once instead of slow tugs.

Answer 6

Users don't want to feel dumb.

When confronted with change, experienced users suddenly become novice users. You need to combat the feelings of uncertainty they will experience.

A crystal clear user experience, clearly better than the old one, helps, but is not sufficient. A lot of other things around the experience are necessary: options for users to safely explore; advance warning of the change; support during the transition period. For complex workflows, it may be helpful to write a "the new way to do things" guide showing before and after.

If the new system really is functionally better, then users will migrate on their own; if it is only better in the usability dimension, they may not, because the perceived benefits don't outweigh the learning costs (even if the are measurably faster, happier, or accurate, users may not perceive those benefits). You'll have more of an uphill battle if it's "just" a refresh. This is why we try to roll out usability improvements with a little sugar, e.g. a new useful feature.

And sometimes you just have to grit your teeth and tough out the 2-3 weeks of transition pain. In any case, it is very likely a vocal minority will HATE it--and that's okay, as long as they're a vanishingly small minority. Manage expectations with your team about this ahead of time--after demonstrating that the new interface is provably better than the old, prepare them for the fact that users may not realize this right away.

Answer 7

It's hard to give an informed opinion based solely on a mockup. Do you have any user data on usage of buttons. That could help inform you on which buttons need to be shown. Other buttons could be added to an overflow type menu. You could also use coach marks to help instruct users when you've made changes if there is a high level of worry about them being able to learn it on their own. Grouping is also a good idea to help in understanding.

A bigger question is why are you trying to change the buttons if your users understand them. Is it causing pain for new users or does the company just think they look bad?

At Amazon we had a button stack on the right of some detail pages that we affectionately called the Buyscraper because it was a bunch of rent and buy buttons that all looked fairly similar. From a design perspective it was ugly, but repeated testing showed up that users preferred having all of the buttons visible. Creating the best user experience is not always inline with creating the slickest design.

Answer 8

Build and implement your ideas on existing functions.

Is there any little more complex function you and your users are happy with? Some sort of UI element the users like to use and are familiar with? Lets say tabs are something completely awesome for some users. Try to take that element and enhance it. Nest tabs. Show an indicator or counter on tabs. Make them colorful. Maybe group them. But don't change the logical function of the tabs since the users have the hang of that and don't want to get lost. After the time you can start implementing tabs in other areas for other use case. Then take the next element and so on.

Is there any function or UI element you could use where users don't make much damage to the system? You could take that and enhance it also, but more quickly. I remember Apple introducing that vertical slide on the iOS6 lockscreen. First it was there only to start the camera. After users got used to it, Apple implemented that element for users to cancel calls and auto-text callers. So the UI element was used for a more critical function.

Answer 9

I'd suggest "Options" / "Actions" labeled dropdown - while it doesn't necessary make actions faster (two clicks instead of one), I'd say that grouping all the actions in one place and further extensibility outweights the problem.

Answer 10

Facebook's approach could be interesting in your case. In the past, the social network used to make some rather "crude" updates. They passed from a version to another overnight. People was disapointed, they had to learn how to use it again.

But, as you probably realized, the new version is added gradually. Some users already use it but for the others we see some elements changing from time to time. Message feature updated, then sharing tools, etc.

It could be a great option to update gradually. Doing so it's easier for your users to notice the changes without any difficulties.

Answer 11

Something small but substantial I've learned through my time working is that you should roll-out changes gradually with users like this, and if it's possible, to inform the user prior to the change - it's lots of changes in one go that will alienate current long-time users. Test your soft changes with a smaller team of people and watch how they first react and analyze for what they're doing.

Answer 12

If you have tons of buttons, that probably means you just have tons of various actions that can be executed against whatever page/module/widget you are on.

In that situation, I think it helps to condense actions into a simple drop down and submit button. You select what action you want to execute and click submit.

Something like:

^{download bmml source – Wireframes created with Balsamiq Mockups}