At BNP Paribas Cardif, the activation portal I built the front end for replaced a manual call-center process and cut operational costs by 30%. At Wonderlabs, a redesigned onboarding flow for a credit card PWA increased user engagement by 15%. At Strongest Families, the redesign of a mental health platform I led improved usability scores by 25% and supported a $2M funding round. I am not sharing those numbers to impress. I am sharing them because numbers like these are what keep design work funded. Without a quantified change, results stay invisible to the business and design stays a cost center instead of a growth lever.
Most design teams lose the metrics argument because they bring craft numbers to a finance conversation. The translation between UX outcomes and business language is the work that earns designers a seat at budget decisions.
Why Most UX Teams Measure the Wrong Things
The most common UX metrics I see reported in sprint reviews are satisfaction scores from usability tests, NPS numbers, and time-on-page. These are not useless. But they are frequently misread. A high satisfaction score from a usability test means participants liked the experience in a controlled session with an observer present. That is not the same as users successfully completing real tasks under real conditions.
Time-on-page is even more misleading in isolation. For an editorial article, long time-on-page is good. Users are reading. For an insurance claim submission flow, long time-on-page is bad. Users are struggling. The metric means nothing without the context of the intended behavior.
The framework I return to is HEART, developed at Google by Kerry Rodden, Hilary Hutchinson and Xin Fu. Happiness, Engagement, Adoption, Retention, Task Success. Each dimension maps to specific metrics and each can be connected to a signal (what do we observe?) and a metric (how do we quantify it?). I do not always use all five dimensions. I pick the two or three that are most relevant to the product's current goals.
The Five Metrics That Actually Matter
These are the metrics I have used most consistently to demonstrate UX impact. They are not the only metrics. But they are the ones most directly traceable to user behavior and business outcomes.
1. Task Success Rate
Task success rate is the percentage of users who complete a defined task successfully. It is the most direct measure of whether your design works. For a form, success means submission without error. For an onboarding flow, success means account activation. For a search interface, success means arriving at a relevant result.
At BNP Paribas Cardif, the activation portal I built the front end for replaced a manual call-center process. Every customer who completed activation through self-service was one less call for a human agent, and that is where the 30% cost reduction came from. My role there was front-end development, not research. But the number that mattered to the business was not a usability score. It was call-center volume.
2. Time on Task
Time on task measures how long it takes users to complete a specific workflow. Shorter is better for transactional tasks (checkout, form submission, support ticket creation). This metric is valuable because it translates directly to cost in any workflow where human time is involved, and it translates to conversion in any revenue-generating flow.
3. Error Rate
Error rate tracks how often users make mistakes. Wrong input, failed submissions, navigation dead ends. High error rate is often a signal of unclear labeling, insufficient guidance, or a mismatch between the user's mental model and the interface model. Reducing error rate reduces support costs, reduces form abandonment, and improves confidence.
4. Engagement Metrics (Retention and Depth)
At Wonderlabs, the 15% engagement increase came from a redesigned onboarding flow on a credit card PWA with more than 50,000 users. Engagement is a lagging indicator. It responds to the cumulative experience, not individual interactions. It is harder to attribute to a single design change but it is the metric product leadership cares most about.
5. Net Promoter Score and CSAT
NPS and customer satisfaction scores are attitudinal metrics. They capture how users feel. They are useful as trend indicators and for benchmarking against competitors but they are weak for diagnosing specific problems. I use them as leading indicators: a drop in NPS flags that something is wrong before you see it in behavioral data.
Instrumenting Designs for Measurement
Measurement only works if you instrument for it at design time, not after the fact. This means identifying the key tasks in your flow before you build, defining what success and failure look like for each task, and ensuring that the implementation captures the necessary events.
- Define the task: what specific action constitutes success? Be precise, 'user completes checkout' is better than 'user is happy with checkout'
- Identify the start event: what user action marks the beginning of the task?
- Identify the success event: what backend or frontend event marks completion?
- Identify failure signals: errors, back-button presses, timeouts, abandonments
- Specify the funnel steps: every decision point between start and completion that should be tracked
- Document analytics requirements in your design specs. This makes instrumentation a development task, not an afterthought
// Analytics service in Angular, typed events for a specific flow
import { Injectable } from '@angular/core';
type OnboardingStep = 'personal-info' | 'identity-verification' | 'account-setup' | 'confirmation';
type OnboardingEvent =
| { event: 'onboarding_step_viewed'; step: OnboardingStep }
| { event: 'onboarding_step_completed'; step: OnboardingStep; duration_ms: number }
| { event: 'onboarding_step_error'; step: OnboardingStep; error_code: string }
| { event: 'onboarding_abandoned'; step: OnboardingStep; reason: 'timeout' | 'back' | 'exit' }
| { event: 'onboarding_completed'; total_duration_ms: number };
@Injectable({ providedIn: 'root' })
export class OnboardingAnalyticsService {
private stepStartTime = new Map<OnboardingStep, number>();
track(event: OnboardingEvent): void {
// Send to your analytics platform (Segment, GA4, Amplitude, etc.)
console.log('[Analytics]', event);
// analyticsClient.track(event.event, event);
}
startStep(step: OnboardingStep): void {
this.stepStartTime.set(step, performance.now());
this.track({ event: 'onboarding_step_viewed', step });
}
completeStep(step: OnboardingStep): void {
const start = this.stepStartTime.get(step);
const duration_ms = start ? Math.round(performance.now() - start) : 0;
this.track({ event: 'onboarding_step_completed', step, duration_ms });
}
recordError(step: OnboardingStep, error_code: string): void {
this.track({ event: 'onboarding_step_error', step, error_code });
}
recordAbandon(step: OnboardingStep, reason: 'timeout' | 'back' | 'exit'): void {
this.track({ event: 'onboarding_abandoned', step, reason });
}
completeFlow(flowStartTime: number): void {
const total_duration_ms = Math.round(performance.now() - flowStartTime);
this.track({ event: 'onboarding_completed', total_duration_ms });
}
}Making the Business Case for UX Investment
The classic mistake when presenting a business case for a significant design investment is leading with user experience rationale: mental models, cognitive load, emotional response. Leadership listens politely and the budget does not move. What works is leading with a number: onboarding completion sits well below the segment benchmark, and every abandoned application has a revenue value you can estimate. Framed as annualized revenue at risk, the same design investment becomes a much easier approval.
The structure I use for UX business cases has four components: the current state metric, the benchmark or target, the estimated impact in business terms, and the proposed investment. Everything is quantified. Everything traces to either revenue, cost, or risk.
- Current state: what does the data show right now? Task success rate, error rate, support ticket volume related to the problem
- Benchmark: what does good look like? Industry data, competitor research, or internal baseline from a better-performing product
- Projected impact: what is the expected change? Be conservative. Executives distrust optimistic projections
- Investment: design hours, development hours, testing time, tooling costs
- ROI or payback period: even a rough calculation makes the case concrete
- Risk of inaction: what is the cost of not investing? Useful for compliance-driven cases
The Attribution Problem
One honest challenge with UX metrics is attribution. Say conversion goes up by 18% after a redesign. That number is illustrative, not one of mine. Was it the redesign, the marketing campaign that ran concurrently, the promotional pricing, or seasonality? Clean attribution is rare. The approaches that work are A/B testing (split the change and a control group), staggered rollouts (release to 10% first and measure), and pre/post analysis with a holdout group. All three need release and experimentation infrastructure behind them.
That infrastructure is the gate, and most teams do not have it. Without it you cannot run a clean split, so the fallback is pre/post measurement with a clear snapshot taken before the work begins. That is the version I have actually run: baseline the metric first, measure the same metric after, and be explicit about everything else that changed in the window. The key is baselining. You cannot prove impact if you did not measure before.
You do not need perfect attribution to build a compelling case for design investment. You need a believable story supported by data that moves in the right direction, at the right time, by a meaningful amount.
Design is most effective when it is treated as a discipline with measurable outcomes, not a service function that produces deliverables. The teams I have worked with that made the biggest impact were the ones who owned their metrics, reported on them in business terms, and used them to drive prioritization. Start with task success rate. Baseline it before you change anything. Report the delta. The conversation with the business changes immediately.
References
- Google HEART Framework (Rodden, Hutchinson, Fu, CHI 2010). https://research.google/pubs/measuring-the-user-experience-on-a-large-scale-user-centered-metrics-for-web-applications/
- Nielsen Norman Group. Success Rate: The Simplest Usability Metric. https://www.nngroup.com/articles/success-rate-the-simplest-usability-metric/
- Amplitude. Product Metrics. https://amplitude.com/blog/product-metrics