As software products have expanded over the decades, companies have had to apply a fair amount of effort to managing their customers’ experience. Since companies have added more and more features and functions to their software products, customer engagement has begun to fluctuate. Managing customers’ expectations had become complicated. These products have continued to grow because customers desired more features and the software companies wanted to offer more value—for a nominal fee, of course. Now, these companies confront the challenge not only of how to design and build the new features but also how to manage and release them.
Several companies—for example, Google—have managed these changes fairly well, but many have a lot of room for improvement. The days are over when we can honestly say, “If we build it, they will come.” We must do the work necessary to truly understand our customers’ needs. If we understood our customers, we would understand that we can’t just jam new features or functions into our software and expect customers joyfully to accept them.
Champion Advertisement
Continue Reading…
In working with companies small and large over the decades, I can tell you that, while there are some reasonable practices around change management, the way companies manage that change generally burns them at both ends of the spectrum of change. Either they give customers exactly what they want to the detriment of their ability to scale their platform and creating technical debt, or they make changes that suit the company and irritate their customers.
Not too long ago, I was working on a project for which I recommended a small, incremental improvement on the basis of our research findings. That recommendation landed me smack in the middle of a debate about how much change our customers could handle. People were tossing around a lot of opinions. Needless to say, our work halted, and the recommended improvement was quashed.
Honestly, I was annoyed by this situation. But, more importantly, it made me curious. Why were these people saying, “Customers don’t like change”? We’re building and improving software within an agile environment! We make changes all the time! Somehow customers now don’t like change? This set me on a journey to understand what’s going on behind our internal assumptions about change, what research tells us about how customers interpret and handle change, and some good universal principles we should apply.
Having done a few interviews with separate groups of internal stakeholders, I encountered some contradictions among their assumptions. After conducting Web searches using various combinations of Product Change Management in queries, I realized that there isn’t nearly as much good information as I had hoped. Most of the information slanted toward Organizational Change Management. I was trying to find user-centered software change management principles. But I was able to find some helpful resources, weed out what didn’t apply, and compile a good set of principles that I could use in my organization.
The Knick-Knack Conundrum
My synthesis process triggered a memory that made me laugh, but was also quite revealing in understanding the experience of change.
A few years ago, my wife asked me to put up a shelf for her on the wall. She likes knick-knacks, such as those shown in Figure 1, and needed a place for them. Naturally, my function was to make sure all the logistics were in order. I wasn’t going to drill holes in the wall only to have her change her mind. My wife cared more about form, how the shelf would look once it was up.
After putting the shelf on the wall, I noticed the knick-knacks that were near me, so I picked them up and placed them on the shelf in a manner I thought was visually appealing. I told her the shelf was ready, and she could make her adjustments.
A short time later, I returned and noticed that she had moved some of the knick-knacks and rotated some others. This didn’t bother me—it was her shelf—but it got me to thinking: Why had she placed them like that? Then, I thought, How invested is she in her opinions of the knick-knacks’ placement?
After a few days went by, I went up to the shelf and turned just one of the knick-knacks ever so slightly—just a few degrees. Then I waited. A couple of days later, the knick-knack was still in the same position I had last positioned it, so I rotated it a few more degrees and waited again. About the end of the week, I noticed that she had rotated the knick-knack back to its original position. And there it was: I had found the point at which the change was too much for her. That last increment of change stood out enough to engage her attention and prompt her to move the knick-knack back to her visually comfortable position.
Now, I was intrigued! So I began sliding a different knick-knack a few millimeters to the left or right. Then another forward or back. Little by little, I was finding the point at which the change was too much for her.
Some of you may be thinking, How diabolical! But wait for it: one afternoon she came into the room, looked at the shelf, and noticed another knick-knack was slightly out of place. She said to me, “This is so weird! Why do my knick-knacks keep moving around?” At that point, I explained everything that I’d done. However, I had to make sure she understood that I’d done it because I was trying to learn more about her. This may seem like a sappy, lame excuse, but it was better than my telling her she was part of some sick experiment regarding her discomfort with change. Although I might not have learned how to place knick-knacks on a shelf properly, I had learned a lot about change, as well as the point at which my wife became uncomfortable with it.
So imagine that this shelf is your product. The knick-knacks are all the features and functions you’ve put into your product. Knick-knacks—like software features—almost always increase. As the knick-knacks begin to exceed the shelf space, you need to either upgrade your shelf or get another one. However, when it comes to software, we just keep jamming in more features and moving them around on customers.
This is what I like to call the knick-knack conundrum. As your software product grows and you add more features, moving others around, there is only so much change customers can handle over a given period. In many cases, the amount of change can simply be too much for customers—and this change could potentially occur at the worst possible time for them.
Spinning the Users’ Experience
Looking at change from an organizational perspective, stakeholders often get stuck on assumptions. They say things such as, “Customers always hate change.” Or, “Nothing we do will ever make them happy.” Sadly, such assumptions cause people to become more entrenched rather than more curious. We should be striving to be curious—to understand how we can evolve the product and bring customers along on a delightful journey.
Let’s consider a couple of things. Technology advances roughly every six months, and computer processing doubles roughly every 18 months. Why does this matter? If technology changes at that rate, and you’ve been in business for a few years, technology is causing your customers’ expectations to change—regardless of whether you’re ready to accept it. Your customers likely use a variety of different products, and those products are changing their expectations about how your product should work. If your product isn’t changing, they’re adapting all around you, and you’re likely to lose those customers.
Plus, we too often describe a customer’s user experience too linearly. “The user logs in, clicks the Settings button, then clicks the Manage button.” Voila! While customers tasks may seem relatively linear, our research tells us that their experiences are actually cyclical and always evolving.
Cognitive psychology tells us that there are three levels of emotional design: visceral, behavioral, and reflective. Generally speaking, the visceral is the customers’ visual interpretation of what they’re seeing and how they’re interpreting the product before they have even interacted with it. At the behavioral level, customers assess the products affordances from the visceral level and begin to interact with the product’s functions. These interactions, in turn, add more flavor to the customers’ experience. Finally, after customers reflect on the overall experience, they begin to form an opinion about it. It’s often the reflective part that gets your product a good or a bad rating. This is key in understanding how customers would react to the changes you make to your product.
The user experience evolves as you make incremental changes to your product. I’ve worked with a company that had a pretty decent Net Promoter Score (NPS). Over time, however, they made some poor decisions and badly timed some large-scale changes, so they got hit with a flood of negative feedback and a big dip in their NPS. The customers’ negative reflections were so strong that we got negative comments about features we hadn’t even surveyed them about. They just wanted to vent as a result of their negative reflective bias.
Unfortunately, this caused the company to become worried about every little change they released. Facing large-account customers who had a very strong negative reflection from the previous releases probably felt like going before a firing squad.
Where Do We Go from Here?
For many UX designers, change management is either their last thought or they don’t think about it at all. They just want to forge ahead with something new and innovative without factoring in how the changes they’re making would impact the customers’ experience. Particularly in enterprise applications, without careful consideration of the changes, this can lead to their taking serious, unnecessary risks.
While some UX designers have the luxury of using technologies that support feature toggles, or A/B testing, not all designers do. Not every company can rapidly increment change as Google, Apple, and the like can do. Many designers simply need to rely on some good design practices and their soft skills in working collaboratively with stakeholders toward improving the product and managing the customer experience. Plus, designers’ skills and strategies must be practical and flexible to meet the needs of their company.
I am by no means a change-management guru. However, I have witnessed and been a part of too many failures. In my search to expand my knowledge about change management, I have been working to establish good practices and put them into practice. Now, I want to share these practices with you. I believe all UX designers can benefit from these change-management practices. They are based on other people’s research. I have merely identified others’ good change-management practices, boiled them down, and colored them with my own professional experiences.
You Can’t Manage What You Don’t Know
In Part 2 of this two-part series, I’ll discuss how to understand the change process, considering how episodic moments influence the user experience over time. I’ll include my research learnings and some practical examples and tips that can help you manage the customer experience. I’ll map out the shaping of influences from anticipatory and reflective user experiences, using the UX Development Lifecycle Chart (UXDLC).
To give you a better understanding of the different types of change and users’ aversions to change, I’ll offer some principles to mitigate change aversion; lay out some principles for managing change and sustaining the cumulative, long-term experience; and discuss how other companies manage change. Finally, I’ll put everything together and describe how you can apply these principles in strengthening your business partnerships and working toward a more sustainably high-quality user experience.
Lead User Experience Designer at Renaissance Learning
Saint Paul, Minnesota, USA
As a UX design leader, Scott has worked with companies both large and small, over decades, in various domains. He has worked with teams to improve platform design and the overall customer experience. Read More
