Is "consumability" another useless buzzword?

"Consumability" is a term that appears to have been coined within IBM. I'm not sure who coined it or when it first appeared, but I started hearing it thrown around about 5 years ago. At first I groaned and thought, "Oh, great, that all we need... yet another term for user experience." Whoever coined it must have been an executive because it didn't die (grin) and I started hearing it more and more within IBM.

I've since come around and started to really appreciate the utility of talking about "consumability". But what is it? Is it different than user experience?

Carl Kessler, an IBMer who writes the outside-in-thinking blog and wrote Outside-In Software Development (which I reviewed here), has the best definition of consumability that I've seen:
"Your stakeholders primarily want to perform the tasks with your software that directly relate to their business goals. But when they use your software, they'll have to also address some additional tasks that aren't in their direct path toward accomplishing those business goals... We call these meta-tasks... We refer to this impact of meta-tasks as consumability; the more the meta-tasks distract from your product's business value, the less consumable it is."

In other words, consumability is the measure of all the crap you have to go through outside of using the product to directly accomplish your goals.

Is user experience a subset of consumability or is consumability a subset of user experience? Well, the problem I've always had with "user experience" is that it's so ridiculously broad that anything could be claimed to fall under the user experience umbrella. In practice, I think there's a lot of overlap between the two, with a few things that are only in one space and not the other. For example, lowering the price of your product will increase its consumability, but doesn't have an impact on user experience (other than 7th order effects). Likewise, improving the usability of your core business value doesn't increase consumability, because consumability is what you do before you get to the business value.

But there are two reasons I like the consumability term. First, consumability has a very different impact on your product depending on your industry/context/market. For example, consumability is not a big deal anymore for MP3 players. When they first went on the market, consumability mattered more because consumers weren't sure how to get music onto them - or even get music on their computer. Nowadays consumability for MP3 players is little more than identifying the "on" button (which in some cases, like the iPod, is harder than you'd think). On the other hand, in the area of enterprise middleware (my area), consumability is enormously important. Enterprise customers are trying to manage installation and fix levels across huge numbers of servers and development machines. When things get out of synch, bad stuff happens. But they don't buy middleware products because they want to manage installations - that's just something they have to do to reach the business value. As hardware costs shrink and people costs rise, consumability is more often becoming a critical business driver.

The other reason its a useful term is that there's a natural, understandable tendency for teams to want to focus on adding direct business value to their products. During release planning, a common and obvious question is "What's the business value for this feature?" Well, what if your goal is to dramatically improve installation? Obviously the product could be installed previously and (as just stated) customers are not buying your product because they want to install it. So the business value of simplifying install is, um, well... not there. When you simplify install and the new product releases, you don't get to put a bullet down for something new that the customer can do. Sometimes this can be a hard sell, which results in products that are constantly adding new features but over time it gets harder and harder for customers to actually get value from the new features because they have trouble getting to them.

Talking about consumability changes the conversation. Improving consumability means less staffing is required for things that aren't adding business value, it means faster time to value, and it lowers the skills required to get things up and running... and maintain it afterwards. These are things that both planning teams and customers can get their head around. User experience isn't focused enough to make the same points.

I'm not sure whether "consumability" will make any headway outside of IBM, but I think there's a place for it.