Usefulness = f ( utility , usability )

Would you keep using something which is not useful? 

Probably not. Neither will your users ...even if their boss tells them to!

Usefulness is a function of utility and usability

Jakob Nielsen says that utility is equally as important as usability.

"Usability and utility are equally important and together determine whether something is useful" -- Jakob Nielsen

We can decompose usefulness in two dimensions, that of utility and that of usability. For simplicity, let's say that the axis representing utility is that of functional adequacy and the axis representing usability is that of ease of use. Both dimensions have a threshold (let’s keep it arbitrary for now) below which neither utility nor usability are satisfactory for the user.

In other words,  Let's say for the usability axis there is a threshold below which something is defined as hard to use. While for utility there is a threshold above which a product characteristic/feature is needed and below which it is not. 

These concepts give us a map with 4 quadrants.

Waste line

The bottom left quadrant where something is hard to use and is not needed is the quadrant of total waste! The bottom right, where something is easy to use but still not needed is the quadrant of ...'still waste'. 

The line dividing the map between the bottom and top quadrants is the threshold of user needs, which is the most important distinction between useful products and useless ones. To build products that users need we must always be above this waste line. If not, we waste time and money.

At minimum we must make sure we don't build software, products and services that deplete our lives and the planet of resources for no good reason. Building what is waste does exactly that. 

Wasting time and money building what is not needed is not a good way to inhabit this planet nor a rational way to make profitable products. Choose your motives here. Whichever you go for, I bet it points away from waste (unless of course you are in the waste disposal business).

Who has time and money to build what is not needed anyway?

Functional adequacy 

In the top left we find the quadrant of functional adequacy where things are needed by the user but are somehow hard to use.

This is the quadrant where at minimum all product backlogs should find themselves in order to avoid waste. This area can be a good start, whether we are working on incremental features or completely new products.

When involved in new product development the product backlog should be full of items that are needed by the user. When there is functional adequacy, because user needs are addressed, the business can reasonably expect to achieve product-market fit. This is true for both startups and established enterprises alike.

Simply put, at a minimum the products we build should be functionally adequate, meaning they must cover user needs and thus have high utility.

Useful

To reach the top right quadrant of usefulness, functionally adequate products must also be highly usable. This is the quadrant to aim for.

In my experience, retrofitting usability into a hard to use product is possible, whereas retrofitting utility is practically impossible. 

Think about it. If you have a product that users need but is difficult to use, then they are likely to tolerate it until there is a more usable one to replace it, if that new or updated product lets them do what they need. Whereas if a product, irrespective of difficulty of use, can not help users cover their needs, spending money to make it more usable won’t do anything for the users. 

Having said that, a very discerning PO once told me that when you have compounding usability issues (irrespective of how minor they may be) then perceived utility breaks down very rapidly. This is because users will give up (or never get to see the utility we provide). Alas we must be very careful. To avoid future loss or outright failure, it is not a bad idea to aim from the start for the quadrant of usefulness. 

The top left quadrant is about doing the right thing for the user and the top right is about doing the right thing right, for the user.

Useful products and services are those which are both needed and easy to use. 

Law of usefulness

My observation is that given enough time in the marketplace, a product or service which has low utility will lose to one with high utility, while one with high utility but with inadequate usability will eventually lose to a disruptor with much higher usability. A product with low or no utility and no usability will crash and burn very quickly. 

I call this the 'law of usefulness', which at times may seem to unfold at glacial pace, akin to the 'disruptive innovation' by Clayton Christensen.  In my experience, this law of usefulness accelerates as people evolve to have less and less time to waste on this planet.

Moving up the utility axis

We can not usability test our way to higher usefulness. 

If we usability test a product which is not needed and find that  it performs well, so what?

“It matters little that something is easy if it's not what you want.” --Jakob Nielsen

We can not discover what users need just by conducting usability testing. Although there are ways to partly achieve this at times, evaluative research is not enough.

Generative research is what is needed in order to move up the utility axis. Simply because, in order to methodically discover what users need, we must explore! 

Conducting generative user research and product discovery is a complex topic, which I feel is one of the most under-appreciated and less studied topics of UX research and design. 

Why do we forget about utility?

It seems so many times that we talk about usability but we rarely mention utility. Why?

In my view, a great many times we tend to “forget” about utility because we assume that we know who the users and/or customers are and what they need; and then we proceed to ideate and commit to solutions based on assumptions. 

Assumption is the mother of all cock-ups!

I have observed that such “forgetting” happens because too many times we are inclined to value “knowing the answer” more than learning and admitting that we don’t know! We want to be right, rather than precise with reality.

Why so? 

Well, learning involves hard work, being wrong, getting humbled and the pursuit of knowledge. Needed knowledge may not be available to us when we want to create something new or make a decision, in which case we have to conduct research. Conducting research is how we create new knowledge. However new knowledge builds on evidence, which hurts feelings and crushes opinions! When we hold opinions strongly, evidence hurts us the most.

"Research is creating new knowledge" -- Neil Armstrong

Organisations that do not value learning and do not tolerate evidence and failure are the ones that I typically expect to see create useless products and thus waste employee and shareholder time and money.

Another problem which is commonly detrimental to conducting research and thus to building useful products is that of haste, or otherwise known as velocity of delivery.

These topics of velocity and opinion based development deserve their own treatment of course. If you haven’t had the chance to talk about this during one of my talks, here is a quote that summarises the situation better than I could (and you don’t have to sit through my talk on evidence based backlogs):

“There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.” -- Peter F. Drucker.

Usefulness as a weighing machine

Usefulness is the ultimate weighing machine for a product's long term ROI. 

Product owners, managers and UX professionals should be obsessed with usefulness. We cannot fake it, but we can measure and design for it. When we don’t, our product, team and business suffer the consequences; that is waste.

Your mileage will vary. I wrote this article in the hope that getting UXers and product folk thinking about usefulness will prove useful in our journey to build useful products (all puns intended), which users need, can and want to use.

I will attempt to further explore topics related to usefulness in subsequent articles; specifically what is and how we can operationalise usefulness measurement. If I managed to strike a chord with you, please comment or message me.

For now, here is a short video from Jakob, enjoy :-)