Change Management of the Product Experience, Part 2

Another associated model of the IFPI framework is the UX Development Lifecycle Chart (UXDLC) shown in Figure 2. This diagram demonstrates the user experience’s long-term cycles and microcycles.

This diagram helps us better understand that the user experience is cyclical. Microcycles of thought and memory intertwine, reminding us that the human mind is complex. All too often, we forget that we’re designing and building products for human beings. What might not be readily apparent, but stood out for me when reading the whitepaper is that we can achieve an effective long-term user experience by managing the anticipatory, momentary, and episodic user experiences. These factors have the biggest impact on the cumulative and reflective user experiences.

According to the whitepaper: “Sustaining a lasting long-term user experience requires the celebration of short-term user experience achievements, making the user experience stick and allowing continuous improvement of the user experience. User experience development consists of anticipatory user experience, momentary user experience, episodic user experience, and long-term user experience. Long-term user experience is a result of the accumulation of the overall user experience over time. It is therefore important to sustain long-term user experience….”

Companies whose goal is to have loyal users for their software products should aim to develop products with appealing, long-term user experiences. Customers’ continuously having positive reflections on your software products is vital to building a lasting user experience.

The IFIP has outlined a few change management principles in support of their research and their UX framework.

• Prepare for change. This takes forethought and planning around the change, the way you’ll implement the change, and how you’ll communicate the change to customers.
• Focus implementation on guiding customer adoption. Guide your customers and help them adopt the change. Make sure that there is awareness of the change so customers clearly know what it is. Foster customers’ desire for the change by establishing a need with which customers can connect. Provide concise knowledge so customers know how to use new features or functions. Plus, you should design them to maximize their usability and demonstrate users’ ability to easily use them.
• Sustain change management. Help customers to manage their behaviors and emotions.

Do not overlook the need to regularly monitor and evaluate changes and work toward continuous improvement. Without awareness, many users would regress, in preference of a poorer, but familiar legacy experience. I have heard this regression story too many times from customers who prefer to stay with a legacy experience, even though a software company wants to move toward the future. Based on my experience, I agree with Dr. Florian Deißenböck of CQSE Consulting, who in his study “Continuous Quality Control of Long-Lived Software Systems” noted: “Users don’t hate change; just bad change.”

Breaking Down Change

In another great article, “Change Aversion and the Conflicted User,” Roxanne Abercrombie outlines some useful categories for the types of changes software teams make, as follows:

• corrective changes—These changes correct bugs and flaws and generally constitute regular updates. These are usually good changes that users welcome.
• adaptive changes—These are infrastructure, platform, and operating system (OS) improvements. These changes generally have low impact. If the product just works or works better, the user might not even notice such changes.
• preventive changes—These are changes whose goal is to future-proof the product. They are generally changes teams make in preparation for future improvements. These changes should be low impact, unless a change disrupts the user’s workflows or tasks.
• perfect changes—These are the most tangible user-interface changes. These could be updates, extensions, or deprecations of features. These are apparent changes that would most likely trigger customer annoyance, unless they were very well designed.

I have begun to use these categories during stakeholder conversations to help us determine the impacts of recommended changes.

In addition to becoming aware of these different types of changes, we also need to understand why customers have such an aversion to change in the first place. In my experience with poorly managed legacy software, the following are common challenges:

• resource drains—These are the consequence of users’ heavy investment of time in learning and using the existing software. Customers don’t want to invest in additional learning or retraining if they can avoid it.
• experience rot—This happens when changes break or bury functionality or interfere with customers’ tasks and goals.
• productivity plunges—The loss of familiar features can cast customers into confusion.
• legacy love—This is bred by familiarity with and exposure to the legacy software. A lack of experience with the new software can cause customers to regress to using the legacy experience.

How can you manage change in the midst of all these challenges? Abercrombie provides a great overall approach. Some tips from Jared Spool’s article “Users Don’t Hate Change. They Hate Our Design Choices”—for which he had studied many software rollouts with hundreds of users—correlate with her approach. When implementing change, do the following:

