Change is hard. When it comes to making a change in your product or launching a new version entirely, you might spend months analyzing and preparing for this update. You know what you’re doing is in the best interest of your users, but they haven’t been thinking about this change for months as you have. 

How do you give your users a seamless change experience? Answer: the very thing you’re changing—your product itself. 

You may have many customer-facing teams – customer success, support, services, etc.—but your product is the most consistent, scalable customer interface you’ll ever have. The value of taking the time to show users what they need—in the exact moment they need it—can not be underestimated. 

Let’s explore a hypothetical scenario to see how communication about product changes can make or break a user’s experience.

Consider the following: 

• I use your product every day for work. It’s a fine product, but I’m busy and don’t pay much attention to blogs, newsletters, release notes, etc. I have a specific way I use your product that’s efficient for me. I’m about to join a meeting, and I quickly log into your product to check something before I hop on the call. But wait—the option I’m used to suddenly isn’t there.

Experience 1: 

• I hunt around for a minute, but I’m about to be late, so I quickly give up. Flustered, I jumped on my call, commenting on how “such and such product wasn’t working, so sorry I’m late.”

Experience 2: 

• I panic for a split second, but then a little tooltip appears in the product menu that reads, “Hi Patrick, your ____ option has moved. This should make your experience just a little bit more efficient in the future.” The tooltip points out a new icon I hadn’t noticed before. I click it, and sure enough, I find exactly what I needed. I join my call with the information and go on with my day. 

Naturally, in-app engagements can be used for big, splashy announcements; but using engagements to manage the product update experience for your users can be just as impactful. Since in-app engagements exist within your product, they can be targeted at the precise time and place when your user needs help most. 

Here are some use cases where this principle is relevant:

• You’ve made some updates to your UI. You’ve already made a PX dialog announcement to unveil the new design. How do you reduce friction for users getting used to the new design? 
• Users have to use your application for work daily. For those users, you may care more about user efficiency than user retention, and you need to inform them of changes without getting in their way. 
• You have a new version of your product, and you have users migrating over from the legacy version. You need a way to re-orient them to the features they’ve previously used in the legacy version. Making that experience engaging and positive will help motivate them to migrate—ultimately reducing the time/cost required to maintain both products. 

1. Manage change with engagements

Build a lightweight experience to onboard users to product/UI changes

Try using non-invasive engagements to help users get up to speed quickly. 

1-2 step Guide Triggered by Badge

This allows the user to opt-in to that tooltip and learn about the change. You may want to use this for less critical changes. Even though this change may be minor, the user’s attention will be drawn to the UI element you are highlighting. 

1-2 step Guides

For more critical changes, you may want to have a 1-2 step guide informing the user of the move—with or without the overlay depending on your preference.

PX on PX

In our PX product, we recently changed where users can submit issues and feedback in-app. Many users were accustomed to the previous workflow, so we created a quick 1-step tooltip to point out the change. A few best practices modeled here:

• Quick, to-the-point copy
• An overlay over the rest of the product to make sure the user sees this critical change

2. Manage change with analytics

Measure the impact on user efficiency

Your product and engineering teams will likely be interested in whether a workflow change has impacted user efficiency. 

Funnel Report

With a PX Funnel report, you can map out key steps in a workflow and see the dropoff rate from each step. Not only that, but you can also measure:

• The average time between steps
• Total time spent on a workflow

Capturing this data allows you to :

• Measure current user efficiency on workflows and
• Measure the impact of product changes on user efficiency

3. Manage change with surveys

Measure user sentiment

Great, so you can measure user efficiency – but do users like the change? Do they feel more efficient? It’s essential to have both qualitative and quantitative data when measuring the impact of product changes.  

CES Survey

By using a Customer Effort Score (CES) survey, you can measure the user’s perception of how easy they think it was to accomplish their task along with qualitative comments. 

Here are a few ways you can implement a CES survey:

• Have a significant change coming up for a particular workflow? Create a CES survey to get a baseline of how your users currently perceive the feature’s required effort. 
• Once the change is released, send out a CES survey after the release. You can make sure this is targeted only to users who have used it since release (that’s the power of PX!). 
• Compare the results of the first survey to the second. Did your engineering efforts move the needle on your CES results? Make sure to socialize any trends. 

A few best practices to keep in mind for surveys:

• Make your question short and easy to understand
• Use a banner with the overlay disabled, so the survey is not in the user’s way
• Give the user multiple opportunities to respond 
• Trigger the survey right after the user has completed the action you’re measuring
  

Advanced Strategy: Put it all together with A/B beta testers

If you’re ready to uplevel your product change experience, you could go so far as to implement an A/B beta test program with the strategies above. 

• Identify version A and version B of your planned product change. 
• Identify a randomized or targeted group of end-users to test the change. You could also allow users to opt into the beta experience. Split into groups A and B. 
• Engagements: launch an engagement pointing out the change to only users in the two beta groups
• Funnel: Create three funnels for group A, group B, and non-beta users. Compare the results. Which group is the most efficient? Is there any impact on completing the workflow?
• Survey: Create a CES survey for group A, group B, and non-beta users. What is the impact of the change on user perception? 

Having the results of such an experiment will allow you to iterate and make informed decisions about rolling out product changes. 

The best part of all these strategies is that you can easily communicate with your users at scale about product changes and measure results. It helps your users get oriented to changes more quickly, but it also frees up your customer-facing teams to focus on bigger-picture initiatives like massive feature releases and achieving outcomes. 

Change is hard, as evidenced by the difficult past months for most. Product changes can be made more accessible by leveraging your product’s scalability to create a seamless experience.