The HEART Framework: How product teams can make User Experience measurable and actionable

The clearest product decisions I’ve ever helped a team make came from a team with almost no user data.

They worked in B2B, had a relatively small customer base and faced strict security requirements. There was no dashboard to hide behind. And that was exactly why the process worked: when you can’t point to a number, you have to make an argument. The team had to articulate the problem they wanted to solve, how they would recognise an improvement and which uncertainties they were willing to accept. Their assumptions were out in the open because there was nowhere else for them to go.

Around the same time, I worked with teams in the opposite situation. They had conversion rates, active users, session duration, feature usage, drop-off rates and revenue trends. They also had research findings, customer feedback, support data and a growing number of AI-assisted analyses. These teams were never short of information. They were often short of conviction.

This is no irony. It is a pattern I’ve seen repeatedly over the past few months: having more data can create a false sense of certainty. A team may have access to countless numbers and still be unable to answer the central question:

Has our decision actually improved the user experience?

I work closely with product teams as a UX and product researcher. Many of my most important interactions happen where product development meets business leadership. At that intersection, research findings, product data, business goals and strategic priorities all need to come together in a decision the team can stand behind.

What is missing is rarely more data. It is a shared understanding of the outcome a project should create for users, the changes that would indicate progress and the metrics that can help assess it.

That is the gap the HEART framework can help close. Beyond its memorable name, I consider it a powerful tool—especially for teams with plenty of user data that use AI yet still struggle to make confident product decisions. Perhaps all the more so. HEART gives structure to the broad concept of user experience and helps teams define more precisely what kind of improvement they want to achieve and measure.

Put simply, it helps product teams assess user experience systematically and connect it to a project’s goals.

Its greatest value lies less in the five categories I’ll outline below and more in the conversations the framework prompts within a team. Good UX metrics begin with clarity about the outcome a product is meant to create for its users. That is often where teams get stuck.

The foundation: five perspectives on user experience

HEART was developed by quantitative UX researchers at Google. The acronym represents five categories:

• Happiness

• Engagement

• Adoption

• Retention

• Task Success

These categories bring structure to the broad concept of user experience and translate it into concrete outcome areas. They help teams consider different dimensions of a product experience before deciding on individual metrics.

Happiness: How do users feel about the product?

Happiness describes users’ attitudes and subjective evaluations. It can include satisfaction, perceived ease of use, trust or how people rate specific parts of a product. This dimension is often measured through surveys, such as short in-product questionnaires or recurring satisfaction surveys.

Happiness is valuable because behavioural data only shows what people do. It rarely tells us reliably how they evaluate an experience or why they behave in a particular way. Someone may use a feature regularly while finding it cumbersome. Another feature may be used only rarely, yet provide significant value at a crucial moment.

Product teams should therefore define which aspect of the experience they want to assess. A general satisfaction question usually offers less direction for action than a specific question about clarity, trust or a user’s sense of control.

Engagement: How deeply do users interact with the product?

Engagement describes the degree to which people interact with a product. Common signals include the frequency, intensity and depth of use. Depending on the product, engagement might take different forms:

• The number of items users create

• Use of key features

• The frequency of meaningful interactions

• Time spent on a productive activity

• The number of completed sessions

The key question is: Which forms of usage actually represent value? This is a question worth taking time to explore.

More time in a learning platform may indicate deep engagement. In an email product, longer sessions may point to inefficiency or difficulty finding one’s way around. Engagement is highly context-dependent. A high number of interactions only becomes meaningful when the team understands the quality behind them.

Adoption: Are users starting to use the product or feature?

Adoption looks at new users or the first use of a feature. It helps answer questions such as:

• How many people start using the product?

• How quickly do users adopt a new feature?

• Which user groups reach the activation point?

• What proportion of the target audience tries the feature within a defined period?

A registration alone is rarely enough to demonstrate true adoption. Someone may create an account without experiencing the product’s value.

For collaborative document software, adoption might begin when a user creates their first document. On a booking platform, the relevant point might be a serious search, a saved property or a completed booking. Defining the activation point is therefore a strategic decision. It shows which behaviour the team considers the first reliable indication that a user has experienced value.

Retention: Do users come back?

Retention describes how many people continue using a product over time. A cohort analysis is often used to measure it. Users who started within a particular period are grouped together and the team then tracks what proportion of that cohort returns over the following days, weeks or months.

Retention matters because repeat usage can indicate sustained value. The appropriate time interval depends on the product’s natural usage pattern.

A weekly view may make sense for a communication product. A tax platform or travel product may call for longer intervals.

A single retention metric across all users can obscure important differences. New users, experienced power users and occasional users often have different goals. Segmenting the analysis usually gives teams a stronger basis for product decisions.

