The Business Value of Usability

I am not fond of the word “redesign”. Not because I have anything against design changing, but because of how differently we each read it. For a designer it can mean rethinking the information architecture, the user journeys, the interactions and the visual system. For the business it is a chance to finally refresh a product that looks dated. For the user it is one more new interface in which the familiar functions have to be found all over again.

None of those readings is necessarily wrong. The trouble starts when we take the fact of change as improvement in itself. A team works on a new interface for months, presents beautiful screens, shows a before and after. Everything looks more modern, cleaner, more consistent. But did the product get better for the people who use it? Do they finish their tasks faster? Are there fewer errors? Did anything change beyond how it looks?

It seems to me that this is where the interesting conversation about design begins. We can build a very beautiful product without solving a single real problem. Or we can change one small journey and create far more value for users and for the business.

“

A new interface is the output of the work. A better experience is an outcome that still has to be proven.

Are we improving the product, or just changing it?

Imagine a team decides to refresh an internal B2B platform. It has complicated navigation, endless tables, filters and settings. The interface looks overloaded, so the first idea is to make it cleaner: remove the extra elements, hide the secondary actions, simplify the menu and give it more room to breathe.

At first glance that is all sensible. But there is a detail: experienced users are in this system eight hours a day. They know where everything is, they are used to a particular order of operations, and they can work almost without looking. For them the new interface may turn out not simpler but slower. What the team read as visual noise was in fact part of how the work gets done.

So does simplifying an interface always simplify the work? And should a complex professional tool be judged by the same criteria as a consumer mobile app?

I do not think so. A product has to be judged in the context of the tasks it helps people finish. Sometimes the right answer is to change the structure completely. Sometimes it is to improve search, or to cut the number of repeated operations. And sometimes it is to leave a familiar interface almost untouched, because it already works.

That is why I think any significant update should start not with references but with understanding the problem. What exactly does not work today? Who does it hurt? What does it cost? And how will we know our solution actually helped?

Can convenience even be measured?

In design we lean on subjective phrases: the interface is intuitive, the navigation is clear, the experience is seamless. But behind each of those there should be something people actually do.

ISO 9241-11 defines usability through effectiveness, efficiency and satisfaction in a specified context of use. I like that definition because it moves us from abstract judgements to questions that have answers.

Did the person finish the task? How much time and effort did it take? Were they satisfied with the process? And most importantly: does the result match what they actually needed?

Take sign-up. In a modern product with Google or Apple login, authentication itself can take seconds. So measuring only the time to create an account is not very interesting. It is far more useful to understand how quickly a new user goes from opening the product for the first time to the moment it gives them something real.

For a task manager that might be creating the first project. For a financial product, successfully connecting an account. For an AI tool, getting a first result that can actually be used.

That moves us from optimising one screen to measuring a whole journey. Product analytics has a name for it: time to first value.

Which raises an interesting question: what matters more: cutting five seconds off sign-up, or helping the user understand the point of the product much sooner?

Fewer steps is not always less effort

We are used to reading fewer clicks or fewer screens as a sign of good UX. Sometimes it is. But the number of steps on its own does not explain how simple an experience feels.

Back in 2003 Joshua Porter tested the popular three-click rule. Across 620 tasks he found no evidence that the number of clicks determined the likelihood of success. People kept going well past many transitions, as long as they understood where they were and how to get closer to the goal.

The same question comes up when designing checkout. Is one screen with a lot of fields simpler than several short steps? Not necessarily. Baymard Institute’s research suggests that the number of fields and the difficulty of filling them can matter more for usability than the number of steps.

Nielsen Norman Group has a term for this: interaction cost, the total mental and physical effort a user spends to get something done. Unlike counting clicks, it lets you look at the interaction as a whole.

When we remove a few screens but make a person process more at once, we have not necessarily simplified the product. Sometimes we have simply moved the complexity out of the interface and into the user.

“

The point of simplifying is not to minimise the number of elements. The point is to reduce the effort it takes to get a result.

Which metrics actually matter?

It seems to me that the problem with many UX dashboards is not a lack of data but that we do not always know why we are measuring these particular numbers. SUS, CSAT, NPS, conversion rate: all of them can be useful, and none of them is a universal answer to the question of product quality.

I would start from a specific problem and write a hypothesis. For example: users keep contacting support because they cannot change their subscription settings on their own. In that case what interests us is not only whether they like the interface, but whether they can finish the task, how long it takes, and how often they need help.

For that you can use task success rate, time on task, and support tickets per thousand active users. And if you want to understand how hard the journey felt, add a Single Ease Question right after the task.

It matters not to confuse behaviour with perception. A user can say the interface is more modern and more pleasant, and still be slower at the task. Or the opposite: react badly to the change at first, and work more efficiently once they have adjusted.

That is why I think a good evaluation combines behavioural and subjective measures. The first tell you what happened. The second tell you how people felt about it.

But even the best set of UX metrics does not always answer the question the business is asking: what value did these changes create?

How do UX metrics connect to the business?

I find it interesting how differently designers and the business describe the same problem. A designer talks about complicated navigation, cognitive load, a lot of errors. The business sees low conversion, churn, rising support costs, or not enough throughput.

But these are not separate worlds. Often we are just looking at the same process from different sides.

Imagine an internal platform used by 200 employees. Each of them performs a certain operation ten times a day. After the journey is improved, the average time drops by one minute. On its own that minute looks like nothing, but across 230 working days it turns into roughly 7,667 hours freed up.

If the fully loaded cost of an hour is $50, that corresponds to about $383,000 of working time a year. This is not automatic financial saving, of course: for it to be real, the company has to use that time productively or reduce costs. But the scale of the potential effect is already visible.

Another example is a product with heavy support load. If improving the settings journey takes tickets from 4,000 to 2,500 a month, and handling one ticket costs $6, the potential saving is $9,000 a month. To call that fair, you still have to check that your change caused the drop, and not seasonality, a different audience or something outside the product.

These are illustrative calculations, but they show why UX metrics should not live apart from business ones.

How do we know the improvements actually worked?

Suppose conversion rose 12% after the updated product launched. Can we say design did that? Maybe. But a marketing campaign could have started at the same time, the price could have changed, a different audience could have arrived. A number moving after a release does not prove design moved it.

That is why I think the success criteria have to be set before the work starts. First we record a baseline, then we write a hypothesis, decide exactly what we are changing, and how we will check the result. Where it is possible, we use control groups or A/B tests. Where it is not, we repeat the measurement with the same method and say plainly what the result cannot tell us.

There is a separate difficulty: users do not always react well to change. Even when the new solution is objectively better, the familiar one can feel more comfortable simply out of habit. This is called change aversion. Judging a result by the first reactions after release is risky, although critical problems, obviously, have to be caught immediately.

And I would add one more question teams are not always ready to ask themselves: what do we do if the hypothesis does not hold? If the new solution turns out not to work, are we willing to revisit it, even after months of building it?

To me, the maturity of a product team shows not only in its ability to produce solutions, but in its willingness to admit that not every idea works the way we expected.

What changes in the age of AI?

Building interfaces is steadily getting faster and more accessible. AI tools let us generate components, assemble prototypes and even stand up working journeys far quicker than before. That changes not only the design process but where the value is actually created.

If we can build several alternatives quickly, the constraint is no longer the speed of making mockups. What matters much more is the ability to frame the problem correctly, pick a hypothesis worth testing, and check it with real users.

This shows up most clearly in AI products. Imagine an assistant that helps a user analyse documents. It produces an answer in seconds and, at first glance, everything works. But how much time does the person spend verifying it? How often do they have to correct the conclusions? How many attempts does a usable result take? And is this really more efficient than working without the AI?

We can build an experience that seems simpler because the user sees a single input field. But if we have handed them all the checking, clarifying and correcting, is that an improvement?

That is one more reason I think measuring outcomes matters more and more. Speed of production does not guarantee value.

Perhaps we should rethink the word itself?

I am not suggesting we drop the word “redesign”. It is clear, familiar and long since part of our professional language. But I would like it to stand more often for a specific wish to make the product better, rather than for the ambition to produce a new version of the interface.

Sometimes that calls for rethinking the whole experience. Sometimes it is enough to change one journey, revisit the information architecture, or remove actions nobody needs. And sometimes the best answer is to leave alone what already works.

It seems to me our profession is moving from producing screens to producing and testing decisions. And the cheaper making things becomes, the more it will matter to understand which problems actually deserve our attention.

“

The point of design is not to create change. The point is to create improvement, and to be able to show that it happened.

And perhaps, next time a team decides to do a redesign, the most useful question will not be “how do we want the product to look?” but “what exactly should work better once we are done?”.