The HEART framework

Overview

You already know how to tell an actionable metric from a vanity one (lesson 2) and why a comparable rate is stronger than a total (lesson 3). But that still doesn't answer a very practical question: faced with a new feature like recommendations, where do you even start looking for candidate metrics? Without a structure, it's easy to either fall short —measuring one single thing and missing the rest of the story— or go to the other extreme —measuring everything you can think of, with no criterion for how important each thing is—.

HEART is a framework Kerry Rodden, Hilary Hutchinson, and Xin Fu published at Google in 2010 to solve exactly that problem for large-scale UX products. The name is an acronym for five dimensions of user experience: Happiness, Engagement, Adoption, Retention, and Task success. These aren't five fixed metrics —they're five different questions you can ask about any feature, and for each one, you choose the actionable metric (a rate, per what you learned in lessons 2 and 3) that best answers it for your product.

How this connects to the module. This lesson and the next one (AARRR) are the module's two structuring tools: instead of picking metrics at random, HEART gives you five different angles to look at a feature within the product, and AARRR (lesson 5) gives you five stages of a user's journey through the business. Lesson 6 will take some of the metrics you choose today and organize them into a tree with a North Star on top.

An analogy: the full medical checkup

When you go for a general medical checkup, the doctor doesn't take a single vital sign and send you home. They measure several different things —blood pressure, temperature, heart rate, blood oxygen, weight— because none of those five measurements, on its own, tells you whether you're healthy. You can have a perfect temperature and dangerously high blood pressure. The full checkup exists because health has several independent dimensions, and each one needs to be looked at with its own instrument.

HEART does the same thing for a product's health: instead of a single number that "sums it all up" —the classic mistake of measuring a feature with one metric—, it forces you to look at five independent dimensions of the experience. A feature can have an excellent adoption rate (lots of people try it) and terrible retention (nobody comes back to use it); if you only looked at adoption, you'd think everything was fine. The framework's name, literally "heart" in English, isn't a coincidence: it's a full checkup, not a single thermometer.

Worked example: HEART applied to recommendations

Let's walk through HEART's five dimensions and, for each one, propose the actionable metric —always a rate, following lesson 3's criterion— that best answers it for Mercado's recommendations carousel:

Dimension	Question it answers	Candidate metric for recommendations
Happiness	Are users happy with the experience?	Short post-purchase survey: "how useful were the recommendations?" (CSAT 1 to 5, reported as % of 4-5 responses).
Engagement	Of those who see the feature, how much do they interact with it?	recommendationClickRate — clicks on the carousel ÷ times it was shown (impressions), per session.
Adoption	How many new users start using the feature?	% of new buyers (their first week on Mercado) who interact with the carousel at least once.
Retention	Of those who already used it, do they come back to use it?	% of users who interacted with recommendations last week and interact again this week.
Task success	Does the feature help complete the real task —buying?	checkoutConversionRate of sessions that saw recommendations, compared against those that didn't.

Notice a pattern: four of the table's five metrics are rates with a clear numerator and denominator —exactly lesson 3's criterion—. The exception is Happiness, which by nature measures a stated opinion (a survey), not directly measured behavior. That doesn't make it invalid: HEART includes Happiness on purpose because there are things —like whether a user likes an experience— that behavior alone doesn't always reveal. But it does mean Happiness needs to be read more carefully than the other four: a survey can have response bias, which is why it's almost never used alone to decide whether a feature worked.

The full process: goals, signals, metrics

Rodden doesn't just propose the acronym: she proposes a three-step process for getting from an abstract dimension to a concrete metric, which is worth seeing applied to one dimension in detail —let's take Engagement:

1. Goal: in simple words, what do we want to achieve? "That users interact with recommendations when they see them."
2. Signal: what behavior, if we saw it, would tell us the goal is being met? "Users clicking on products in the carousel, not just scrolling past it."
3. Metric: how do we turn that signal into a measurable, comparable number? recommendationClickRate = clicks on the carousel ÷ carousel impressions, per session.

Repeating this process —goal, signal, metric— for each of the five dimensions is what prevents the most common mistake in using HEART badly: jumping straight to "we need an Engagement metric" without first articulating what specific behavior, in this product, would mean engagement improved.

An important clarification: the five don't always apply

Rodden herself is explicit about this: not all five HEART dimensions are relevant for every feature. A purely visual change —like redesigning a button's color— probably doesn't have a real story to tell in Adoption (nobody "adopts" a color) or in Retention. Forcing a metric into each of the five letters, even when it doesn't make sense for what you're measuring, is exactly the kind of over-engineering this entire module tries to avoid. For recommendations, all five dimensions do make sense —it's a new feature, with a real adoption curve, a measurable interaction, and a direct link to the task of buying—, but don't assume it will always be that way.

Common mistakes

Measuring 50 things inside HEART and acting on none of them. What happens: a team, excited about the framework, attaches three or four metrics to each of the five letters —"just in case"— and ends up with a twenty-metric dashboard nobody reviews in depth every week. Why it happens: HEART feels like a checklist you need to "fill out completely" to do it right, when the actual goal is to choose one strong metric per relevant dimension, not to accumulate every possible one. How to spot it: if you ask the team "what action would you take if this specific metric dropped 10% tomorrow?" and they don't have a clear answer for half of the twenty, half of them are excess. How to fix it: for each dimension, choose the single actionable metric that best answers its question —like in today's table— not a collection. Fewer, well-chosen metrics get reviewed; many don't.

