How to Effectively Measure UX with Google HEART Framework


Gut feeling is good but data-driven UX design is better. Still, the collectible data can be overwhelming, and the product teams might be working toward conflicting goals. The problem here is not in data since people have more data now than ever before. The whole problem lies in managing that data.

And it’s not that only startups are facing this issue, large enterprises like Google also have to deal with this. So, Google’s UX research team has come up with the Google HEART framework to measure the quality of user experience. The framework is described as a set of user-centered metrics for web applications which can help measure progress towards key goals and product-related decisions.

Fact* Google HEART can be applicable to mobile apps and enterprise software too.

Fact* Google HEART can be applicable to the whole product or a specific feature!

It is a good way of measuring the quality of user experience to get actionable insights. User experience does not only need to be designed well, it should be measured well too.

Image source

Let’s now dive deeper into what Google HEART is and see how it can help you measure UX.

H for Happiness

Happiness is a measure of satisfaction and attitude towards a product or a feature. It gives insights into how people feel about what you offer. You can measure the satisfaction on large scale through conducting user surveys. More specific things to measure here include the user’s satisfaction, net-promoter score (NPS), the perceived ease of use.

One of the simplest scenarios of calculating happiness is conducting a satisfaction survey after a major redesign. NPS surveys can be a really good tool for doing this. An in-product survey can depict the satisfaction level more vividly than a survey conducted through email.

E for Engagement

Engagement measures how much a user interacts with your product in a given timeframe. Some specific things to measure include the regularity and the intensity of use, and the level of interaction over a period of time. Some examples include the number of visits per user per week or the number of videos/photos uploaded per user per day e.g. for a photo editing app.

But note that the right metrics will vary depending on your niche. For example, a QR code scanner app is unlikely to see the same depth of engagement as an email app. But still, scenarios might differ depending on different circumstances.

A for Adoption

By adoption, you measure the number of new users of a product or a feature. For example, at Inapptics, when we successfully added a new feature of creating visual funnels from existing user flows, we started measuring the number of users who ended up using that feature during the next two weeks of its launch.

However, there is a little controversy about this too. Some of you might argue that adoption is not so much related to user experience but rather marketing activity. We agree that a heavy investment in marketing can overcome UX problems. But in the longer-term, a poor user experience is very likely to prevent new users from installing your app or using the new feature since they read reviews and ask their friends. Thus, for adoption, it’s best to combine your UX and marketing efforts.

R for Retention

Making people return is one of the hardest tasks ever. By R, you will be measuring the rate at which your users return. For example, you might be measuring how many of your active users at a given timeframe are still present at some later time. The failure to retain or the so-called churn is another metric you will want to measure. In fact, it’s one of the most heated topics among apps.

Similar to adoption metrics, the retention metric is going to be pretty useful when coming up with a new feature or rolling out a new release.

T for Task success

This one looks like a more technical metric since you will be measuring the time to complete a task or the error rates in a specific task. Some more things to measure will include the time to create a profile or upload a photo e.g. in the case of Instagram.

Now that you know all the categories in Google HEART framework, make sure you choose one or two of them based on your product. But how can you decide which metrics to measure and which ones to skip? Everything starts with Goals. It is one of the GSM (goals, signals, metrics) processes that you need to identify. Also, make sure everyone on the team knows the direction you are moving to.

For example, everyone wants to have a high number of mobile app users. However, they should decide which metric they want to measure: engagement or new users.

The next step in the GSM process is mapping the Goals to Signals. Signals should echo the users’ actions. For example, a failure signal in the Task success category for Instagram can be selecting a photo from the device, adding a filter to it but not publishing it.

And lastly, you can refine the signals into Metrics. In the Instagram task success example, we might implement “users upload images, add filters on them but do not post the images” as “the average number of cases when users upload images, add filters but do not post the images on Instagram.”

Summing up

If you want your product’s design to be backed by large-scale data, Google HEART framework can be the answer. But how to collect the data you need? A good in-app analytics tool such as Inapptics can help you not only gather relevant data but also analyze it in order to get precious user behavior patterns.

Have you tried using HEART to measure UX? Or maybe you have your own methods for doing this? Feel free to add responses below.


Found this post useful? Kindly hit the 👏 button below to show how much you liked this piece of content! :)

Follow Inapptics: Medium | Twitter | Facebook

Originally published at blog.inapptics.com on November 3, 2017.

Read Next: 14 Mobile App KPIs to Take Your App to the Next Level


from Sidebar https://sidebar.io/out?url=https%3A%2F%2Fuxplanet.org%2Fhow-to-effectively-measure-ux-with-google-heart-framework-4a497631d224

Leave a Reply

Your email address will not be published. Required fields are marked *