Task Success: Can users achieve their goals?

Task Success measures the effectiveness and efficiency of key user tasks. It may include:

• Completion rate

• Time on task

• Error rate

• Drop-off rate

• Number of steps required

• The proportion of users who need help

This dimension is particularly responsive to specific design changes. That makes it useful for evaluating redesigns, processes and individual flows. Task Success can be measured through usability testing, product data or large-scale benchmarking studies. When a process is instrumented clearly, the team can analyse the journey from start to finish.

For example, an upload flow could be assessed using events such as:

1. The user starts the upload.

2. They select a file.

3. They confirm their selection.

4. They receive a success message.

These events can be used to calculate completion rates, identify drop-off points and measure time on task.

To make Task Success metrics reliable, the team needs a precise definition of when a task begins, when it is complete and what counts as abandonment.

HEART is a framework for thinking, not a ready-made list of metrics

A common mistake is to choose several metrics for every HEART category straight away and build a large dashboard. Trust me, I know what I’m talking about. The framework has a different purpose: it helps teams counter that tendency by giving them a way to think through which outcomes matter.

The categories are perspectives from which a product can be assessed.

Depending on the project, two categories may be enough. For an enterprise product that employees are required to use, product-wide adoption and retention may tell the team very little. People use the system because their organisation expects them to. In that case, Happiness and Task Success may be far more relevant.

At the feature level, adoption could still provide useful insight: Are employees using the newly released feature? Does it make their work easier? Do they return to it?

The quality of the framework lies in how the team selects and prioritises its focus.

Going further: from goals to signals to meaningful metrics

HEART is most effective when combined with the Goals-Signals-Metrics process.

Many teams begin by discussing metrics. They collect potential KPIs, look through existing analytics dashboards and choose numbers that are already available. This can quickly produce a long list of data points with no clear connection to the product goals. The Goals-Signals-Metrics process reverses that order.

1. Goals: What outcome should the product create for users?

Start with a concrete goal for the user experience.

A goal such as “increase traffic” describes a desired business outcome. To develop useful UX metrics, the team needs a more precise understanding of how the product should improve people’s experience.

For a video-sharing platform, a goal might be:

Users can quickly find content that is relevant to them and find watching it worthwhile.

This goal already points to several possible perspectives. Finding relevant content relates to Task Success. A positive experience might be measured through Happiness. Engaging with the content relates to Engagement.

Defining the goal forces the team to make its assumptions explicit. Product management, engineering, design and research often have different expectations of a redesign. That is normal and part of working together. A product manager may want to make room for new features. Engineering may focus on performance. Design may want to make the information architecture clearer. Research brings the needs and pain points of existing users into the conversation while also taking other stakeholders’ perspectives into account.

A shared goal-setting process brings these perspectives together and creates a basis for later decisions.

2. Signals: How would we recognise success?

Signals describe observable changes in users’ behaviour or attitudes. For the goal of improving search, potential signals might include:

• Users select a result more often.

• They reformulate their search less frequently.

• They reach relevant content faster.

• They rate the quality of the results more highly.

• They abandon the search process less often.

A signal is more concrete than a goal, but it still needs a clear measurement definition.

At this stage, the team should consider how closely each signal responds to the planned change. Redesigning search results may have little effect on overall product usage. Clicks on relevant results, search reformulations and abandoned searches are more directly connected.

Each signal also needs to be validated. A higher value should genuinely correspond to a better user experience. More clicks on search results could also mean that users have to open several irrelevant results before finding what they need. Combining different data sources is often necessary to build a reliable picture.

3. Metrics: How exactly will we measure the signal?

In the final step, the signal is translated into a precise metric. The signal “users select a relevant search result” could become:

The proportion of search queries for which a user opens a result within 30 seconds and does not start another search on the same topic.

This definition involves several operational decisions:

• Which users are included?

• Which event counts as a selection?

• What time period is relevant?

• How are repeated searches treated?

• How is relevance estimated?

• Which segments should be analysed separately?

Only with this level of precision does an idea become a metric that can be used in a dashboard, long-term measurement or A/B test.

Good UX metrics lead to better decisions

In my work, I rarely start by asking which KPIs a team should track. I start with the decision the team will eventually need to make.

• Should the new navigation be rolled out?

• Should onboarding be simplified further?

• Should a feature be expanded, changed or discontinued?

• Which user group benefits from the change?

A good metric provides direction for a specific decision. It helps a team distinguish between different explanations and reduce uncertainty in a focused way. That usually takes more than one perspective. A primary outcome metric can create focus, while supporting metrics help with monitoring and diagnosis.

