The HEART Framework: Measuring UX Quality, Not Just Usage

Google's HEART framework measures user experience quality across five dimensions—Happiness, Engagement, Adoption, Retention, Task success—by forcing teams through a Goals-Signals-Metrics process instead of jumping straight to whatever numbers are easiest to pull from an analytics dashboard.

Quick Answer: HEART = Happiness, Engagement, Adoption, Retention, Task success. Pick only the dimensions relevant to your feature, define a goal for each, name the observable signals that indicate progress, then convert those signals into specific metrics. Skip dimensions that don't fit rather than forcing all five.

Most teams that "use HEART" actually just relabel their existing dashboard: DAU becomes Engagement, signups become Adoption, and Happiness gets a token NPS widget nobody reads. That's not the framework — that's the acronym wearing the framework's name. The actual value of HEART, as Kerry Rodden and her Google colleagues designed it in their 2010 CHI paper "Measuring the User Experience on a Large Scale," is the discipline of the Goals-Signals-Metrics (GSM) process that sits underneath the five letters.

What Is the HEART Framework, Exactly?

HEART is a five-dimension model for evaluating user experience quality — Happiness, Engagement, Adoption, Retention, and Task success — paired with a three-step process (Goals, Signals, Metrics) that turns each dimension into something you can actually instrument and track over time.

Rodden's team built it at Google because usage counts alone couldn't tell product teams whether an experience was actually good. A feature can have rising usage and declining satisfaction simultaneously — think of a confusing checkout flow that people are forced to use, or a workaround users tolerate because there's no alternative. HEART exists to catch that gap.

Each dimension pairs a behavioral signal with, where possible, an attitudinal one — Rodden was explicit that neither alone gives a full picture. Behavioral data tells you what people did; attitudinal data tells you how they felt about it. A rising completion rate paired with a falling CSAT score means people are succeeding but grinding through friction to get there, which is exactly the kind of blind spot raw usage metrics create.

The Goals-Signals-Metrics Process, Step by Step

The GSM process is the actual mechanism that makes HEART usable: for each relevant dimension, you write a goal in plain language, list the observable signals that would indicate progress toward it, then pick one or two specific metrics from those signals. Skipping straight to metrics is the single most common way teams misuse HEART.

Why order matters: if you start with metrics, you anchor on whatever your analytics tool already tracks, which biases you toward vanity numbers. Starting with goals forces you to articulate what "good" means for this feature before you know what's measurable, which is the whole point.

Step 1 — Write the Goal

A goal is a single sentence describing the outcome you want for users, stated without any numbers in it. "Users can find the report they need without asking a teammate for help" is a goal. "Increase search usage by 20%" is not a goal — it's a target for a metric you haven't defined yet.

Goals should be written per-dimension, per-feature. A search feature's Task success goal ("users find what they're looking for quickly") is different from its Engagement goal ("users return to search rather than browsing manually"). Conflating them produces a metric that serves neither goal well.

Step 2 — List the Signals

Signals are the observable, real-world indicators that would move if the goal were being met — before you've decided how to instrument them. This step is brainstorming, not measurement design; the goal is to list every plausible signal, then narrow.

For a search-find-report goal, plausible signals include:

• Number of searches per session before finding the target document
• Rate of users abandoning a search and browsing manually instead
• Rate of repeat searches for the same term within a session
• Time between search initiation and document open
• Support tickets mentioning "can't find"

Notice none of these are metrics yet — they're candidate observations. Some will turn out to be hard to instrument cleanly and get dropped in Step 3.

Step 3 — Convert Signals to Metrics

A metric is a specific, computable definition of one signal — with an exact event, a time window, and a unit — that you can actually pull from your data. This is where the tracking-plan work happens: each metric needs a named event, a clear property schema, and a defined denominator.

From the signals above, a team might land on:

1. search_result_click_rate = searches resulting in a document open within 60 seconds, divided by total searches
2. search_abandon_rate = searches with zero result clicks followed by manual navigation, divided by total searches
3. search_repeat_rate = identical search terms re-entered within the same session, divided by total searches

Getting these definitions instrumented cleanly is exactly the work covered in a complete guide to analytics instrumentation — HEART tells you what to measure, but you still need sound event naming conventions and a well-designed event property schema to actually capture it reliably. Teams that skip a tracking plan before writing code usually discover mid-analysis that the event they need was never logged with the property that would let them compute the metric.

A Filled HEART Table: In-App Notifications

Applying HEART to a real feature makes the abstraction concrete — here's a complete Goals-Signals-Metrics table for an in-app notification center, a feature type common enough that most PMs can map it onto their own product.

