01 / UNDERSTAND
What is the HEART framework?
HEART is a framework for selecting user experience measures across Happiness, Engagement, Adoption, Retention and Task Success. Kerry Rodden, Hilary Hutchinson and Xin Fu introduced it in their CHI 2010 paper on measurement at scale. The categories help a team consider different aspects of experience rather than relying on one activity count.
The accompanying Goals, Signals, Metrics process starts with the improvement sought, identifies observable signs of that improvement and specifies how to measure them. HEART is not one composite score. Not every category needs a metric, and the meaning of successful use depends on the product’s purpose.
Why use HEART Framework?
A dashboard can be precise about activity while remaining vague about whether people were helped. HEART encourages the team to connect behavioural and attitudinal evidence to a named goal. It also makes disagreements visible: increased engagement may be beneficial for one product and a sign of repeated difficulty in another.
When to use it
USE IT WHEN
A product team needs measures that reflect experience as well as commercial activity.
A redesign has a clear goal but success is currently described only as more clicks or visits.
Existing metrics point in different directions and need a shared interpretation.
When to choose another method
Use User Interviews when the goal or expected behaviour is poorly understood.
Use Usability Testing to examine where a specific task breaks down.
Use Research Plan to choose an evidence approach before instrumenting uncertain signals.
What you’ll need
Define the product situation, audience and intended improvement. Bring knowledge of event logging, surveys and research access. Agree the unit being counted, eligibility, time period and exclusions. Check whether events mean what their labels imply. Plan privacy appropriate collection and access. A metric should have someone responsible for its quality as well as someone who owns the product decision.
What the HEART framework contains
Keep the elements that help answer your question and support a decision.
Attitudes such as satisfaction, confidence or perceived ease.
Relevant involvement, interpreted against the purpose of use.
Starting a defined meaningful use, within an explicit eligible audience.
Continued relevant use of a defined cohort across an appropriate interval.
Effectiveness, efficiency or errors in accomplishing an intended activity.
The connection between the improvement sought, observable evidence and a precise measure.
02 / PUT IT INTO PRACTICE
How to apply HEART to a product decision
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Name the experience goal
Write the change sought without starting from available analytics events.
Residents should know whether a repair visit is actually confirmed.
02
Choose relevant categories
Use HEART to test the breadth of the goal; select only categories that help.
Happiness and Task Success may matter more than repeated engagement.
03
Describe signals
Identify what people would do or report if the improvement occurred.
A person can identify the confirmed time and explain what remains pending.
04
Define metrics
Specify numerator, denominator, unit, interval and meaningful exclusions.
Count eligible attempts where the correct appointment state is identified, not every page visit.
05
Check data quality
Verify that logged events or questions capture the signal and inspect missing cases.
A status page load is not evidence that the status was understood.
06
Add counterchecks
Look for consequences a primary metric could conceal.
Fewer support contacts could indicate clarity or difficulty reaching help.
07
Review and decide
Read patterns alongside contextual research, then change the product or measurement definition.
Investigate unresolved cases before interpreting lower contact volume as success.
Example: measuring appointment status clarity
Fictional scenario, continuing the repair booking case used in User Stories and Product Roadmap: a repair booking team wants residents to know which appointment they can rely on. It selects Task Success for correct interpretation of the booking state and Happiness for confidence in arranging access. Repeated visits are kept as a diagnostic signal rather than a target to increase.
A proposed research measure records whether an eligible participant correctly identifies the confirmed appointment without assistance. A short follow up question explores confidence and the reason behind it. Service data can show repeat status checks, but that event alone cannot distinguish uncertainty from a legitimate changed situation.
The team would examine these signals together. Fewer visits and fewer support contacts are encouraging only if people still understand the appointment and can get help. All measurement choices here are illustrative; no improvement, benchmark or observed product result is claimed.
03 / BELOW THE SURFACE
Below the surface: a successful service can reduce engagement
Repeated use is meaningful only in relation to the reason a person returns.
INTENTION
Why would the person return?
Separate useful repeat use from unresolved work.
COUNTERCHECK
What could make the metric look better without helping?
Name a competing explanation before reviewing results.
MEASUREMENT
Who is counted and who is missing?
Keep eligibility, interval and denominator explicit.
A booking service may be better when a resident checks once, understands the commitment and leaves. A dashboard that rewards return visits could favour unclear status or repeated reassurance. The same event can therefore represent either value or unresolved work.
Before setting a target, name the user intention behind the event and an alternative explanation for an apparent improvement. Measure the completed need, not merely the repeated interaction. If support contacts fall, check whether uncertainty fell too and whether assistance remained accessible.
Use a countercheck that can challenge the preferred interpretation. This does not require a dashboard with dozens of measures. A small diagnostic study or review of unresolved cases can be more useful than another aggregate count. Preserve the reasoning so a later team understands why less engagement may be desirable.
HEART Framework companion worksheet
The original two page companion connects a goal, selected HEART categories, signals, metric definitions, data checks and review decisions. The second page examines intention, alternative explanations and missing cases. It supports measurement design and interpretation; it is not an analytics dashboard or an automatic HEART score.
Practical tips
Choose categories according to the product’s purpose.
Document event meaning and the eligible population.
Use one useful countercheck for a consequential metric.
Common mistakes
Adding a measure for every category regardless of relevance.
Treating an event count as direct evidence of a completed need.
Combining unrelated measures into an unexplained overall HEART score.
What you’ll get
A compact measurement plan that connects a product decision to observable experience. Review its evidence and limitations before deciding whether to continue, revise or investigate. If the data cannot distinguish success from a harmful alternative explanation, improve the measurement before celebrating the result.