For example, an onboarding redesign might increase the activation rate. At the same time, the team should check whether later retention, perceived clarity and support requests remain stable. This can reveal local improvements that create problems elsewhere.

Common mistakes when applying HEART

1. The team gets involved too late

UX metrics are more valuable when a team develops them together. When one person creates the entire model and then presents the finished result, the rest of the team may not feel ownership—and, unfortunately, that is often what happens.

Collaborative workshops improve the quality of the ideas and help the team take ownership. Team members understand how the metrics were developed, which assumptions sit behind them and how to interpret future results. This involvement becomes especially important when the data shows unexpected or negative developments.

2. The initiative starts at the organisational level

An organisation-wide HEART dashboard can sound appealing. In practice, products, user groups and usage contexts differ so much that a single model can quickly lose its meaning.

A better starting point is a specific project and a team that is open to trying the approach. The team can define its goals, signals and measurement criteria carefully. The experience then becomes an internal case study that other teams can learn from.

3. Too many metrics receive equal priority

HEART can generate a lot of ideas. A team could easily define dozens of signals and metrics. But a larger dashboard also takes more effort to interpret. Stakeholders may select individual numbers to support their own views, relationships between metrics get lost and maintaining the dashboard becomes a burden.

Prioritisation is therefore central to the method. A product team needs a small number of key metrics that are closely connected to its most important goals. Other metrics can remain available for deeper analysis.

4. A single metric becomes the optimisation target

Organisations often look for one central number to guide them. Once that number becomes the sole target, the system starts optimising for its increase. This is a classic example of Goodhart’s law: a measure loses its value when people begin to optimise directly for it.

For example, a metric such as “time spent in the product” could encourage designs that keep people’s attention for longer—even when users would prefer to complete their task more quickly.

Central metrics therefore need supporting guardrails and regular checks to make sure they still represent what the team intends to measure.

5. Ethical consequences are left out of the discussion

UX metrics are approximations of people’s actual experiences. Longer usage may indicate engagement. It may also point to problematic or compulsive use. Especially for social platforms, media products and AI systems, teams should discuss what kinds of usage they want to encourage—and where they should draw the line.

Qualitative research plays an important role here. Interviews, diary studies—my favourite and, in my view, an underestimated method—and open-ended surveys help us understand how a product affects people’s everyday lives. These insights give quantitative signals meaning. And making sense of data is exactly what I think is increasingly missing today.

HEART as a tool for better decisions

The HEART framework is often presented as a set of UX metrics. If you have read this far, you may agree that this view is too narrow. Its real strength lies in creating a structured connection between three things:

• The value a product is meant to create

• The observable signs of that value

• The specific data a team uses to make decisions

Making these connections takes research expertise, product understanding and a shared view of the goals. A standard dashboard can hardly replace that work, however well designed it may be.

Product teams need data. That is a given. But they need more than data. They need a measurement and decision-making system that explains which developments matter, how to interpret them and what decisions might follow.

That is why HEART is a useful framework: it structures the discussion, makes different assumptions visible, connects user experience to product goals and requires teams to clarify what success means for their users before they start measuring it.

Conclusion

Before I finish, I want to emphasise that the HEART framework does not make product decisions for a team. So what does it do?

It improves the foundation on which those decisions are made.

The key point is that the framework requires teams to agree in advance on what success should look like for users. Only then do they choose signals and metrics.

Who should be part of that team? The people who shape the product, evaluate it and will later make decisions based on the results. That usually means product management, UX or product design, research, engineering and data analytics. Depending on the product and project, business, marketing, sales or customer support may also need to be involved.

The goal is not to bring as many people into the room as possible. That wastes resources. The team simply needs four perspectives:

• User needs

• Product strategy

• Business goals

• Technical and analytical feasibility

One more thing: at least one person with decision-making authority should be involved. HEART should not be developed by research alone or by management alone. Its greatest value comes from the conversation between them. That is where different ideas of success become visible—before they turn into disagreements about the results months later.

A practical example

Because HEART combined with the Goals-Signals-Metrics process can feel abstract in theory, I’ll finish by applying it to a concrete example: redesigning the homepage of a travel platform.

The homepage in this example serves several purposes. People who already have a specific trip in mind can search by destination, departure airport, dates and travellers. People who are undecided can explore curated deals, types of trips and destinations for inspiration. The page also includes elements intended to build trust, such as tour operators, customer service, recommendations and reviews.

Even this brief description points to the central question: What exactly should the redesign improve?

“The new homepage should convert better” is too vague to serve as a goal. The homepage supports people with very different intentions. Some already know where they want to go. Others have only a budget, a time frame or a rough idea. Still others are looking for inspiration.

The team should first define the decision it wants to make after the redesign:

