Natural vs. digital

We’ve all been there before. We open up an app we use on a daily basis to complete a simple task. We just want to hear a certain song, check a feed or pay a bill.

But wait, this looks different 😬

All of the options are in a new place and hidden behind new icons. The things we’ve saved are in a new home with a new name. The colors have changed or things that used to be mellow are now bouncing around the screen. And we weren’t expecting anything out of the ordinary before tapping that familiar rounded tile.

Overnight, change was shipped and now we need to learn something new without warning. All the popups and tooltips only add to the anxiety in this new landscape.

The physical world doesn’t operate this way. Flowering trees put on buds, slowly open flowers, drop pedals and grow leaves. Plants and animals start small and grow slowly over a period of time. Delicious food sizzles and smokes on the grill. Nothing is instantly changed, and all of our senses prepare us for what’s coming. But in the digital world, our brain has to adapt to change in an instant. Should we accept that expectation?

Change curve

Change can be slow and largely unnoticed, or it can be quick and often cause anxiety. It can pass without consequence, or it can cause deep grief. Everyone navigates change at a different rate along a common curve, widely known as the change curve, originally created by psychologist Kübler Ross.

Ross’ work looked at navigating the loss of loved ones, but it has been applied to navigating change at work and in daily life as well. Depending on personality and the type of change, navigation can happen quickly or take a lifetime. Or it might never be complete. Our acceptance of change follows a consistent process across the board.

When we look to implement deep change in a digital product or customer experience, we need to be mindful of the unintended emotional impacts.

Deep change in a digital experience is often the right end result, even if change can be difficult to navigate. Climbing 800 feet during a 2-mile hike can be exhausting, but the views are always worth it. The question is, how can we guide our customers to the viewpoint we know they’ll love?

A huge aspect of releasing change is communication. The team shipping the change obviously sees the value. That’s why we’re spending many sprints researching, executing and delivering it up to the user. But in order for change to be accepted and celebrated, it needs to be seen as a gain to the user as well. Here’s a fantastic way to put it from Sofia Quintero (article link):

“Change is not about what you want to achieve, but what other people think they will achieve if they embrace change.”

Incremental change vs. feature frenzy

The slow process of incremental change moving upwards from a baseline is a practice of shipping change in a staggered approach. Change is dished out one portion at a time. But if each incremental change adds something new, the experience will quickly become bloated. Features will creep and creep. Incremental changes should also include things like IA changes, simplification, content updates and bug fixes.

If you’re reading this post, you might notice Medium recently simplified it’s reading experience on large breakpoints to remove further reading and author bios that were on the right and left sides of the page. Their incremental change reduced the bells and whistles to create a more focus on the article at hand which pleased authors and readers alike.

Incremental change simply means small change over time to create the best experience for customers. It might mean more, it might mean less. It always means better.

Some examples…

After years of missteps and successes, I’ve learned firsthand about how to put new tools into customers’ hands in the most positive way possible. Here are a couple examples and what I’ve picked up.

Product redesign

A few years back, I was part of a project to redesign a core experience of a product. I’ll keep things nice and vague for obvious reasons. This experience was a very important tool for our customers and the health of our business, so we spent many sprints interviewing customers, iterating, validating concepts, prototyping and testing everything in triplicate to make sure we created and shipped the best experience possible. We tested across all demographics with current and prospective customers. We did design thinking sprints and studied the industry in detail. Sounds like a recipe for success, right? We thought so at least.

But once the redesigned experience was launched, our previously mediocre customer satisfaction scores dropped to startling lows. It turned out, regardless of how well the new experience worked or how the new visual design language modernized things, customers hated the change. The product was a utility and the goal of the customer was to think as little as possible about getting the job done. All the prototyping and testing in the world couldn’t tap in to the way change in a routine action would impact users in the real world.

If we would have rolled out change one piece at a time, we could have measured more specifically to pinpoint any problems in what we created. Releasing everything in one bundle made it nearly impossible to determine which pieces of the new experience were causing the most pain for our users. Releasing incrementally also gives teams better data to understand perception and address problems head-on.

To the credit of the team, there were strategic decisions out of our hands and system constraints that made it nearly impossible to change incrementally. In order to improve, we needed to clean the slate to some extent. But I still highlight this example to show the negative impacts change can have in and of itself. If I were able to go back, I would explore more options to bring the experience to the new industry standard over a few releases instead of over night.

Design system progress

Zoom forward to the time of writing this, and my work has shifted quite a bit. Instead of working on end user experiences, my team creates the design system used by product teams across U.S. Bank to create all of our digital experiences. And we face the same exact problems. As we release change and advance our tools for designers and developers, we need to be mindful of the amount of change we introduce to the employee experience. It can be the difference between causing anxiety and inspiring excitement.

Releasing tools for internal consuming teams also needs to take into account change outside of components and artifacts. To the designer and developer, all of the organization’s change is connected. If a team experiences size-able changes in policies or tools and we also ship a global breaking change in the design system, the change management demand placed on teams can become overwhelming. We need to be sensitive to the landscape of change teams are experiencing and plan the right amount of system change to create a more positive environment for adoption. During chaotic times, good communication is a must. Even on the best days, a little hand-holding and teaching can go a long way.

Just my perspective

Thanks for reading! All of this (and everything I could ever write) is just my perspective. It’s all based on the teams I’ve been a part of and the projects we’ve shipped. If you disagree or have your own examples to add, I’d love to learn!

p.s. I’d like to give a special shout out to Shane Kibble for encouraging me to write this out. Cheers! 🍻