A UX metric is not an outcome: baselines and conversions

A UX metric tells you how the interface performed. An outcome tells you what changed in the business because of that interface. People who approve budgets look at revenue, cost, risk, speed and retention, and neither “we ran 24 interviews” nor “our usability score went up” answers any of those. To show impact, pick one behavioral metric before the project starts, measure where you stand, and tie the final number to one of those five areas.

Two kinds of report that make design look like a cost

In 2026 NN/g published a piece on reporting business outcomes instead of UX activity. It names two habits that keep showing up in teams that lose funding.

Reporting effort. Counting interviews and studies says what the team did, not what changed.
Reporting UX metrics to people who don’t track them. A SUS score moving from 62 to 74 means nothing to a CFO who has no idea whether 74 is good.

The article doesn’t ask you to drop usability scores. It just gives each number its place. Task success and SUS describe the design, so they belong in the research report. Support volume, conversion and churn describe the effect, so they belong in the budget conversation.

The five questions leaders actually ask

The same piece lists the questions a leader asks about any investment. They work well as a filter before you choose a metric.

Does it affect revenue? Friction in signup or checkout costs sales.
Does it cut cost? Every support contact costs money, and confusing screens create contacts.
Does it lower risk? Design-caused errors can turn into legal, financial or compliance trouble.
Does it ship faster? A problem caught in a prototype is a quick fix, and one caught after the build eats a sprint.
Does it keep customers? People who never reach a first success in the product leave early.

If the change you plan touches none of the five, the report will be weak no matter how good the work is. Better to know that before you start.

Without a baseline, the final number says nothing

The usual mistake is measuring too late. Another NN/g piece, on making baselines a habit, makes the point with a plain example: a 67% completion rate after a redesign only proves something if you know it was 48% before. Without the before, the after is just a figure.

Its rules for choosing the metric fit in three lines.

Relevant over easy. Page views and session length come free from analytics and rarely tell you whether the flow got better.
One metric. Tracking five gives you room to report whichever one rose, and that wears down trust over time.
Behavior over opinion. Completion and error rates show what happened. Self-reported satisfaction shows how it felt, and leaves more room for argument.

The article also asks you to write the method down next to the number: how, when and with whom you measured. If January was a moderated test and August was an unmoderated one, the comparison loses its weight. And the baseline should be shown to decision makers before the build, not after.

Historical analytics can serve as a starting point too. The piece accepts that when the team knows where the data came from, and warns that data gathered for another purpose may have gaps.

The case I measure against

The example that taught me this difference best was the voltage bug, from my work at Stefanini Brasil. The change itself was small: voltage stopped being text on the page and became a required field before checkout. As an activity report, it would read “one new field in the purchase flow”, and nobody would care.

What got measured was something else. The starting point already existed in the returns report the data team brought in. The metric was behavioral and landed right on cost: appliance returns, which fell 18% right after the change, with refund and shipping costs falling with them. Before that, the change went through an A/B test, with both versions live at the same time.

My reading: the number worked because it was in the language of whoever pays for return shipping. Nobody had to ask what it meant.

Macro and micro conversions

Not every project has a cost figure that direct. In those cases the split between macro and micro conversions helps. The NN/g article on the two defines them like this:

A macro conversion is the action that serves the product’s main goal. A completed purchase, a submitted lead form, an account created in a community.
A micro conversion is a smaller action that tends to come first and happens more often. Adding to cart, starting checkout, subscribing to a newsletter.

Micro conversions matter because macro ones are rare and slow to move. The article cites an average macro conversion rate of 2.9% across industries. A small fix in one step of the flow may not shift that rate in time for you to notice, but it shows up in the next step (NN/g).

The piece splits micro conversions in two. Process milestones are the steps that lead straight to the macro conversion, such as confirming an email before the account is created. Secondary actions don’t lead there directly but suggest the person will come back, such as comparing products or downloading a document. To find where a flow gets stuck, milestones are the useful ones, and funnel analysis is where they show up.

There is one limit people often ignore. Conversion rate is the wrong measure for mandatory actions. The article’s example is a vacation request on an intranet: the number of requests won’t change with the design, because nobody has another way to do it. There, the work is measured by ease of use, error counts and support contacts.

What NPS can and can’t tell you

NPS sits on almost every product dashboard, and the NN/g piece on NPS and user experience explains why it can’t judge a single screen.

It measures loyalty to the whole company. Price, service and brand all feed the score, and a clearer icon won’t move it.
It sorts answers into three buckets and drops the passives. A change that lifts most scores from 2 to 5 still counts everyone as a detractor.
It varies by country. The article cites a Qualtrics study across 18 countries in which the gap between scores for liked and disliked companies was widest in Brazil (NN/g).
It needs a large sample. Asking for NPS at the end of a five-person test gives you no valid data.
It is easy to game. Asking only after a good support call already skews the sample.

None of this takes NPS off the table. Leadership knows it and likes it, and it tracks overall perception over time. Its place is next to a behavioral metric, not instead of one.

Where the sources disagree

One metric or several. The baseline piece asks for a single metric, so nobody picks the winner after the fact. The NPS piece recommends combining measures, because no subjective score alone describes the experience. My take: pick one to decide and keep the others to explain.
NPS in the leadership conversation. The outcomes piece lists NPS and CSAT as fair satisfaction measures for leaders. The NPS piece warns that it barely reacts to a local interface change. Both hold at different scales: NPS works for the whole product and fails for one screen.

How to set up the report before the project starts

Pick the business area the change should move: revenue, cost, risk, speed or retention.
Pick one behavioral metric tied to it. If the action is mandatory, swap conversion for errors and support contacts.
Measure the starting point and write the method next to the number.
Agree with finance, support or analytics on access to the after data. Without that access, the translation never happens.
Show the baseline to decision makers before you build.
Measure again with the same method, and read the result with the sample care an A/B test needs.
Report the number in business terms and keep the usability score in the research appendix.