DESIGNERS NEED KPIS TOO
Every product team measures the business. Almost none of them measure the experience.
Same product, two metrics, opposite conclusions.
The YCS mobile app had a business KPI and it was ugly. Adoption sat at 14%. The target was 80%. Read that number alone and the conclusion writes itself: the app is failing, fix the app.
Then you look at a second number. That 14% of users generated 41% of revenue. Per head, app users were worth roughly four times what desktop users were worth.
One metric says the app is broken. The other says the app is the most valuable channel in the business and almost nobody is on it. The second reading was the right one, and it changed what the project was. Not a rescue. An investment in the thing that was already working.
What I want you to notice is how close we came to never seeing it. The business KPI was tracked, dashboarded, and reported. The revenue-per-user cut existed only because someone went looking. The metric you choose decides what you conclude, and most teams only choose one.
02 / WHAT BUSINESS METRICS CAN'T TELL YOU
They tell you that something moved. Never why.
Adoption, conversion, revenue, retention. Indispensable, and blind in a specific way. When the number goes up, the business takes the credit, reasonably, because a dozen things changed at once. When it goes down, design gets asked what happened. Neither case tells anyone whether the experience actually improved.
Look at what happened next on YCS. After the new app shipped, adoption climbed from 14% to 45% over about six months. On a dashboard that is a triumph. But a new release arrives with partner comms, account manager pushes, App Store presence, and features people wanted anyway. How much of that 31 points was the design?
I cannot tell you. Neither could anyone else, because we were not measuring the experience. We were measuring the business and hoping the two moved together. That is the trap. A team can hit its number and learn nothing. Worse, it can hit its number while making the experience worse, and never find out.
03 / WHAT TO MEASURE INSTEAD
For a tool people are required to use, engagement is a meaningless metric.
This is where most UX measurement goes wrong. Teams reach for consumer metrics: time in app, sessions per week, engagement. On a consumer product those mean something. On an enterprise tool they are noise, or inverted. Nobody opens YCS for pleasure. A hotel manager updating rates at 7am wants to be out of the app. Time in app going up is not a win. It might be a defect.
YCS is a task application. People come to do a specific thing and leave. So the measurement had to be built around tasks, not attention. We defined five.
Task completion time. How long the core jobs take and where the time goes. The closest thing to a direct measure of whether the design is working.
Error management. How often users make mistakes in a flow, and how well the system helps them recover. Errors are friction with a receipt.
Data accuracy, target 100%. In an extranet, wrong data is not an inconvenience. It is a wrong rate on a live listing. An experience metric with a revenue consequence.
Content health score, target above 80. Whether each property has complete, current information. A partner who cannot easily keep their listing current has been failed by the interface, and the customer sees the result.
Accessibility coverage, WCAG 2.1 AA at 80%. Not a compliance checkbox. Half a million properties across dozens of markets is not a homogeneous user base.
Alongside those, SUS at 75 to 80 as a satisfaction check. Each metric is answerable, has a target, and is attributable to design. If completion time drops, that is the interface. If errors fall, that is the interface. These are numbers a design team can be held to, which is the entire point.
04 / WHY DESIGNERS SHOULD WANT TO BE MEASURED
Not being measured is not safety. It is irrelevance.
Most designers resist this. The instinct is that metrics flatten craft, that the good work is not quantifiable, that a number will eventually be used against you.
The opposite is true. If design has no metrics of its own, then design has no evidence, and a team with no evidence loses every argument to a team that brought a chart. You get overruled. You get asked to justify headcount with a portfolio. You get told the redesign did not move conversion and you have nothing to say except that it looks better.
UX KPIs are how design stops being a matter of taste and becomes a matter of record. They are also how you find out you were wrong, which is worth more than being unfalsifiable. The five metrics above were not a reporting obligation. They were an argument, made in the only language the rest of the organization was already speaking.
05 / WHERE I'D PUSH HARDER
We built the framework alongside the redesign. It should have come first.
The KPIs were defined. What they never got was a baseline before we shipped.
That is the mistake, and it is mine. When adoption went from 14% to 45%, we had no pre-launch measurement of task time, error rates, or content health to compare against. The one moment where those numbers would have been worth the most was the moment we did not have them.
Measure first. Then design. Otherwise you end up in exactly the situation this piece is arguing against: a number that went up, and no way to say why.