Confusing Happiness (stated opinion) with Engagement (real behavior). What happens: a team reports a high satisfaction survey ("90% say recommendations feel useful") as if it were evidence people are actually using them, without looking at the real recommendationClickRate. Why it happens: the two things sound similar —"they like it" and "they use it"— but they're different types of signal: one is what people say, the other is what people do. How to spot it: the conclusion about a feature rests only on a survey, with no real behavior data backing it up. How to fix it: use Happiness as a complement to Engagement and Task success, never as a substitute. If the survey says people like it but the click rate is very low, there's a real disconnect worth investigating, not ignoring.

Forcing all five letters even when the feature doesn't need them all. What happens: for a small change —like adjusting the order of search filters— the team insists on defining an Adoption metric and a Retention metric, forcing something because "HEART has five letters". Why it happens: the acronym feels like a template that has to be filled out completely to "be using the framework correctly". How to spot it: the proposed metric for a dimension has no real business question behind it —it's an answer to "we need to fill this box", not to "we need to know this". How to fix it: remember Rodden's own clarification: not every dimension always applies. For a big, new feature like recommendations, all five make sense; for a small tweak, maybe only one or two do, and that's fine.

Exercises

Exercise 1 — Locate the dimension. For each candidate metric, say which of HEART's five letters it belongs to, and why:

• (a) % of new sellers who upload at least one product in their first week on the seller dashboard.
• (b) Average time it takes a buyer to find and complete a return (measured against whether they succeeded without contacting support).
• (c) % of buyers who used the price filter last week and use it again this week.

See solution

• (a) Adoption. It's exactly the adoption question: how many new users start using the feature (the seller dashboard)?
• (b) Task success. The question is whether the feature (the return flow) helps complete the real task —getting the return done— without friction, not whether people "like" it or come back to it.
• (c) Retention. The structure —"used it last week, do they use it again this week?"— is retention's exact definition within HEART, applied to a specific feature (the filter), not to the whole product.

Exercise 2 — Apply the three-step process. For recommendations's Task success dimension, write the Goal, the Signal, and the Metric yourself, following the same process applied to Engagement in the lesson. (The table above already gives you the final metric; the exercise is reconstructing the full reasoning backward.)

See solution

A reasonable answer: Goal — "that recommendations help users complete a purchase, not just browse". Signal — "users who see recommendations and end up completing checkout, compared to users who don't see them". Metric — checkoutConversionRate segmented by whether the session included an interaction with the carousel or not. The point of the exercise is to notice that the table's final metric (checkoutConversionRate) doesn't appear out of nowhere: it comes from first articulating, in simple words, what behavior would count as real task success.

Exercise 3 — Spot the forced fit. The team behind a minor change —changing Mercado's shopping cart icon— proposes this Adoption metric: "% of users who click the new icon at least once". Why is this metric an example of the "forcing all five letters" mistake, and what would you measure instead?

See solution

It's forced because every user who uses the cart automatically "adopts" the new icon just by continuing to use the product normally —there's no real decision to "start using" something new, the way there is with a genuinely optional feature like recommendations—. The metric would end up being almost identical to total active users, disguised as "Adoption", saying nothing specific about the icon change. Instead, for a change this small, neither Adoption nor Retention probably makes sense: the relevant dimension is more likely Task success —do people still find and use the cart just as fast as before, or did the new icon cause confusion?— measured, for example, with the rate of users who open the cart and complete checkout without navigation errors.

Summary and next step

In this lesson you learned HEART —Happiness, Engagement, Adoption, Retention, Task success—, Google's framework for choosing metrics from five different angles of the experience within a product. You saw the three-step process (Goal → Signal → Metric) applied to recommendations, built the full five-dimension table for Mercado's carousel, and learned the key clarification: not every dimension always applies, and forcing all of them —or piling up metrics within each one— is the most common mistake in using the framework.

Before moving on you should be able to: name HEART's five dimensions and the question each one answers; apply the Goal → Signal → Metric process to a new dimension; and recognize when a HEART dimension doesn't apply to a specific change.

Lesson 5 gives you the module's second framework: AARRR, from Dave McClure. Where HEART looks at the experience within a feature, AARRR looks at a user's full journey through the business —from arrival to payment—.

Resources

• Kerry Rodden, Hilary Hutchinson, and Xin Fu, "Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications" (CHI 2010) — research.google/pubs/measuring-the-user-experience-on-a-large-scale-user-centered-metrics-for-web-applications. The original paper where HEART was born. In English.
• Kerry Rodden, personal page on HEART — kerryrodden.com/heart. Additional resources from the framework's author, including the original Google Ventures post and a chapter of her book on quantitative UX research. In English.
• ProductPlan, "HEART Framework" — productplan.com/glossary/heart-framework. A practical summary of the Goals → Signals → Metrics process with additional examples outside Mercado. In English.