Twenty-two years ago, design legend Jakob Nielsen published 10 Heuristics for User Interface Design. These ten tips are just as relevant now as they were in the early days of the internet.
I consider them my ten commandments when it comes to designing software. In fact, this was the one and only thing that I displayed on my cubicle wall at my previous job.
Anyway, the second heuristic on the list is:
Match between system and the real world
The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
In other words, you want to make your product come as close as possible to the mental models of your users. In a perfect world, all products would closely align with how customers actually think.
Unfortunately, it’s not a perfect world.
In reality, there’s always a gap between how the product represents things compared to how the user actually thinks about them.
Actually, it’s often quite a large gap.
At my previous job, an established financial software company, the RTFM test revealed a feature that caused a lot of support requests: user access control. After speaking with some customers, we noticed that they were using different words than we were. What the system referred to as Access Areas, they called Functions. Also, the interface for user access control wasn’t consistent with the rest of the system. Our customers were used to using Excel-like tables to configure and view things, but this feature had a series of listboxes and dropdowns that were much less familiar or flexible. For this feature, there was definitely a gap between our product and the mental models of our users.
The Match Debt
Having this gap is not a huge problem (users tend to “satisfice“, settling for “good enough” solutions instead of fully understanding all options), but it is a cost. A cost that shows up in customer support, bug fixes, and worse: lost sales. I call that cost the Match Debt, because much like technical debt, the decisions you make today can make future development more expensive, like paying interest on a loan.
For our user access system, the Match Debt showed up most visibly in the form of calls to our support team. It also meant that the feature was hard to maintain. It may also have led to lost sales, though that is much harder to mention.
There are really only two ways to pay off Match Debt.
Educating your users
Firstly, you can try to move the users mental models closer to the way the product works via customer training and documentation- let’s call this education.
Our user access system had thorough, well-written documentation, which I’m sure helped some of our customers, but users don’t read!
Learning about your users
Alternatively, you can try to move the product’s design closer to how the users think. This can be done in many different ways, including researching your users, designing solutions to their problems, testing these solutions, and more. But for simplicity’s sake, let’s just call this User Experience, or UX.
This is what we did when we redesigned the user access system. The new design uses slightly more familiar language and presents it in a way that’s consistent with the rest of the product. It’s nowhere near perfect, but now the Match Debt is lower, meaning that we’ll probably have fewer support calls and slightly happier customers than before.
It’s not you, it’s me
Both education and UX do the trick in reducing Match Debt, but from a customer’s perspective, UX is a whole lot nicer because it means that the product is doing the work, as opposed to the customer having to do the work. UX puts the onus on the few people who develop the product instead of the many people who use the product.
UX is the product team telling the user “it’s not you, it’s me”, then actually doing something to fix “it”. Isn’t that the way it should be?
Sure, this is a gross oversimplification, but this is why I love UX so much. It pays off Match Debt by aligning the product (and in fact the whole organization) closer to the users’ mental models.
It’s hard work. But it’s worth it.