Designing for change, keeping customers uncomfortable

In this cloud-based world, product designers hold a lot of power. In one extreme, an app could be redesigned in major ways frequently. In the other extreme, an app’s interface could stay exactly the same for its entire life.

The degree to which you keep your customers uncomfortable is a choice, whether you’ve made the choice intentionally or not. If you’re building or running a software product, figure out where you want to be on this spectrum. Then figure out how you can best take your customers along for the ride.

The following is my take on the pros and cons of frequent vs. infrequent change and how to best serve your customers based on your chosen strategy.

Designing for frequent change

If you decide to go balls-to-the-wall with change and make it a part of your company’s DNA, you’re likely targeting early adopters. And if you’re in the right market, you can probably find enough early adopters to make your efforts worthwhile.

Web-based software is particularly good for this strategy: you can push major changes out to customers, and they’ll pick them up instantly the next time they log in.

Communication is key

The best strategy for frequent, aggressive change is effective communication.

I’ve noticed that Heroku is particularly good at this with their Changelog (which is also available in tweet and RSS forms). Heroku has been around long enough where they’ve not only added features to their platform, but they’ve also sunsetted old features and changed the way things work. The Changelog is a great way for them to keep the channels of communication open with customers who are depending on them.

Notice that I said effective communication earlier. You need to do it well, not only do a lot of it. Quality before quantity.

The tradeoffs of frequent change

Depending on your situation, it can be hard to keep customers on-board when you’re constantly changing things on them. Once you reach a larger market (even if it’s just a large percentage of your niche), you’ll likely have customers that dislike major change and want more comfort.

Or perhaps your product isn’t a part of your customers’ daily lives, so their seeing a different product for each of their infrequent logins can be quite disorienting.

Lastly, change is risky in software. If you’re consistently introducing change, you’re going to have bugs in your software.

(But if you’re always changing, you’ll fix those bugs along the way anyway. See what I did there?)

Designing for infrequent change

If you decide to introduce change slowly, there is value in that as well. No matter what type of customer you have (early adopter vs. the masses), it can be quite comfortable to not have to deal with much change. _If it ain’t broke, don’t fix it. _And perhaps this is true for your product.

That said, you still need a strategy for introducing some change to your customers. One of the best strategies is giving your customers the option to change on their own terms with versions.

Versions: giving customers the option to upgrade on their own terms

The traditional model of software is to release major versions and have customers pay for the upgrade. This was essential before software had the Internet as a distribution channel. Under this model, customers can choose when they want to change (and choose if the investment in the change is worthwhile for them).

I’ve also seen web-based services offer this upgrade path, but for free. For example, if you’re a long-running Basecamp customer, you can choose to stay on their Basecamp Classic platform without upgrading to the newer platform. (You can sign up for a new Basecamp Classic account too if that’s your cup of tea.)

Lastly, this is a common practice with services that offer APIs. If you want to make major breaking changes to your API, you need to give customers an upgrade path and plenty of time to make the transition to the new version of the API.

Making small steps toward big change

Another strategy to keep your customers comfortable is to introduce changes gradually. Gradually morph your service into the change that you desire.

An example of this has stuck with me for over a decade, and it comes from a story by Jared Spool about eBay:

One day, the folks at eBay decided they no longer liked the bright yellow background on many of their pages, so they just changed it to a white background. Instantly, they started receiving emails from customers, bemoaning the change. So many people complained, that they felt forced to change it back.

Not content with the initial defeat, the team tried a different strategy. Over the period of several months, they modified the background color one shade of yellow at a time, until, finally, all the yellow was gone, leaving only white. Predictably, hardly a single user noticed this time.

Of course, how you employ this strategy depends on what kind of change you’re making to your service.

The tradeoffs of infrequent change

As I’ve illustrated, when you introduce change, you may end up with customers hurling pitchforks and waving flaming torches at you. If your customers are resistant to change, be prepared for meaningful change to be a battle, even if it’s ultimately good change.

Another downfall: perhaps a new competitor will come on the market and bam!, you’re left behind, watching everyone move on to the New Thing™. You’re MySpace, watching your customers switch to Facebook.

Lastly, if your strategy is to release new major versions of your software and to have customers transition over to the new version on their own time, be prepared for many of them to choose to stay right where they are. You may very well end up needing to maintain both the old and new versions of your software as a result, which can get time-consuming and expensive.

In conclusion: make the choice

Constantly introducing change to your customers isn’t for everyone, yet it may be required for others. Or you may decrease your market potential if you’re too aggressive one way or the other.

Remember that ultimately it’s your choice to make, and you can plan for providing what your customers need after you decide.

Image credits: Rabbit and turtle by Samuel Fine.