Have you ever used software whose user interface had some or all of the following characteristics?
- No clear path for performing a task
- Non-intuitive controls
- Poorly worded, non-descriptive labels
- Unhelpful error messages
- No feedback when you take an action (Is it doing anything, or is it stuck?)
- Data entry fields that allow you to enter invalid data
- Date entry fields that require you to duplicate data entry or enter extraneous data for no good reason
- Poor or nonexistent help
If so, you’re not alone—in fact, if you haven’t encountered such software, you are in a tiny minority.
The software may be fantastic under the covers: Superb object design, optimized for efficient performance, well-commented code—everything a software engineer could ask for. But if the user interface stinks, most people won’t use it unless they have to, and those people will hate it. And you, if you’re the one who designed it, built it, or sold it to them.
The Importance of User Experience
Why is it that even now, some 50 years after the graphical user interface was first conceived, we are still plagued with crummy user interfaces? That should be the easy part, right?
Well, not really.
Much of the effort of building a software application goes into the behind-the-scenes code that makes everything work together. Even a simple, straightforward app might have thousands of lines of code behind a deceptively simple user interface.
The developers who write this code are, as a general rule, truly brilliant. (Yes, we’re a bit biased on this point here at AndPlus.) However, because they spend so much time writing the underlying code, they have a certain mental model of how the software works, and it often doesn’t match up with a user’s mental model.
It’s OK for developers and users to have different mental models of the same software. For example, a user might believe that all the data the report he or she is looking at comes from one table in a database. Chances are good that it’s actually a combination of data from different tables or even different databases, but it doesn’t matter, as long as it works.
The trouble is that if you let a developer design a user interface that’s based on the developer’s understanding of the software, the results may be disastrous because the user doesn’t think in those terms. The user thinks in terms of accomplishing tasks and using software to make those tasks easier.
A related problem is that a developer might leave the design and coding of the user interface for the end of the project after all the underlying code has been developed. This compounds the poor interface design with hasty execution when trying to meet a deadline.
This is why all reputable software shops employ user experience (UX) designers to handle the design of the user interface. A UX designer talks extensively with the end users to understand the tasks they need to accomplish, the pain points they are experiencing, what they need the software to do for them, and their mental model of how it should work.
Armed with this information, the UX designer designs the user interface, and ideally prototypes it for the users to ensure the requirements are captured accurately—all before (or at least in parallel with) actual code writing.
And if the users’ mental model doesn’t match how the software actually works under the covers, it’s the development team’s job to design the system to support the user’s mental model. The development team can’t reasonably expect users to change their mental models for the convenience of the developers.
User interface design is often not easy. In their work, UX designers have to answer questions such as:
- How should controls be arranged to both flow logically and make the best use of limited screen real estate?
- What’s the best way to provide feedback when the user takes an action, especially if the processing will take time to complete?
- How should the interface be designed for different types of users (that is, users trying to accomplish different tasks)?
- How should the interface be designed for users who speak or read in other languages?
- How best to provide help when users make mistakes or go down wrong paths?
…and more. The UX designer must have an intimate understanding of the various user journeys and the tasks and processes the software is intended to support.
Taking UX to HEART
One of the problems with UX design is that the quality of a user interface is difficult to quantify or measure. In particular, it’s hard to relate the quality of the user interface with a dollar value. How does an improvement in the user interface change revenues for the company providing the software? How does it affect costs or productivity for the end users? How much effort can be expended on improving the user interface while still realizing a positive return on the investment?
The good folks at Google set out to solve this problem recently.
What they came up with is a framework of five metrics that they call HEART: Happiness, Engagement, Adoption, Retention, and Task Success. (They even published an academic paper about it.)
- Happiness: How do users feel about the product? Do they enjoy using it? Does it help them do things faster/better/more accurately/more efficiently than they could without it? Although an obviously subjective measure, it is easily captured with well-crafted surveys and other feedback mechanisms.
- Engagement: How much are users using the product? How many times during the day do they use the product, and how much time do they spend with it?
- Adoption: There are two facets of adoption: product adoption (what percentage of users who install or sign up for a product actually use it?) and feature adoption (what percentage of existing users start using new features?).
- Retention: How many users continue to use the product after a given time period?
- Task Success: Are users able to use the product for its intended purpose? Do they go down wrong paths or make mistakes when attempting to perform a task? Classic, well-understood usability testing techniques can provide these measures.
The HEART of the Matter
With the HEART framework, Google has formulated an explicit, concrete, consistent, and reproducible method to measure the overall user experience of a software product. In the process, they have shown that UX is more than simply product usability: There are other, measurable aspects of UX that provide a holistic picture of why and how a product is succeeding (or failing) in the marketplace.
By adopting the HEART framework, a software development organization can realize some important benefits, including:
- A more complete picture. Having multiple dimensions of metrics provides a richer, fuller view of where and how a product can be improved. For example, a product that has high adoption but low retention indicates a different problem from one that has low adoption but high retention.
- Focused enhancement strategies. The different measures also show development teams where to focus their efforts in future versions of the product. If a product has high engagement, the team shouldn’t spend time improving the engagement score, but rather should focus on enhancements that can improve other metrics.
- Predictable return on investment. By analyzing historical data from these metrics, development teams can predict where they will get the most bang for their development buck. If an investment in raising adoption consistently brings in more revenue than the same investment in raising retention, you have an idea of what to focus on if both scores are low.
Fixing a low score does not necessarily require a large effort. This analysis of Google’s use of HEART in their own products shows that something as simple as a pop-up notification of a new feature or a “guided tour” of how to get started with a new product can enhance a product’s UX.
The Gift of HEART
HEART is a powerful new tool for both software development and software product management. Its concrete, multidimensional data provides much greater insight on a product’s performance in the marketplace, not only showing where to focus development efforts but also suggesting that further efforts may not be worth it and that it’s time to pull the plug on a product.
In short, it gives software providers solid data on which to make decisions, largely eliminating guesswork and personal preferences from the decision process.
Although they developed the HEART framework to help evaluate and enhance UX for their own products, Google was kind enough to share it with the world, and we at AndPlus are actively adopting it into our own work. We are eager to see how well it helps us and our clients evaluate software UX and make good decisions on future software product directions.