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.

  • By showing that people have been doing thing ineffectively because no one has bothered to provide them with an effective solution... or slip it in and if people like it then they will take the credit for it anyway.
    – Michael Lai
    Jul 31, 2014 at 0:04

7 Answers 7


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.

  • Some stupid powers will counter your point with "we don't want to be like them; we want to be better than them by being different!"
    – JoJo
    Sep 4, 2011 at 2:55
  • 1
    Just don't use ebay or amazon as an example, and you should be fine :D
    – Christian
    May 27, 2012 at 14:50

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.

  • 1
    Any ideas for someone with limited resources? The only available test subjects that I have are all engineers or software developers. Also,we have no budget (or perceived need by management) for bringing in outside test subjects. See the issue is we provide products that happen to come with software to customize the products, but the software itself is not very important to anyone other than the few of us who develop it, as long as it works and gets the job done. There is little to no concern on how well it works or if it is a pleasant experience, which is what the software team wants to change May 17, 2011 at 14:37
  • 1
    Tough one. Maybe you can use one of the cheap softwares or services (like www.silverbackapp.com or www.usertesting.com). Or maybe it's enough if you show all the users (the developers in your case) a proposition of the new UI and if they all like it, tell the management that all the people who matter prefer the new UI.
    – Phil
    May 17, 2011 at 15:04
  • If you're serious about it, pay for a couple of UserTesting.com studies out of your own pocket, blow the execs away with your results, and worry about reimbursement later. May 18, 2011 at 14:25
  • get the data and also make sure you produce graphs from it.
    – icc97
    Jul 22, 2011 at 11:25

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.

  • We have done that, but the management says, "That's different than the old version. I don't want to change anything, then they (the users) have to learn the new way." May 17, 2011 at 14:04
  • 1
    I tried that quite often and it almost never works. They'll just say "but I like this one better". They usually think it's just a matter of opinions - they're not professionals on this field - that's why you need data instead of demos.
    – Phil
    May 17, 2011 at 14:05
  • OK, looks like we've got different experiences here ;-) But I will edit my post...
    – Jan
    May 17, 2011 at 14:11
  • Ok, removed -1 :)
    – Phil
    May 17, 2011 at 14:24
  • Cheers, much appreciated :-)
    – Jan
    May 17, 2011 at 14:24

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.

  • Point #1: Yes. They think our software has been hard enough to learn in the past, that since people finally learned the way it works now (the bad way) that they will get frustrated all over again. Management says, "That's different than the old version. I don't want to change anything, then they (the users) have to learn the new way." Point #2: Everyone who designed the previous version is on my software team and agrees it should change. Point #3: No no extra time is needed really. So basically a small group of people are just being a stick in the mud. May 17, 2011 at 19:18

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:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.