How to Measure UX Design's Hidden Value
Measure UX value by defining the user outcome before the change, choosing observable signals and recording a baseline. Google's HEART paper connects happiness, engagement, adoption, retention and task success with a goals/signals/metrics process. Choose the measures that fit the task; collecting every available number is not a measurement strategy.
Key Takeaways
- Write the goal, signal and metric before implementation.
- Use small qualitative sessions to find problems, not estimate precise population rates.
- Keep reported health signals separate from evidence of efficacy.
- Explain the link before attributing a financial result to UX.
The product examples describe our own design work and the October 2026 project records. They illustrate measurement choices, not clinical validation or causal evidence of design effectiveness.
Why UX value looks hidden
UX work rarely fails to create value. It fails to leave a receipt. A redesign ships, conversion moves a little, support tickets drop a little, and six weeks later nobody can say which change did what, because nobody recorded where things stood before.
There are three usual causes:
- No baseline. The metric was never measured before the change, so there is no "before" to compare with.
- The wrong level. Teams track revenue, which design influences but does not control, instead of the user behaviour design directly changes.
- Too many metrics. A dashboard with forty numbers cannot tell you anything about one decision.
This post is about the mechanics of measuring, not the argument for doing it.
Goals, signals, metrics
The HEART paper by Kerry Rodden, Hilary Hutchinson and Xin Fu (Google, CHI 2010) describes the framework as user-centered metrics plus "a process for mapping product goals to metrics". The process is the useful part, and it fits on an index card:
- Goal. What should be true for the user if the design works? Write it in plain language. "New users reach their first completed session without help."
- Signal. What would you see in the product if that were happening? "A first session is completed within the first visit."
- Metric. How do you count the signal over time? "Share of new installs with a completed session within 24 hours, weekly."
The five HEART categories are a checklist for goals, not five dashboards to build. Pick the one or two that match the decision in front of you.
| Category | A goal it captures | A metric you could track |
|---|---|---|
| Happiness | Users feel the product helped | Short in-product rating after the core task |
| Engagement | Users come back to the core task | Core tasks per active user per week |
| Adoption | New users try a new feature | Share of active users who used it in week one |
| Retention | Users are still here later | Share of a signup cohort active after 30 days |
| Task success | Users finish what they started | Completion rate and time on the core flow |
Start with task success
Task success is a useful starting measure when the product is supposed to help someone complete a defined job. Specify full success, partial success and failure before watching the sessions.
An exploratory session can show what happened for that person under those conditions. Task success also depends on prior knowledge, data, context and system behavior, so do not attribute every difference to the interface or treat a small sample as a precise population estimate.
A practical version:
- Name the three tasks that matter most, for example "sign up", "complete the first core action", "change a setting".
- Watch five people attempt each one, recorded. Score full success, partial success and failure, with partial defined in advance.
- Write the baseline down with a date. Ship the change. Repeat the same tasks with five new people.
This is close to how our product UX audit starts: the product used end to end as a new user, recorded, then a ranked fix list with effort and expected impact. The recording is the baseline.
Build the outcome into the product
The strongest way to stop UX value hiding is to make the product measure the outcome for the user, on screen, every time. Then the metric is not a report someone remembers to run. It is a feature. Three apps we designed and built do this.
ILTY, an AI mental health companion. The app records self-reported mood before and after a conversation and provides specific next steps. The case study shows that product choice. A reported mood change is a signal to investigate, not proof of clinical benefit or that the conversation caused the change.
HRV Breathe, a breathwork app. HRV Breathe displays HealthKit-derived HRV changes in session history. That makes a recorded physiological signal visible; it does not establish that the exercise improved health or caused the observed variation.
TrackCold, a cold plunge timer. The project includes heart-rate and recovery displays. Describe the recorded measure accurately rather than treating it as proof of physiological adaptation or a recommended exposure protocol.
The pattern generalises well beyond health apps. A project tool can show time saved against last month. A booking flow can show how long checkout took. If the outcome is visible to the user, it is also visible to you, and the value of the design stops being hidden.
Tie the metric to one business number
Small exploratory sessions can reveal failures and possible repairs. Repeating a task with five new people does not by itself isolate causation or provide a precise population success rate. The iterative-testing rationale should be used within that qualitative scope.
Once a UX metric moves, connect it to exactly one business number, and say how. A KPI tree helps here, as long as it stays small:
- Business goal: more paying customers.
- Funnel step design controls: share of trial users who complete the core task in week one.
- Design change: a shorter onboarding that reaches the core task in three screens instead of six.
Each level should be something you can measure, and the link between levels should be a sentence you would defend in a meeting. If you cannot explain why the UX metric drives the business number, track the UX metric anyway, but do not claim the revenue.
For marketing sites the same logic applies with different signals. A website audit gives you a dated technical baseline, and a conversion optimization retainer is, at heart, one measured change a month against that baseline.
What we cut from the earlier version of this post
The first version of this article, published in December 2024, included a case study with before-and-after percentages for trust, task completion and feature discovery. We could not trace those numbers to a recorded study, so they are gone. That is the same standard the post recommends: if there is no baseline on file, there is no result to report.
The short answer
Write down a goal, signal and metric before changing the product. Record task outcomes with the sample and conditions, and distinguish observation from causal evidence. If the product displays a user-relevant signal, explain what it does and does not establish. Connect a financial result only when the relationship and attribution are defensible.
Have a product idea?
Designed, built, and shipped in about 5 days.