I ❤️ Requirements Gathering: The HEART Approach

Welcome back to the final installment of my blog series on Requirements Gathering. In this series, I’ve explored the Grammarian’s approach, the Fire Hydrant approach, and the Customer Journey approach. Today, we’ll explore the HEART approach.

Back in 2015, quantitative UX (User Experience) researchers at Google developed this methodology. Their original research was visualized on Dtelepathy.com in a wonderful post, “How to Choose the Right Metrics for Your Product” and has been summarized here by E-Nor.

What is HEART?

• Happiness: How happy is the user with the product? This is typically gathered from surveys or in-product feedback.
• Engagement: How engaged is the user? This may be determined via time on site, bounce rate, or visit frequency.
• Adoption: How much is the feature usage spreading to new users?
• Retention: How much are existing users returning to use the feature?
• Task Success: How well or often are the key tasks associated with your feature being used?

Goals, Signals, and Metrics are then mapped to each letter of the Framework.

Key Questions to Ask

1. What type of project are you trying to measure?

Although this framework was developed for UX researchers, you don’t need to be in the business of user experience to find value in it. It’s ideal for websites, apps, and other arenas where users engage with your business. You could be measuring the success of a booth at a trade show or the success of your newest mobile app. When using it, it’s helpful to think of what you are measuring as a “product” users are engaging with.

This framework can be used for a whole product or a component of a product. If you are launching a large site or complex mobile app, it may make sense to have an overarching measurement framework for the product as a whole and then smaller ones for individual components. Always start with your top-level goals, though, as those should trickle from the top-down.

2. What are you trying to accomplish?

Start by identifying your Goals, or what each component of the project needs to accomplish in order to be successful. This is similar to the Grammarian’s approach post in this series.

For example, you are an Analytics Manager working on a Content App for a major news publication. The app has both free and premium content. One of the Engagement goals is to drive more Premium content consumption.

3. How will you evaluate the sucess of your goals?

Next, identify your Signals. These are the factors which contribute to the success or failure of a goal. For an individual goal, you likely have multiple teams with input on its signals. A good way to approach this is starting with all the possible signals and narrowing them down, keeping your goal top of mind.

With the Engagement goal, a signal could be your Content Recommendation feature. Are users seeing more Premium content in this Recommendation feature than Free content? That would certainly impact their interaction with Premium content.

Also, consider if you can measure what types of content users see in Recommendation engine. You may also realize that an important signal might be difficult to track or isn’t currently tracked. Can you implement tracking for that signal? How critical is that signal to the success of the goal? You may decide to eliminate a few other signals which are less impactful and dedicate your resources to your most essential ones.

4. How will you measure success?

Your Signals should be distilled down into metrics you’ll actually measure. There could be multiple metrics per Signal and that’s OK! But be thoughtful about how you plan on measuring your goals in the long-term.

Metrics associated with the Content Recommendation feature could be the ratio of Free to Premium Impressions and the clickthrough rate of Free vs Premium Content.

Pro and Cons of the HEART Framework

• Pros
  • Easy to Understand: The acronym makes it easy to comprehend and explain to others.
  • Easy to Scale: The Framework is simple enough that it can be applied to a project’s high-level goals and then applied to individual components.
  • User-Focused: Marketing is becoming more user-centric and it’s sensible to start approaching requirements-gathering from the perspective of the user.
• Cons
  • Naturally Geared to UX Projects: While this framework is adaptable to non-UX or non-design projects, it might not feel like a natural fit to businesses with very different needs.

I’m currently working on a Mobile App Analytics project and will be using aspects of this framework in my requirements gathering.

As in all the methods I’ve explored in this series, I encourage you to take what works for you and leave what doesn’t. While “Task Adoption” may not be something relevant to you, “Happiness” and “Engagement” could be your bread-and-butter.

If you enjoyed this post/series or have questions, connect with me on Twitter at @caitlinmariemcc or via email at caitlin@e-nor.com.

Continue Reading the posts in this series:

1. A Grammarian’s Guide to Digital Analytics Requirements Gathering
2. Track All the Things: The Fire Hydrant Approach to Requirements Gathering
3. Follow the Yellow Brick Road: Requirements Gathering with Customer Journey Mapping