Update Frequency and the Maximum Pain Formula

A recent emailer asked, “From a usability standpoint, what’s the optimum frequency for pushing program updates?” It’s a great question–I only wish I could give you a great answer to it!

When considering how often to push upgrades (including patches) to your users, there’s clearly a balance to be struck between doing them too-frequently (yes, we’re looking at you, Adobe Reader!) and so infrequently that you give the impression that you’ve abandoned the product.

Most users like to see progress in a product’s development, but even the least intrusive updates tend to involve some level of annoyance and interruption of the user’s flow. The worst, however  (Hiya, Windows Update!) routinely restart your machine, or even crash your servers, sending your support techs scurrying from their slumbers to troubleshoot in the middle of the night, muttering things not suited for sensitive ears.

The Maximum Pain Formula for Customer Acceptance

Upgrades, like all else in interface design, seem bound by the Pleasure/Maximum Pain™ equation. To wit:

Customer Acceptance = (Personal expected gain) – The greater of (Personal expected pain,  Personal actual pain).


A = Gexpected – Max(Pexpected, Pactual)

When A is a number greater than zero, there’s a good chance that the user will upgrade [or use your product]. Below zero, and the user won’t.

There are a couple of important things to note about this deceptively simple formula, however.

Rule 1: The measurements of pleasure and pain are individual to the person making the decision.

My twelve-year-old son adores mathematical simulation programs, whereas I love killing legions of the undead in violent video games. That’s why this weekend will likely see me sprawled on the couch playing Left for Dead 2, and him installing a Linux partition so that he can finally mess around with some new open source math sims he’s read about. And both of us will quietly think the other one mad for wasting  a perfectly good weekend this way.

More seriously, I’ve seen many a groupware product fail precisely because the central authority foisting the elaborate new expense tracking  or project accounting system on the employees was to  derive a great deal of benefit from the new system, but the staffers who had to slog through it saw only extra work for themselves. As a result, the staffers tended to “opt out” by neglecting to use the new system, or even passively working to sabotage it.

Rule 2:  Results count, but expected results count more.

When you decide whether to do something or not, you’re really measuring the expected gain against the expected pain, and if the expected pain is greater, you’d be crazy to even start. Once you’re involved in the process, however, you begin weighing the pain you’re actually feeling against the gain you hope to accrue by the end. If the actual pain starts to outweigh the expected gain, you’ll likely abandon the task as being pointless.

And as a corollary, it doesn’t matter if your upgrade is easy, if the user doesn’t think it’ll be easy. Upgrading your product might be as simple as changing a lightbulb, but if any of your users are inclined to think of it as a task only slightly less difficult than recalculating entry orbits on the space shuttle, they’re probably not going to even try.

Pushing the Upgrade Odds in Your Favor

Every time you push an upgrade, you force your users to consider whether the Pleasure/Maximum Pain formula makes sense for them. If the updates are minor and non-annoying, and if they routinely provide visible benefits to the user, they’re likely to be installed by habit. If the update is smooth and unobtrusive enough, you may even be able to get the user’s permission to always update automatically, particularly if that can be accomplished without getting in the user’s way. Firefox does probably as good a job of this part of the equation as I’ve seen, using background downloads and installing after the user is done using the program for the most part.

Where Firefox (and almost everyone else, to be fair) fails is in emphasizing the advantages of the update and by telling the user what they’re going to get for their trouble. The trick, of course, is in couching things in specific, but non-threatening language which lets the user know that the update is going to make their life better in some measurable way. Ideally, this would be accompanied by a link to information on any new features or bug fixes to fill the user in on the specifics.

Interestingly, the Sales department may be better positioned to answer the question of how much is too much or too little when it comes to updates. By gathering data on the sales and usage stats of the various versions of your program, you can start building your own curve to show what percentage of the customer base will jump on–and which will avoid–anygiven update. And if you feel the number avoiding the update is unacceptably high, it’s up to you to change the numbers in the equation, either by upping the perceived gain, or decreasing the pain or upgrading, both real and imagined.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s