Analytics tools are primarily designed for data/business professionals who may want an overview of the data. UX researchers or Designers, who may want specific knowledge of a few metrics, are often secondary or tertiary users. But the flipside of this is that for UX professionals, metrics are most often either a way to expand upon research questions or as a way to translate research findings for stakeholders.

As a result, you often don’t need to know everything about metrics.

Sometimes, you need to understand one question: Which metrics should UX prioritize for this project?

Last week, I talked about how engagement metrics are what UX probably cares about. But those are not the only ones you might use. To figure this out, here’s a framework you can use to choose the right UX Metrics. And it begins with HEART.

Understanding the Heart Framework

https://library.gv.com/how-to-choose-the-right-ux-metrics-for-your-product-5f46359ab5be

The Heart framework was developed by Quantitative UX Researchers at Google while helping product teams define what UX Metrics they wanted to follow. It’s based on five of the most common categories of suggestions teams suggested:

• Happiness: these are measures of users' attitudes, usually collected through surveys. For example, satisfaction, Net-promoter score, perceived ease of use.
• Engagement: Amount of user involvement, which is typically measured through behavioral UX data involving frequency, intensity, or depth of interaction over a time period. We might see represented in Google Analytics as the number of repeat visits, time on page, or the number of photos uploaded per user on a single day.
• Adoption: The number of new users of a product or feature. For example, the number of accounts created in the last seven days or the percentage of users using our new feature.
• Retention: The rate of existing users that are returning. For example, how many active users from a given time period are still present later on? Sometimes, the more interesting example is failure to retain, otherwise known as “churn.”
• Task success: These are the traditional behavioral metrics of UX, such as efficiency, effectiveness, and error rate. This typically applies to areas of your product that are very task-focused, such as searching for something or uploading a document.

Some of these metrics should seem familiar to UX, but these are still somewhat broad categories of metrics to consider. But the good news is that you don’t have to apply the entire framework to every project: you have to figure out which metrics you should prioritize.

So how would you prioritize them?

That’s where Goals, Signals, and Metrics come into play.

Goals, Signals, and Metrics

Defining the Goals, Signals, and Metrics is a discussion of what you should do with the rest of the team: it allows establishing common ground on what matters and how you would define success. To do that, we need to start from the beginning: going through Goals, then Signals, then finally defining our metrics.

Goals:

Surprisingly, one of the hardest things for a team to do is define the project's goal. One of the most common pitfalls for teams is to jump past thinking about your goals straight to defining your goal with existing metrics. For example, “we want to increase traffic to our site.”

There are a dozen ways to do that. Do you want to retain existing users? Make certain tasks easier to do? Draw in new users? Defining the overall goal of the project is helping to prioritize which metrics to use. Because no matter what, almost all design decisions have trade-offs, especially when it comes to metrics. And once you define goals, you can talk about the next part: Signals.

Signals

Signals can signal success or failure for your goal, and thinking about the signals helps to bring into focus how easy or hard some goals are to track. If you wanted to have increased engagement on a website, you might use signals such as how much time users spend on a page, but also how many interactions they have, how many leave before completing tasks, or what the typical user’s journey through a site might be.

However, some of these signals will be worse than others for three major reasons.

The first is that some of these signals will be hard to track or accomplish: if you wanted to track your user’s journey through a website, you could look at quantitative metrics such as Google Analytics’ Behavioral flow maps, but it would likely also involve running user interviews on an existing user workflow or some other things.

The second reason is that some of these signals may be hard to define in terms of success or failure: having more interactions on a website without defining their interactions results in issues.

Is it a success if you’ve doubled the number of interactions (but also made it so that the users had to click on everything twice)?

The last reason is that some signals don’t lend themselves well to being sensitive to design changes. For example, time on the page would probably be a poor signal to measure your UX design against. Many changes in the design might make no difference to the time spent (or sometimes good changes, like combining two pages, might actually increase the time spent). Once we finish thinking about Goals and Signals, we’ve cut down a lot of the possible Metrics we might consider into quantitative ways to track everything.

Some of the most common metrics to be concerned about tending to exist within common Analytics programs such as Google Analytics, but it could be that there are metrics that you want to explore that you will need to figure out. If, for example, you wanted to use a different customer-facing metric other than more popular ones such as Net Promoter Score or CSAT, you might have to figure out how you’re going to track things.

But this allows you to make sense of metrics in a way that can add value to your projects. And it’s only then, when you’ve decided your Goals, Signals, and Metrics, that you should take a look at Google Analytics. When you do that, it should be much easier to find what you’re looking for.

The value of metrics

One of the key things about metrics is that they allow us to answer a basic question: How can we know that a project is successful?

If we have the resources, we could perhaps follow up with user interviews with key users and stakeholders a few months later to see if they liked it. But metrics are often a way of defining success or failure, especially when they’ve been established ahead of time. And one of the most powerful things that you can experience is whether the project succeeded and whether or not your re-design improved UX.

Being able to point to a chosen UX metric and show how it improved can provide you with proof that you’ve succeeded in making your user’s lives better. This can yield a sense of satisfaction or provide evidence that you can leverage to improve the UX maturity of your organization.

So if you’ve ever felt overwhelmed by metrics, take a step back and realize that you don’t have to know everything there.

You have to know what you’re looking for.

Kai Wong is a UX Designer, Author, and Data Visualization advocate. His latest book, Data Persuasion, talks about learning Data Visualization from a Designer’s perspective and how UX can benefit Data Visualization.

The UX Collective donates US$1 for each article we publish. This story contributed to World-Class Designer School: a college-level, tuition-free design school focused on preparing young and talented African designers for the local and international digital product market. Build the design community you believe in.