Home > UX and Prototyping > How to use the Google HEART framework to design better for users
Why the Google HEART framework is the ideal tool for making your design user-centered, with a little help from interactive prototypes

Why the Google HEART framework is the ideal tool for making your design user-centered, with a little help from interactive prototypes

Everyone knows that data-driven UX design is better than designing and developing on user experience gut feeling.

But collecting, analyzing and applying metrics relevant to user experience is easier said than done: the volume of collectible data can be overwhelming, standard analytics can be too generic to have any meaningful application to your product or feature, and product teams may be working toward confused or even conflicting goals.

We have access to more data than ever, but that doesn’t make managing that data any easier.

It’s not just smaller enterprises and UXers who come up against these problems; even Google’s UX research team, faced with growing quantities of large-scale behavioral data, found they needed to formalize their user experience research metrics collection and synthesis. That’s when they came up with the Google HEART framework, a process that incorporates user-centered metrics in web apps “to measure progress towards key goals, and drive product decisions.”

Not solely applicable to web apps, the Google HEART framework can be applied to websites, mobile apps and enterprise software. It’s a way to measure user experience quality and get actionable data from those measurements, which then feeds into goal-oriented activities. 

In this post, we’ll take a closer look at the Google HEART framework, and how it fits in with collecting UX metrics at the prototyping stage of web or mobile app development.

The Google HEART framework: an introduction to UX metrics

Image credit: IDF

Test the Google HEART framework with Justinmind interactive prototypes

Download free

The Google HEART framework is the brainchild of Google’s UX research team, who noticed that their suggestions for useful product metrics all fell into one of five categories. Putting these categories together they came up with the acronym HEART, a comprehensive structure for organizing user experience related data.

H – Happiness: qualitative user experience measurements, such as satisfaction and ease-of-use

E – Engagement: frequency, intensity, or depth of interaction over a given timeframe

A – Adoption: how many new users a product, or an updated feature, gets in a defined time period

R – Retention: how many users stick around and how many start to churn

T – Task success: what Google defines as “traditional behavioral metrics of user experience”, like time to task-completion, error rate etc.

Whether applied to the design of an entire product or to an individual feature, the HEART metrics help product teams figure out which metrics they need to collect. What they then do with these metrics is covered by the next stage of Google’s UX metrics framework, Goals-Signals-Metrics.

Goals-Signals-Metrics in the Google HEART framework

As the Google UX Research team point out in their in-depth paper on the Google HEART framework, “no matter how user-centered a metric is, it is unlikely to be useful in practice unless it explicitly relates to a goal, and can be used to track progress towards that goal.” That’s why they came up with Goals-Signals-Metrics, a process that helps product teams voice their goals around a product or feature, and use ‘signals’ to track progress those goals.

Goals: identifying the UX goals of a product or feature can be complicated. Brainstorming around the Google HEART framework can unite the team towards one common goal, and weed out the project goals from the product goals.

Signals: kind of like UX KPIs, ‘signals’ are the user behavior signposts might help a team track progress towards goals? Actions that indicate a goal has been met, or feelings that correlate to success or failure, should be mapped out here.

Metrics: how will signals manifest as metrics? This is where baggy data gets turned into statistics, which can then be compared against industry or product standards.

How to use prototypes to collect UX metrics with the Google HEART framework

Image credit: UsabilityGeek

According to IEEE’s seminal report Why Software Fails, an estimated 50% of rework time could have been avoided had testing been done in the early design stages: this doesn’t just apply to functional and system testing, but also to user experience testing. The earlier UX metrics are collected and mapped to goals, the less likelihood there is of last-minute reworks. High fidelity prototypes provide UX research teams with an early opportunity to check the UX impact of design decisions before moving on to code.

“It can be up to 100 times more expensive to change a coded feature than a prototype,” Web Usability

Using a prototyping tool powerful enough to create interactive wireframes quickly and flexibly means many of the Google HEART framework metrics can be collected before any code is written. With Justinmind, teams can build interactive and OS-specific UI prototypes that are so realistic that UX metrics can actually be harvested prior to coding. These prototypes are built in a fraction of the time and at little cost. Here’s how:

  1. Download Justinmind and then create a new prototype. You can choose from a wide selection of desktop and mobile prototype templates, and even customize your canvas size.
  2. Build your prototype with the content confirmed earlier in your design process. You can drag and drop UI elements to the canvas from our widget libraries.
  3. Then, use Justinmind’s Events system to build out the interaction in your web or mobile prototype.
  4. Add conditions and variables and data masters, lists and grids to make your prototype as realistic as possible. You can even import real data into your design.
  5. Once you’re finished designing your prototype, it’s time to test it. You can do so directly from Justinmind – learn more here.

Most prototyping platforms are integrated with a range of usability testing tools (check out Justinmind’s integrations here), which mean UX and usability tests can be organized and run externally, with data then being fed back to the team.

A HEART-based brainstorm should be held before testing, to define what exactly is going to be measured: a prototype can then be built with test-adequate features.

Basics such as scenario simulation in browsers and test-on-device capabilities are must-haves; with more powerful prototyping tools you can also build actual data into a prototype, allowing users to really experience the end-product.

Of course, collecting Google HEART framework metrics from prototypes is similar but not identical to collecting UX metrics from final products.

UX researchers harvesting data from prototypes have to be aware of how prototype-specific factors might have had an impact on results. For example, including lorem ipsum placeholder text in your prototype might hinder users’ navigation abilities; a provisional color scheme may be less intuitive than the final design. And it may not be possible to collect data over long periods of time, such as engagement metrics.

Check out this UsabilityGeek post on usability testing with prototypes for more in-depth ideas.

Top tips for collecting Google HEART framework metrics from prototypes

  • Use realistic data, and drop the Disney character email addresses and celebrity usernames
  • Utilize user surveys to collect qualitative metrics
  • Agree on product/feature goals before starting to collect metrics
  • Track negative metrics as well as positive. You can learn more from user failures than you can from seamless task completions more often than not.

Cassandra is Marketing Lead at Justinmind

Add comment

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