Should you concede to user demands that seem clearly inferior?

Question

Currently working on a ground-up (not just the UI) reimplementation of a whole, existing system. Because it's internal we've been able to work with its existing users during the process, and get their feedback on what they want doing.

One of their existing UI elements involves nested data. Currently, they have to take the following steps:

• Type text into a textbox to narrow the selection in a drop down.
• Chose one of the results from the drop-down box, which populates a treeview.
• Browse and expand the treeview, and select a branch.

The list in the drop down is not long enough to justify the text filtering (about 75 items). However, under each of these items there can be a very large number of items and sub-items in the treeview.

We replaced this with a single treeview which has the 75 items at the top level, each one expanding down. This seems very easy to use, to us: as each level expands you can, if necessary, just scroll down the list with the mouse wheel and find what you need.

But the users hated it. They wanted to go back to the old way. When we watched them using the new system it seemed quite clear that the biggest problem is simply that they weren't used to using scroll wheels, so the left-right swipes required as each level was expended and then the scroll bar grabbed and dragged were slowing them down.

We pointed out how useful the scroll wheel was, but they're not used to scrolling, and don't want to start.

To my mind, the way we redeveloped it is unambiguously better. But the user base was equally emphatic in rejecting it. So today, to the complaints of my fellow team members, I removed our new implementation and set it to work in the manner the users were used to.

What was the right course of action here? Is there a point at which the user's fear of change becomes an important UX consideration in its own right?

Answer 1

What was the right course of action here? Is there a point at which the user's fear of change becomes an important UX consideration in its own right?

This is an interesting question - I believe the answer is yes. The core tenet of user centered design is considering the characteristics and needs of your users in your design. If the fear of change so outweighs the benefit of that change, maybe that change isn't worth making.

However, making changes like the one you described happen all the time, as part of a redesign, and I think you can mitigate the user's fear of change by incorporating some steps into your design/engineering process. My favorite set of practices comes from a blog post titled "Change aversion: why users hate what you launched (and what to do about it)" by Aaron Sedly, a UX researcher at Google:

1. Warn users about major changes. Unexpected changes catch people off-guard and can provoke a defensive response. A simple message can set users’ expectations, for example: “Soon we’ll be introducing a redesigned site with new features to improve your experience. Stay tuned!”

2. Clearly communicate the nature and value of the changes. An explicit description can help users to appreciate the changes from your perspective. For example: “We’ve redesigned our site. It’s now cleaner to save you time. Here’s how it’ll help you…”. With framing like that, users will be less prone to change aversion, such as: “Ugh, it looks totally different. I don’t know why they did this, and I wish they hadn’t messed with it.”

3. Let users toggle between old and new versions. Giving users control over the timing of the change can cut down on feelings of helplessness. Allow them to play in the new sandbox before removing the old one.

4. Provide transition instructions and support. If a city changes its street layout, residents need a map of the new streets and a way to direct lost people to their destinations. The same principle applies for your product’s alterations.

5. Offer users a dedicated feedback channel. Without a way to connect with those responsible for the changes, users will vent publicly and further entrench their negativity. Users will respect you more if you actively solicit their opinions.

6. Tell users how you’re addressing key issues they’ve raised. This completes the feedback loop and assures users that their feedback is critical to prioritizing improvements. Try a simple message like: “We’ve been listening to your feedback about the changes we’ve made. Based on your comments, here’s what we’re doing…”

Update: I just was perusing the papers for CHI '13 and noticed that Aaron Sedly and and Hendrik Müller have published a paper on minimizing change aversion ("Minimizing Change Aversion for the Google Drive Launch" {1}). They measured user satisfaction with the new Google Drive on an extended Likert scale. I found this observation interesting:

Early psychologist William James wrote about the power of habit, as if it were a giant flywheel keeping people in their respective social classes. The same effect applies to people's use of products, which generates substantial inertia over time. Any forced changes to well-established habits are prone to cause disruption, and significant effort to regain inertia.

The mere exposure effect, identified by Zajonc, showed that familiarity breeds liking. With technology, familiar designs and interactions have a natural advantage over new approaches, at least until a new version is used enough to reap the benefits of familiarity.

The authors go on to note that they "developed a framework of actions to minimize change aversion", which included the steps I originally mentioned from the blog post.

