HEART Framework
HEART groups user-centered measurements into Happiness, Engagement, Adoption, Retention, and Task success. Kerry Rodden, Hilary Hutchinson, and Xin Fu proposed it at Google in 2010, alongside a goals–signals–metrics process for choosing measures. It complements the business and technical metrics they called PULSE: page views, uptime, latency, seven-day active users, and earnings. Those measures remain useful, but their meaning for experience can be ambiguous; more page views might reflect interest or difficulty navigating. HEART supplies categories for selecting evidence, not a fixed score or a requirement to use every category.
The five categories
Happiness concerns reported attitudes, including satisfaction, perceived ease, and willingness to recommend. Engagement concerns involvement, which may be reflected in frequency, intensity, or depth of use during a period.
Expected use at work can make overall engagement less informative, while optional feature-level use may still be meaningful.
Adoption tracks new users starting use; retention follows users from an earlier cohort into a later period. Define the event that counts as use and choose periods suited to the task.
Task success concerns effectiveness, efficiency, and errors. Successful completion without troubleshooting support can be a task-success or independence measure rather than a substitute definition of engagement.
| Category | On an internal platform | Example metric |
|---|---|---|
| Happiness | Reported experience of a specified task or capability | Versioned survey score with population and response counts; separately identified success, failure and support samples |
| Engagement | Meaningful involvement with a capability | Frequency or depth of relevant use per eligible user or team; interpret against task needs and available choices |
| Adoption | Teams beginning use during a period | First-time users among teams eligible but not yet users at quarter start; report the cohort and new arrivals separately |
| Retention | Continued use by a prior cohort | Teams active last quarter that meet the stated use criterion this quarter, divided by last quarter’s active teams; report dissolution, infrequent tasks and missing observations |
| Task success | Completion, effort, elapsed time and errors for a defined task | Verified database readiness or successful incident diagnosis within a stated window; separate ordinary approvals from troubleshooting assistance |
DORA’s platform guidance recommends HEART for new-team adoption and continuing use alongside other platform measures. Keep these distinct from current coverage. With 100 eligible teams, 50 active last quarter, 25 of those retained and 25 new active teams, current coverage remains 50%, retention is 50%, and new users are 25% of all eligible teams. If the other 50 teams had never used the capability and were eligible at quarter start, their new-adoption rate is 25/50, or 50%. State the denominator rather than calling all of these adoption. Mandatory use still counts as use but does not establish preference. Retiring a workaround can be contextual evidence; it is not the definition of retention.
Goals, signals, metrics
Start with the user’s goal, identify behavior or attitudes that could support or contradict it, and then specify metrics. Consider the coverage and accuracy of logs and surveys before relying on the signal. For a database journey, a proposed goal might be verified readiness without troubleshooting support. Define eligibility and valid request submission, readiness checks, and an observation window. Count successful completion within that window without ticket, chat, or direct guidance; track approvals separately rather than treating every human step as help. Failed, abandoned, still-open and unobserved requests need explicit treatment. No follow-up question is not proof of success. Full automation, if desired, is a separate measure.
For example, all 100 completed tasks might succeed while 20 require only routine approval and 10 different tasks require troubleshooting. The share completed without troubleshooting is 90%, while the share with no staff intervention beyond the user’s request is 70%. This example assumes disjoint groups, no other staff intervention, and complete observations; it is not a claim about a real platform. A survey or completion measure should also include the relevant unsuccessful or unfinished population when its purpose requires that view, instead of quietly conditioning on completion.
Ratios and per-user averages can reduce the effect of population growth, but not changing composition. With unchanged success rates of 20% and 80% in two task groups, 490 and 110 attempts produce 186 successes out of 600, or 31%. A later mix of 120 and 480 produces 408, or 68%. Neither task group improved. Compare definitions, workloads, populations, observation windows, and missing data; inspect within-group trends before interpreting the aggregate.
The HEART authors treat metrics as complements to research, not substitutes for early discovery or usability studies. A metric directly measures a defined quantity, such as verified task completion, but becomes a proxy metric when used to stand in for a broader outcome such as productivity. State and test that relationship. Happiness uses perceptual measures: stable wording helps trends, but response composition, recall periods, and context matter too. Version necessary question changes and validate continuity or establish a new reference. Twenty-Three of Twenty-Five Shipped applies these ideas to roadmap decisions, with separate attention to operating cost and causal attribution.
References:
- Kerry Rodden, Hilary Hutchinson, and Xin Fu, Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications, CHI 2010, author’s version.
- DORA, Capabilities: Platform engineering (Creative Commons Attribution 4.0).
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.