• Makes small changes often. Never force too much change on customers too quickly. Rapid change could cause digital whiplash and backfire on you. Reduce your changes to the smallest unit of change possible.
• Create a product roadmap. Map out what is changing and why, and define clear goals for each design iteration.
• Communicate changes in advance. Constantly communicate with your customers. Never dump unexpected changes on customers. You must respect customers’ existing investment in your product, so show users how the changes would benefit them.
• Be flexible between versions. Allow your customers to play in the design sandbox with you by engaging in collaborative, participatory design before committing to changes. If possible, give users control over when changes would affect them.
• Listen to customers’ feedback. Actively seek out the voice of the customer (VoC). Customers’ feedback can tell you what is happening with the software.
• Always keep testing. Continuously work to improve your product—as long as it receives any negative feedback. Testing can get to the heart of why something needs improvement.

The Personal-Space Conundrum

As I mentioned in Part 1, I experimented with the knick-knack conundrum to discover the tipping point in my wife’s comfort with change. I shared that story with a coworker, who found it interesting and wanted to try it. After a couple of weeks went by, she said, “I want to kill you.” She told me that she had tried the experiment on her husband, and he had gotten mad at her.

Naturally, I had to ask what she had done. I wanted to learn exactly how she had conducted the experiment. She proceeded to tell me that her husband keeps the TV remotes, his reading materials, and a few other things right next to his chair. She moved these items “just a few feet away,” which was enough to trigger a very strong negative reaction. First, she moved everything at once rather than making small, incremental changes. Second, she moved all the items too far away. Given the context, her husband’s expectation would be that they would be within easy reach, which they no longer were.

If I assess her experiment based on the principles I outlined earlier, I don’t think she applied any of them. Naturally, the participant—her unwitting husband—experienced legacy love and experience rot, so was eager to regress to the familiar experience.

Learning from the Past

I once worked on a massive, very complex project whose goal was unifying more than 216 small applications into one large, cohesive platform. The project had multiple user personas for various roles, in different departments within the company. One of many challenges was the fact that each role in each department had developed specific training from their perspective. Our attempt to unify the user experience became a big tug of war between department heads, users, project managers, and architects.

We were working to unify everything into a single platform, but these teams kept pulling things apart into the custom components they wanted. “We want this! We want that!” When we did usability testing to show users’ positive outcomes when performing their tasks, the people on the various teams still focused on how the new system was different from their old applications and told us how they wanted it to work. They wanted an à la carte solution, with more than 216 custom applications. I came onto that project a year and a half after it began. Looking back, I realize that the groundwork to establish stakeholder expectations had not been done before I came on board. That would have made a big difference. This project was focused on technology, but change management was a huge hurdle the team needed to overcome.

Another company I worked for was in a race to get some legacy software onto AWS (Amazon Web Services). The mad rush to get over the technical hump in a short timeframe created massive amounts of change for customers. In the rush, customers lost parity features, the navigation models changed, and the release was seemingly one big dump. Needless to say, customers were neither happy about the changes, nor the scope or timing. What was left in the wake of this mad rush was tons of technical debt and a major hit on their Net Promoter Score (NPS)—on which the impacts of that change are still reverberating. The company then became concerned about backlash from almost any kind of change. One big burn can paralyze even the most reasonable decision-making around change management.

At one point or another, every company I’ve worked for has been concerned about their customers’ reactions to the changes in a release. Every release carries some risk—some more than others. Bolt-on features carry a little less risk than clean-up or perfection changes. The toughest changes occur when we need to streamline or course-correct the existing experience to prepare for future improvements. But companies cannot bolt on change forever. Over time, their product would eventually become a Frankenstein of cobbled-together bits and pieces, held together with duct tape and paper clips. Customers would eventually see through any veneer and, at that point, the changes necessary to course-correct could be an expensive, risky proposition.

Conclusion

I have learned quite a few things on my journey to improve the software change–management process. I didn’t need to reinvent the wheel. I just needed to dig into what was already available. I was delighted to find a mix of software architecture, user experience, and cognitive psychology converging in change management. However, I don’t think the principles I’ve mentioned are equally suitable for all companies. Some companies are more mature than others. Different companies develop different products that serve different user bases. Each company must determine what works best for them and their customers.

UX professionals should consider their organization’s strategies for change and work with their business partners to discover what works best for them. Our platforms should be extensible and nimble and leave room for growth and market shifts. The toughest part is that we need to keep our customers happy as we move forward on our continuous-improvement journey.

This reminds me that the UX sweet spot is the convergence of customers’ needs, the needs of the business, and the technical feasibility that is necessary to accomplish our goals. If there is an imbalance in our decision making, we risk getting stuck, which inhibits our growth. Remember Amy Bucher’s comment, “Your success may depend on your ability to change behavior.”