User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
How do you go about convincing the stubborn "powers that be" to let you change a clumsy layout that users are used to?
Say there was a layout in a previous version of software from years back and the powers that be at your company do not want to change it at all just because it has been that way, but in reality is not even following a best practice or convention, and actually is rather clumsy.
A very common problem for professionals in our field. I usually try to convince the powers by showing various famous sites how the web convention looks today, in order to get anything done. You turn the discussion in a different direction from "I don't want to change" to "Cool, I want that on my site as well".
I get the best response if I show the other famous webs first, and when the powers are convinced, I show my solution. There's no guarantee for this technique to work all the time, but the odds increase.
In my experience there is only one thing that works: Get data that proves that your solution is better (if it really is...).
If there are no studies on the exact subject (there usually aren't) you'll have to test it.
I once worked on a project where we had to replace some old (20+ years!) custom-made DOS software, with a hard requirement that we had to keep the old interface, since each employee who worked with the software knew all the keyboard shortcuts by heart (function keys F1 to F10, with different meanings in different parts of the program). The main reason they needed a software upgrade was that they were having more and more difficulties in finding DOS computers.
We decided not to argue too much about the requirements. Instead, we silently changed the row of function labels and some other interface elements into buttons, ran a quick test with one of the experienced employees who had worked with the application on a daily basis for more than 10 years and invited management to come and observe. They were quite surprised, I'd even say a bit shocked, when they saw with their own eyes that our test subject didn't use the function keys at all, but used the mouse the whole time. This totally changed their attitude towards interface changes.
Sometimes it can work really well if you start with a single babystep (but that of course won't be possible for every project).
Often, showing is better than telling.
Try to find out the users' pain points by gathering data (hat tip to Phil), so you can address them accordingly. Then build a mockup or demo UI that addresses those pain points and test it with some actual users. You can even do this with paper prototypes.
Bundle all this together for a convincing proposal for management.
Can you find the real reason that your stakeholders are resistant to change?
They say they don't want people to learn the new interface--that might be true. But why?
Are they worried they will drive users away? If so, can you disprove that assertion: e.g. demonstrate that novice users are driven away by the current interface? Or demonstrate that even experienced users can pick up the new interface?
Did one of the stakeholders design the current interface, and has some cognitive dissonance when faced with a better design? In that case you might try a tactic like explaining that styles (or user expectations) have changed over time.
Are they concerned that development time is better spent on other changes? Then you should figure out a way to identify if they might be right! Maybe the interface is clunky and it doesn't matter.
You cannot change their minds without understanding what they are concerned about. "We don't want to change it" is only half the story. Your job becomes identifying the other half, and that requires detective work.
My answer is case specific.
From my experience, if they like their interface, and especially if someone who works in that company has designed it, you must not attack it no matter how bad it is. Once when you make enemy of someone who works there, you will have a lot of trouble to pass anything you bring in, no matter how good it is. They work there, and can "feed" stakeholders with their view.
When possible, it is necessary to present changes one at a time, AS improvements of existing design, which are result of advance in technologies/browsers etc. Only when you do couple of things well and they like it, you will get them to trust you and you will be able to introduce some bigger changes. Complete overhaul of UI is most efficient and fastest/cheapest, but is also probably too big of a risk. When you approach through iterations, you can "soften" decision makers gradually.
You must also think of their position, they don't want to be responsible for anything that is not good in new design, and when there is complete change they will probably dismiss it because they cannot test and be sure everything is better. It is safer for them to dismiss it and keep their position. But if they accept some small change (and their acceptance is not final in that phase), they will probably want see how that one change reflects to work process/user experience. However, this approach has major drawback - if you introduce changes one by one, that means that you can work without specification, and without real "target" - what is final product of your work. It is important to make that specification at start (no matter if it is only for you) so you don't loose composition if some "small" change requests arise. Also, if some of stakeholders is "designer", you could be in trouble, as they could suggest "next" change to UI (after you present current) which may not be what you planned to do, and you need to check if it fits in your spec before answering.
We all know that changes are hard to be accepted; especially for users that technology is just a commodity for them. For those users, @Phill answer is the most recommended approach. However, sometimes we don’t have data or resources to do a proper UX study. In that case, you need to be a good sales person. A few things that can help you when presenting a proposal to them are:
