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
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:
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!”
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.”
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.
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.
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.
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
No comments:
Post a Comment