Update 2: I came across an interesting paper in the IUI '14 proceedings that was citing the aforementioned Sedley and Müller paper on change aversion: "On user behaviour adaptation under interface change" by Rosman et al. This study is looking at how users learn and adapt to new user interfaces and it considers when the users are already used to an existing interface. They found that a change to a user interface can degrade user performance even when the change might be considered to result in a "better" interface. This study highlights the importance of having a good change management strategy when you make large changes to your software.

1: Aaron Sedley and Hendrik Müller. 2013. Minimizing change aversion for the google drive launch. In CHI '13 Extended Abstracts on Human Factors in Computing Systems (CHI EA '13). ACM, New York, NY, USA, 2351-2354. DOI=10.1145/2468356.2468767 http://doi.acm.org/10.1145/2468356.2468767

2: Benjamin Rosman, Subramanian Ramamoorthy, M.M. Hassan Mahmud, and Pushmeet Kohli. 2014. On user behaviour adaptation under interface change. In Proceedings of the 19th international conference on Intelligent User Interfaces (IUI '14). ACM, New York, NY, USA, 273-278. DOI=10.1145/2557500.2557535 http://doi.acm.org/10.1145/2557500.2557535

Answer 2

Normally the users have a point. It may not be the point they think, but that does not mean there is not a valid issue at the heart of it.

The choice of (a) "old way" or (b) "our correct new way" is rather stark. I have re-factored a lot of UI's and occasionally missed a much loved short-cut. I always found a way of blending the better design for learners while keeping the short cut.

Why did you become convinced the new solution was better? 75 items is a fairly big cognitive load. The mental model "Give me the stuff called 'car'" and "Read 75 items looking for text 'car'" is quite disparate, which is why I can understand a particularly strong user feedback.

To summarise an answer: If you get strong negative feedback then there is something(s) that as a UI designer you need to take on board.

Answer 3

To my mind, the way we redeveloped it is unambiguously better.

That's great, but "Better" does not always equal "Best". You may have thought you had "Best" before you received user feedback. However, the feedback you received should have thrown up red flags in your mind.

What was the right course of action here?

First, be willing to re-evaluate your initial assumptions with an unbiased mind. For example, you and your users seem to disagree about this assumption in particular:

The list in the drop down is not long enough to justify the text filtering (about 75 items).

Second, you must be willing to consider new designs based on the changed assumptions. In your post, it was just "old vs. new", not "back to the drawing board". Do not be focus on "Better", focus on "Best"!

---

Here's how the thought process might have gone when applying those principles:

Designer: We came up with a "better" design, how do you like it?
Users: We hate it! We want the old way back!
Designer: Can you clarify what you mean? Why do you want the old way back?
Users: No, we just know we hate it and we like the old way! Give it back to us!
Designer (to self): Hmmm, what's different about the new way versus the old way? The only advantage of the old way is that there was a search, so you didn't have to look through 75 items.
Designer: Ok users, do you want the search functionality back?
Users: Yes!
Designer (to self): Ok self, looks like our our assumption about 75 items not needing a filter is what's causing this hatred. What can we do to fix it? Well, we could add a filter to the top that filters the root items as the user types. Since it's already 75 lines long, it won't take up much vertical real-estate, but searchers will get their searchy functionality, and scrollers can just ignore it...that seems reasonable.
Designer: Ok users, we are going to launch our new design, try it out below:

Unfiltered:

Filtered:

Designer: How do you like the new design?
Users: We hate it!
Designer: Can you clarify what you mean? Why do you want the old way back?
Users: Now there's a box at the top. What does that do? And I thought you were going to give us our search functionality back!
Designer: Doh! That text box IS your search box. I'll add a label to it.

...and so on...

Answer 4

This is the however

If the majority of users have rejected a design, it seems ludicrous for any UX professional to insist on that design because 'they know better what's good for the users'. Quite appropriately, the majority of the replies to your question follow that thinking.

I would, however, like to offer an alternative take on this, which goes well deep into the very essence of what we do.

Rejecting change is a survival skill (the status quo bias)

You can argue that the fundamental principle behind any human behaviour, and the root rationale behind nearly all man-made things, is the wish to find order in chaos.

To do so, we must identify patterns. Life could not have existed without such ability - a baby exposed to a different language every day would learn any language. If your girlfriend's face and general appearance would change every day, you would find it rather impossible to keep her as your girlfriend - after all, you wouldn't be able to recognise her most of the time (and while having sex with a stranger might sound fun, most people eventually opt for the stability, or order, relationships offer).

The problem with changes is that they break patterns, which must trigger some cognitive 'discomfort'. Once's you have learnt something, you don't want it to be taken away and forced to learn something again.

This is a key challenge in UX - although changes are often for the better, experienced users often dislike them (even if the benefit is clear sometimes).

So rejecting changes is a survival skill (if you want) and a completely natural one.

It happens that the older we get, the more firm our understandings become and thus the more we reject change. This partly explains why young people are much more welcoming new technologies than older ones.

The Apple PCIe story

Somewhere around 2007 (if I'm not mistaken) Apple came to give a talk at then my school, which specialises in audio and film production. They could not have picked a worse time - 3 month earlier, Apple have announced the discontinuation of PCI based Macs in favour of the (then unheard of) PCIe interface.

For the school this meant an estimated 5 digit cost over 2 years, and ditto for pretty much the whole of the professional audio and film industry (which were relaying on a particular, highly popular PCI DSP hardware).

Needless the say, a lot of grief, disappointment, and even anger were thrown at the Apple representatives during this talk. But their answer was a winning one. It went along these lines:

At Apple, our aim is to craft the future of technology and provide our customers with cutting edge hardware and software. If Apple were to focus on dated, under-performing technologies, it would never have existed today.

Rejecting change is rejecting progress

There is much more to the embracement of change than what may first meets the eyes.

Mankind would have never achieved what it has without change - No change, no progress.

Novel innovations, by virtue, explore unfamiliar territories. Many scientific breakthroughs were the result of popular patterns being challenged.

To give just two lame examples, both when stereo sound and colour television (the ancestor of the screen you are looking at right now) were invented, people were seriously doubting the usefulness and value of these innovations - in the case of stereo, it took 24 years before the invention became a commercial product.

My point is that while totally understood from a user point of view, one should also understand the consequences of allowing change aversion to prevail.

Be brave, triangulate

You should really question what side you are on, and what is your true role and purpose in this field.

If your users have disliked the change, you have one evidence against it. But if a triangulation with a other empirical research methods would prove otherwise, you have strong case to overrule the users.

I wouldn't rely on your own expert opinion, but perhaps use some predictive evaluation techniques, or user testing with those unfamiliar with the system.

Anyhow, I don't think the answer is as clear cut as otherwise seem by most other replies.

Answer 5

Before ignoring the wishes of your users, you must first validate that your new solution is indeed better. The way to do this is to get a number of fresh, non-involved users of the system and test the existing and proposed options with them.

When the uninitiated users prefer your new method, you have validated your approach, eliminated assumption and you can comfortably blame your previous user resistance on ‘fear of change’.

I worry about your dependency on scroll-wheel use. It may be obvious and regularly used by computer power-users but lot of less computer savvy people don’t use them or just aren’t used to them. But by conducting the test with users unfamiliar with the system you’ll get an answer either way.

Answer 6

I'll take a different tack from some of the others on this.

If users hate it then chances are it made their job harder instead of easier. Drawing an arbitrary line in the sand and saying that 75 items isn't worth doing text filtering seems silly as well. Real users interact constantly with the system you are building, where you only interact with it on occasion so don't try to force your preferences on them.

Scrolling isn't inherently better than typing for navigating a tree view quickly, so the right answer would be to provide them an alternative form of control that still works with the new presentation. That way users who want to type can still type, and users who want to click and scroll can do that.

A perfect example that comes to mind in navigating directory trees.. Many modern shells include auto completion that makes text entry very efficient for navigation. And if the auto completion is ambiguous it can still narrow the field and present the alternatives. Open up windows explorer, click in the navigation bar and start typing if you want another example.

If you setup things so they could use any combination of clicking and typing to filter all the down to the leaves then they would probably have been perfectly happy.

Answer 7

Joshua Barron's on the right track with his leading answer. I do see some additions to make, but I'm not cool enough yet to add comments.

Let's stick with the simple assumption that the new UI is better than the old one. That way, we're just talking about the Developers who are Right, and the Users who are Wrong.

The key problem then is how do you convince or educate the Users so they won't be Wrong anymore?

It's sort of a marketing problem.

The solution should not be developed in isolation. That was likely the first mistake. A sample set of the users or project sponsor (aka Not the Dev Team) needed to be in on the plotting and plannning of the idea to make this UI change, long before the change got coded.

This helps you get the Users (via Project Sponsor or user advocates) to come to the same conclusion the Dev team has. If you sit in a meeting with these people, and outline the problem (ex. the current UI bit is clunky and doesn't handle large lists well). Then you all talk through the possibilities, the Devs will get a sense of how the Users see the problem when they respond to ideas.

Additionally, the Users/Project Sponsor in that room will be educated into the problem and the various possibilities to fixing it. So when you agree on a solution, you have buy-in by some of the users or the Project Sponsor who is in turn responsible to the Users.

These people now become your advocates and can evangelize the reason for the change and the value of how this change is better than alternatives to solving it.

By doing so, you reduce the population set of potential cranky Users long before they see the actual change in production. All you'll have left are the Cranks, which nobody listens to anyway.

Answer 8

Users reaction to change is an interesting topic, look at all the problems major services have when they update - Facebook/Windows 8/etc!

Changes becomes a bigger issue where you have expert or repeat use users. They have invested in the process over time and will have developed a relationship with it. Even if the solution is easier from a pure usability perspective they may not want to invest the time and energy to learn the new approach.

Also remember that over time user behaviour may change and it could just be a knee jerk reaction that you are encountering. If it is then it could be more of a cultural issue than UI. Is there a way to improve the relationship with the users? Involving them more in the design process could lead to them being more on board with future updates?

To summarise - you should certainly base your design decisions on user behaviour, but equally its important to understand the limitations of a one off test. It is not a totally realistic scenario if your users are likely to be repeating the action 100s of times a week.

I imagine there are likely to be new users in the future so they need to be considered as well.

At the end of the day there are a lot of factors to weigh up! - Sorry for me there is no easy answer!

Answer 9

The list in the drop down is not long enough to justify the text filtering (about 75 items).

A very interesting statement. Scrollbars aside, I would test both UI's on yourselves and see how well you perform a searching task with 75 items with or without filters.

Answer 10

There may be other reasons, too. I worked on a system that had a clunky UI, click here, click there, click back here, etc. I asked the systems analyst about it and it turns out there was a very good reason for it.

It was designed that way to force the user to look in both places (it was a comparison tool) and then consciously go somewhere else to accept it. It was critical that it not be possible for the user to simply hover over the 'accept' button and click as each pair came up.

The 'convenient interface' would have made it possible to introduce errors that would invalidate the statistical experiment being done, leading to incorrect results. Not acceptable, so they made the users go a little bit out of the way to answer the question being asked each time.

Answer 11

There is one simple rule: He who pays the bill gets what he wants.

I have seen groups put themselves out of business by doing it there better way. You can do both but don't be surprised if your new way is not used. Lots of good advice in the above comments on how to get the users to see things your way. Dan

Answer 12

People, particularly long-time users of legacy systems, are averse to change - period.

If your paycheck depends on keeping your users happy, you did the right thing.

If your paycheck depends on bringing innovative solutions to your users and educating them to accept them, you did the wrong thing.

Did your manager/supervisor have any input regarding your decision? In many cases, such as my current job, it's their call.

I have users (many of them in important management positions) that have been using the same system for mission critical work for a decade or more. I am constantly challenged to keep my innovations "cloaked" such that the users don't really know much about them!

The first question my manager (who knows our user base very well) thinks about is "How will the veteran users take to this change?". If the answer is "they won't like it at all", then my assignment is to come up with a design that incorporates my innovations in a way that the users will accept without complaints.

Answer 13

If the end users aren't happy with it then the project is a failure.

But as a suggestion perhaps you could consider a hybrid approach which gives the best of both worlds.

i.e. the drop down can filter the tree view as with the old design.
But by default, the whole tree is displayed as with the new design?

Answer 14

Do both.

Based on user, present one control or the other, and allow changing that preference. Default it to the new one, if you wish.

This will allow users to experiment with the new one, whilst preserving backwards compatibility with existing users who don't want to change.