Does the new homepage help more users find a relevant starting point for planning their trip—and find it faster?

Only then would I select the HEART categories. And I would deliberately avoid treating all five as equally important.

Task Success would be the most important dimension

The homepage’s central goal is to guide users to a suitable next step. For someone with a specific travel plan, that next step might be completing a search with relevant parameters. For someone who is undecided, it might be exploring a relevant trip category, offer or destination.

The signal would be that users choose a suitable path more quickly, backtrack less often and have to restart their search less frequently.

Possible metrics might include:

• The proportion of started searches that are successfully completed

• Time to reach a relevant search result or offer

• Drop-off rate within the search form

• The proportion of users who reach a results or offer page without unnecessary detours

• The number of repeated searches and reformulations

I would analyse users with a specific trip in mind separately from those in the inspiration phase. A combined average could hide the fact that the redesign works very well for one group but makes things harder for the other.

Happiness would help us interpret the behavioural data

Next, I would look at how users perceive the new homepage. The goal would be for them to experience it as clear, relevant and trustworthy. A suitable signal would be that users recognise more quickly where they can start and feel more confident about choosing a path.

This could be measured through a survey after use, using statements such as:

• “The content shown was relevant to my travel plans.”

• “I trusted the offers presented.”

Responses could be recorded on a scale from 1 to 5. The team could then calculate metrics such as:

• Average perceived relevance

• Average rating for ease of navigation

• Average trust rating

• The proportion of users who agree with a statement, rating it 4 or 5

• Changes in these ratings compared with the previous homepage

This dimension matters because behavioural data alone can be ambiguous. Someone might click on an offer quickly because it looks relevant. They might also click quickly because the homepage is confusing and they are trying different paths. Survey responses help the team interpret the observed behaviour.

Engagement would matter only for some users

I would look at Engagement primarily for users who have not chosen a specific trip yet. The goal would be for inspiration to lead to meaningful exploration of relevant offers.

The number of clicks alone would not tell us much. A longer session might also mean that users are struggling to find their way around.

A more meaningful signal would be a qualified interaction. This could include someone exploring an offer in more detail, saving it, comparing options or starting a specific search afterwards.

One possible metric would be the proportion of inspiration sessions that lead to at least one such valuable next action. This would help the team understand whether the homepage is generating genuine interest and moving the planning process forward.

Adoption would be relevant only if there were a new feature

For the overall redesign, I would probably exclude Adoption. It would become relevant if the new homepage introduced a previously unfamiliar entry point, such as an AI travel assistant, a personalised inspiration feature or a new way to search.

The goal could then be for users to experience the feature’s value early. A signal would be that they use it and reach a relevant next step. The metric should go beyond the first click. More meaningful would be the proportion of users who use the new feature to find a relevant offer, save a trip or complete a search.

Retention would not be a primary success metric in this example

I would not treat Retention as a primary metric for this redesign either. People visit travel platforms at irregular intervals. Their return depends heavily on travel plans, prices, seasonality, campaigns and available offers. That makes it difficult to isolate the effect of a single homepage change.

Retention could still be observed over the longer term. For example, the team could look at whether users who found a relevant offer through the new homepage return more often in the following weeks. But for evaluating the redesign itself, this metric would be too far removed from the change in the user experience.

Which metrics would really matter in the end?

For this project, I would keep the measurement model deliberately small. The primary metrics would be:

• Successful use of search

• The proportion of qualified entry points into the inspiration journey

• Time to reach a relevant, predefined next step

I would also measure perceived clarity, relevance and trust—both quantitatively and qualitatively.

Business metrics such as starting a booking or eventual conversion would remain important guardrails. Technical factors such as loading time and reliability should also be considered. They answer different questions from UX metrics, though.

After launch, the team would be in a much stronger position to make a decision.

If clicks increase while users take longer, backtrack more often and report that the page is harder to navigate, there would be little reason to consider the rollout successful. If both user groups reach a relevant next step faster, find the page clearer and maintain stable booking performance further down the journey, the team would have a stronger basis for its decision.

That is where HEART’s value becomes clear. The team is not collecting every metric it could possibly track. It is selecting the perspectives that fit the homepage’s purpose and the product decision at hand.

Template generated with Claude

For me, HEART is ultimately a reminder that good product decisions begin with a shared understanding of what success means. To help you apply the framework with your own team, I’ve created a practical template for you—well, had it created for me. 😉

Get the HEART and Goals-Signals-Metrics template

Enjoy!

Sources

• Boardmix: The HEART Framework

• Chapman, C., & Rodden, K. (2023). Quantitative User Experience Research: Informing Product Decisions by Understanding Users at Scale. Apress.