A one-sentence takeaway: this table shows five independent stories — a notification center can have excellent Task success (people act fast) while Happiness quietly erodes (they're annoyed by volume), and only measuring one dimension would hide that.

When to Skip a Dimension

Skip a HEART dimension when the feature genuinely has no meaningful signal for it — forcing a metric onto a dimension that doesn't apply produces noise that dilutes the dashboard rather than clarifying it. Not every feature needs all five letters filled in.

Common, legitimate skips:

• Adoption doesn't apply to a feature every user already has and always sees (e.g., the primary navigation bar) — there's no "adoption event" because there was never a choice to opt in.
• Retention is often meaningless for a one-time-use feature, like a data-import wizard run once at account setup. Measuring "day-30 retention" on a wizard is a category error.
• Happiness is hard to attach meaningfully to a purely backend or infrastructure-facing change (say, a caching layer) where users have no direct perception of the change at all — Task success and reliability metrics carry the weight instead.
• Engagement can be actively the wrong goal for a feature explicitly designed to be used briefly and rarely, like a password-reset flow — high engagement there would actually signal a problem (repeated failed resets), not health.

The discipline isn't filling five cells. It's asking, honestly, dimension by dimension: "does this even mean anything here?" — and writing "N/A, and here's why" when it doesn't. A HEART table with three filled rows and two deliberate skips is more credible than one padded to five with forced metrics.

HEART vs. Other UX Measurement Frameworks

HEART is one of several structured approaches to measuring experience quality, and understanding where it overlaps with and differs from adjacent frameworks helps you choose (or combine) the right one for a given question.

These aren't competitors so much as instruments with different resolutions. SUS and CES are strong at a single moment — a usability test session, a specific support interaction — while HEART is built for continuous tracking of a live feature, which is why it maps so cleanly onto product analytics instrumentation rather than one-off research studies.

A useful pattern: use SUS or a moderated usability test to generate qualitative hypotheses about why Happiness might be low, then instrument HEART's quantitative Happiness signal to track whether a fix actually moved the needle over time. Jakob Nielsen and the Nielsen Norman Group have long argued the same point from the usability-research side — qualitative and quantitative methods answer different questions and neither substitutes for the other.

How HEART Connects to Jobs-to-Be-Done and Customer Journey Work

HEART measures whether an experience is good; it doesn't by itself tell you which jobs users are hiring your product for or where in their journey the friction actually lives — that context has to come from complementary frameworks upstream of instrumentation.

Before you can write a credible HEART goal, you generally need to already know what job the feature serves — which is the territory covered by a complete guide to jobs-to-be-done. A Task success goal like "users complete their report request" is only meaningful once you know the underlying job ("get budget approval before Friday's meeting") that the report actually serves.

Similarly, HEART's Happiness dimension benefits from journey context. A complete guide to customer journey mapping shows where in a multi-step flow a user's sentiment shifts — which tells you which touchpoint to instrument a Happiness signal around, rather than measuring satisfaction generically at the end of a session and losing that resolution.

Where Prodinja Fits: Qualitative Happiness Alongside Quantitative Signals

The Happiness dimension is the hardest of the five to instrument well, because a numeric survey score alone often can't tell you where in an experience the sentiment shift happened. Prodinja's Customer Journey tool addresses that gap by letting a PM walk through a flow and plot an emotion curve stage by stage — capturing qualitative Happiness signal tied to a specific touchpoint, which is designed to complement the quantitative CSAT or micro-survey metric you're already instrumenting for the same dimension. It's not a replacement for the HEART metric itself — it's the qualitative half of the same Happiness row, giving you a "why" to sit next to the "what."

Key Takeaways

• HEART is five dimensions — Happiness, Engagement, Adoption, Retention, Task success — but the real value is the Goals-Signals-Metrics process that prevents teams from jumping straight to whatever's already in the dashboard.
• Write goals before signals, and signals before metrics — starting with metrics anchors you to what's easy to measure rather than what actually matters.
• Pair a behavioral metric with an attitudinal one wherever possible — usage and satisfaction can diverge, and either alone hides half the picture.
• Skip dimensions that genuinely don't apply — forcing Adoption onto an always-on feature or Retention onto a one-time wizard produces noise, not insight.
• A filled HEART table is only as good as the tracking plan behind it — sound event naming and property schemas are what make the metrics computable in practice.
• HEART complements, rather than replaces, frameworks like JTBD and customer journey mapping — those tell you what job and where in the flow to look; HEART tells you if the experience there is actually good.