How to make HEART metrics work in practice

Search for a command to run...

No comments yet. Be the first to comment.
On finding the depth that sets you apart, and earning a reputation along the way

I'm often asked to recommend a tool or vendor for a research project. Over the course of 20+ years doing applied research, I've come to rely on a set of suppliers and software to consider when needed

Iβve recently had discussions with other Quant UXRs about βrigorβ and what it means in our work. Iβve often heard it raised as a question over the years, and this prompted me to compile some thoughts. I propose a stack with 4 levels of how I view βri...

Kelly Moran [Note from Chris: This week I've invited a post from Kelly Moran, a longtime colleague and exceptionally thoughtful and experienced qualitative researcher and anthropologist. Many of us are familiar with the qual/quant "sandwich" that alt...

In the past few months, Iβve had many conversations with senior folks across a variety of MAMANG and similar companies. These are all UXR managers or senior ICs (L5 and up, largely L6-L8 if youβre familiar with those levels). I expected to hear a var...

π I'm happy to be making my first contribution to the Quant UX Blog! I'm Chris's co-author on the Quant UX Research book, and I'm excited to join him in sharing perspectives that complement the book.
I led the early Quant UX Research team at Google, where we came up with the HEART framework to help teams define metrics of user experience. More than a decade ago, I wrote this blog post about UX metrics that introduced HEART to a wider audience outside of Google.
Since then, it has been applied by teams across the tech industry, and has found its way into many introductory resources about user experience and product management, including the popular book Escaping the Build Trap. Those resources generally cover similar ground to my original blog post, and there is little published material about what happens when teams actually apply HEART to real projects.
In this post, I'll go beyond those basic concepts and share some new perspectives on how to apply HEART in practice, based on material from Chapter 7 of the Quantitative UX Research book.
It's divided into four sections:
With this knowledge, you'll have a better chance of helping your team reach a successful implementation of user experience metrics.
HEART helps teams break down the broad concept of "user experience" into more specific, measurable outcomes. It also encourages teams to consider multiple aspects of the user experience when defining metrics, although it does not cover every possible aspect.
The acronym stands for:
Happiness: Measures of user attitudes, often collected via surveys. This might include satisfaction or perceived ease of use.
Engagement: The level of user involvement with a product, typically measured by frequency, intensity, or depth of interaction. For example, the number of visits during a certain time period, or the usage of key features.
Adoption: How many new users start using a product or feature. Making an explicit distinction between new and existing users helps a team to understand growth.
Retention: The rate at which existing users return to the product. This can be thought of as a long-term version of engagement. Some teams focus more specifically on failure to retain, which is known as "churn".
Task success: The efficiency, effectiveness, and error rate of user actions. This category often yields the most useful metrics for UX changes, provided that task-specific data is available.
HEART π has a fun acronym that makes it easy to remember. Teams often get enthusiastic about it and jump straight to brainstorming metric ideas, because they want to get started on building a dashboard.
However, this is very unlikely to lead to a successful outcome. Metrics are not useful unless they are aligned closely with the team's high-level goals... and many teams are surprisingly unclear about what those are, especially in terms of user experience.
The Goals-Signals-Metrics process is designed to help with this problem by encouraging teams to start by thinking at a higher level.
Goals: Using the HEART framework as inspiration, define the overarching objectives for your product or feature. This step involves team discussions to align on priorities and user experience goals, including explicitly addressing the inevitable disagreements. Omit HEART categories that are less relevant to your project.
Signals: For each goal, identify possible signals β ways that success or failure might manifest in user behavior or attitudes. Map the goals to the data that you are (or could be) collecting about user experience. Consider both the ease of tracking these signals and their likely sensitivity to design changes.
Metrics: Develop specific, quantifiable measurements based on the signals. This involves steps like figuring out how to analyze the low-level signals (e.g., using averages or percentages) and deciding on appropriate time periods for aggregation.
By following this process, teams can create meaningful metrics that align closely with their product goals and user experience priorities. To give a simple example, a goal of "make the upload process easier" might map to signals relating to completion of each stage of the process, or, alternatively, to responses to an inline survey question about ease of use. The signal about completion could translate to a specific metric like "the percentage of times a user finishes the upload flow successfully, having started it in the past 7 days".
Two important aspects of the process that I want to emphasize:
You Must Prioritize: Focus on implementing metrics related to your top goals. It's better to have a few well-chosen metrics than an overwhelming dashboard.
You Must Iterate: When you've gone through the process the first time, you are not done. As you collect data and gain insights, be prepared to refine your choices over time.
Certain issues come up over and over again for individual quantitative UX researchers when they try to apply HEART and Goals-Signals-Metrics. I still make some of these mistakes myself!
While it might seem efficient to develop metrics independently, this approach can backfire. Engaging your team throughout the process:
I suggest scheduling a collaborative session to work through the first part of the Goals-Signals-Metrics process with key members of your team: agree on goals, and brainstorm possible signals.
The HEART framework is most useful when applied to specific projects with engaged teams. Avoid the temptation to create organization-wide dashboards immediately. Instead:
HEART and Goals-Signals-Metrics are only the beginning of a long process. Just because you used them to come up with a metric idea, that doesn't mean that it's a good or a useful metric, or that it has any correlation with quality of user experience.
Be prepared for:
Allocate sufficient time and resources for these crucial next steps.
While HEART can help you generate numerous ideas, implementing too many metrics can be counterproductive. To avoid overwhelming your team and other stakeholders:
Every project takes place in context, and different organizations and teams have different challenges that you can attempt to proactively address, or keep in mind when selecting the right projects to apply HEART.
Introducing targeted metrics can expose project shortcomings, which may create anxiety within teams. To address this:
While having too many metrics is problematic, focusing on a single metric is also detrimental, but leaders are often drawn to that in an attempt to create clarity and focus. Chris has a separate post about the problems with "North Star" metrics. Remember:
UX metrics are only proxies for user experiences. No metric of user engagement can actually identify how truly engaged a user is, or whether that engagement represents a positive experience for them. For example, time spent in a product is often used as a default metric of engagement, but this may not be appropriate for a given product, especially if unhealthy overuse is a possibility.
When implementing metrics:
HEART is a useful tool to help teams focus on the user experience when defining metrics. Here's a summary of the main things to keep in mind when applying it in practice:
For more detail on all of this, and a case study of a Gmail project, see Chapter 7 of the Quantitative UX Research book. I'm also available for consulting or speaking on these topics π
Have you applied HEART with your team? If you have, I encourage you to write about your experiences, so that the rest of the community can build on what you've learned.