📹 New! Remote User Testing - Get video + voice feedback on designs and prototypes
Read more
Viewpoint

How to Launch Software Changes Without Pissing People Off

Go the extra mile to avoid interruptions and protect your customers’ time.
How to Launch Software Changes Without Pissing People Off

Software designers and developers are all about NEW. We like to experiment with far-out ideas and make shiny things. Our livelihood depends on it.

We’re so addicted to NEW that sometimes it clouds our judgment. We love NEW and everyone else should too, so we force heavy-handed product changes onto our customers without much explanation.

And if they didn’t want that? Or if they got needlessly interrupted by it?…Shhh…we’re not so interested in those problems.

Dislike Facebook’s redesign? Deal with it! Confused by the newest Windows updates? Oh well! Missing some features in the new Final Cut? Too bad, they’re gone forever!

It’s no surprise that these sorts of changes are comically unpopular:

Cineworld have changed their app and I feel hurt and betrayed x

— alex ✨ (@FuellAlex) February 20, 2017

ANDROID CHANGED THEIR UI AND I DONT LIKE IT I DONT LIKE IT

— ????disappointment???? (@dammitjiim) February 27, 2017

Developers get away with this anyway because we wield all the power. We can push a button and instantly transform an experience for millions of people in one shot.

Imagine if that kind of thing happened in the real world. Let’s say this was your living room:

And one day it suddenly became like this:

You wouldn’t be cool with that at all. You’d be totally freaked out!

What!? Where are all my books? What is all this creepy stuff? Whose head is that? Are those antlers?

That’s exactly what we do to our customers all the time. No wonder they’re always ranting on Twitter.

Why do we make disruptive changes?

There are a few reasons developers decide to steamroll NEW stuff.

Notice a theme there? It’s hard for us. Our laziness or time constraints take over, so we pass the buck.

How we can do better

Not all changes are massively disruptive, so we just need a strategy for identifying the ones that are, and then handle them properly.

Here’s how we do it at Basecamp.

Make only additive updates and improvements.

Taking away a feature is a surefire way to upset your customers. Even if it’s something small or innocuous, you can guarantee someone depended heavily on that one thing you took away.

@SpotifyUK absolutely heartbroken my Spotify inbox has been removed, one of the best features that set Spotify from the rest...

— Tas (@aniakans) March 1, 2017

"Taking away a feature is a surefire way to upset your customers."

The solution? Don’t take things away (if you can possibly avoid it.)

Thoughtfully adding stuff is great. Who wouldn’t want more for their money?

It’s also fine to improve rough spots. Make the same features look better, work better, or get the job done faster. Nobody’s going to be bothered by that.

The don’t-remove-stuff philosophy has a strategic upside, too. If you can’t take anything away, you’ll be more conscientious about what you put in.

Take extra care when making a disruptive change.

Sometimes you have a big idea that makes your product better, but switching over will be bumpy for your existing users. In that case it’s worth the additional effort to smooth things out, even if it means extending your development budget to build transition-related features.

We did this last year when we launched some big changes in Basecamp 3. We spent a few extra weeks making a settings screen for the new features we were introducing, so we wouldn’t be shoving them down our customers’ throats. The new stuff was turned off by default, so people could opt in if they wanted to, rather than having to opt out of something they didn’t want.

Basecamp’s new HQ and Teams features defaulted to OFF for existing customers.

Basecamp’s new HQ and Teams features defaulted to OFF for existing customers.

Whatever extra time you spend doing this is a drop in the bucket compared to the exponentially greater time your customers might have wasted out of confusion or frustration.

Don’t bother pre-announcing changes.

You might think it’d be helpful to warn everyone before a big launch, like…

In three weeks, this website will be totally unrecognizable. You’ll have to figure everything out from scratch, but we think the new one is nicer. Enjoy!

…but what good does that do? Maybe the advance notice dulls the shock, but the customer can’t act on this information. They have to wait to be interrupted again later by the actual change.

This only prolongs the anxiety, with very little upside. It’s better to focus energy on the transition instead—make it so smooth that there’s no need for a pre-announcement.

Explain what’s different.

It’s bad enough to be forced into an update you didn’t agree to, but it’s even worse if you have no idea what happened or why things changed.

"Make sure you have a way to introduce and explain what’s new when you launch"

Make sure you have a way to introduce and explain what’s new when you launch, either via in-app announcements, a mailing list, a blog, or whatever method you have to communicate with customers.

People may not like the changes, but at least they won’t be blindsided. It’s the courteous thing to do.

Basecamp’s iOS app tells you whenever there’s new stuff.

Basecamp’s iOS app tells you whenever there’s new stuff.

Split distinct major versions and keep them around forever.

When we’ve collected enough new ideas to constitute a major rethink of Basecamp (this usually takes years), we create a whole new version from scratch. The previous versions live on in perpetuity in maintenance mode.

That means even there’s no disruption for people who are happily using a previous version. We incur the maintenance time and costs to keep it all running, and they keep paying us like they always did.

This might not work for some products, but it’s worked wonderfully for ours. Our customers get to keep using the version they like for as long as they want, with no pressure to do anything else. They can migrate to the newer version on their own timeline. Or not.

Perhaps best of all, we’re free to make a sweet NEW Basecamp every few years, with no legacy constraints holding us back. We can take risks and make big leaps forward.

You’ll be glad you did

Working through these issues might not be the most fun and exciting part of your job, but it makes a big difference in how people perceive your product, your service, and your company as a whole.

A few people will always complain about any change you make. That’s life. But these approaches will help keep your support load lower and your customers happier.

This article was originally published on Jonas's Medium page

Design and prototyping for everyone

Design and prototyping for everyone

Thousands of individuals and teams use Marvel to design and prototype ideas.

Get Started, it's Free!

Product Designer at Basecamp. Also made Hello Weather. Follow me on Twitter.

Related Posts

Making good component design decisions in react when it’s hard to see how an existing component can still be reused

Disney’s 12 Principles of Animation is one of the inestimable guides when traditional animations are considered. It was put forth by Ollie Johnston and Frank Thomas in their book – The Illusion of Life. These principles were originally designed for traditional animations like character animations. However, these principles can still be applied in designing interface animations. So, this is just… Read More →

Design is no longer subjective. Data rules our world now. We’re told all design decisions must be validated by user feedback or business success metrics. Analytics are measuring the design effectiveness of every tweak and change we make. If it can’t be proven to work in a prototype, A/B test, or MVP, it’s not worth trying at all. In this… Read More →

Categories