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.
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:
…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.
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.)
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:
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.
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.