Usability Heuristics in Critical Systems — #2 Matching Systems With the Real World

Maria Meireles
UxD Critical Software
5 min readMar 31, 2021

In the first article about Jakob Nielsen’s heuristic and critical systems, we talked about system status visibility — the importance of informing users about what is happening to empower their decision-making process.

This time, we will focus on the second heuristic, matching the system with the real world, explaining this using an example from the medical devices industry.

#2 Matching the System With the Real World

Systems shouldn’t use their own terms but rather communicate in the user’s language. Communicate with familiar concepts, words and expressions adapted to your user, in a natural and logical order, following real-world conventions.

Users feel comfortable with your system; we humans are most comfortable with what is familiar to us. If the users do not know or understand what is being communicated, they can become confused and second-guess themselves. This heuristic refers to both language, objects, actions and other real-world conventions.

1. Make sure the language is adjusted to users. Don’t make them look up a word’s definition.
2. Don’t assume your understanding of words matches those of the users.
3. Align UI elements with real-world objects and actions.
3. Do user research to discover the best words to use and uncover users’ mental models of the most important concepts.

Have you ever noticed how some utility apps, like calculators, look like the equivalent object in the real world?

But rather than simply explaining this concept with words, let’s play a game:

Quite simple, no?

The UI elements of digital applications are similar to the equivalent objects in the real world. The user’s interpretation of what a calculator, radio, phone and planner are is based on real-life objects — they carry these mental models with them to the digital world. When designing, we should take advantage of the user’s previous knowledge to enable a more rapid understanding of the digital interface.

Know your users and show you care about them by listening to what they have to say and adapting your system to communicate specifically to them. Show empathy on familiar grounds, and you can build trust — it’s the best path towards a lasting relationship (with users, of course).

Match the critical system with the real world

Unlike the example given above, matching the system with the real world can be a bit more complicated when dealing with critical systems. Let’s take a look at the example of medical devices.

A glucose meter is a medical device used by patients with diabetes or hypoglycemia to perform home blood glucose monitoring. It allows patients to find out the concentration of glucose in their blood simply by extracting a small drop of blood onto a disposable test strip. The result can be seen on a display in mg/dL or mmol/L (depending on the standard unit of measurement in the user’s country).

Example of a glucose meter being used.

The FDA (Food and Drug Administration) issued a recall of glucose meters allowing patients to change units. Why?

Some meters allowed users to choose between units of the measure during setup. It looks like a great product decision — the meters could be sold in countries that used both mg/dL or mmol/L. For instance, the meter could be marketed both in Europe and the USA. It would also be beneficial for patients that travel and visit doctors in different countries. If in Europe, patients set the meter to display in mmol/L; if in the USA, set the meter to display in mg/dL.

The problem is that the units differ by a factor of 18 — patients used to a unit could mistake the two of them and subsequently take incorrect therapy actions.

The other issue faced by these meters was that users would change units of measure by mistake when setting up the meter’s clock (e.g., daylight savings) because both settings could be changed in similar ways. This would happen without patients realising it because the units were not displayed at all times.
Forcing patients who travel to have two glucose meters for two different measure units was a necessary imposition made by the FDA to reduce the probability of error. Currently, a device has to be locked into a single unit of measurement.

Medical devices are critical devices regardless of who the user (medical staff, doctor, nurse, patient) is and where (hospital, patient home, care home, emergency transport) it is used. Specific medical words and concepts should always be taken into account. Innovating by focusing on the real-world differences between the units of measurement was in theory a good idea, but it took the user’s knowledge of the differences between these for granted. Just taking into account the conventions and concepts known to the user is not enough — a doctor or nurse could understand the change from mmol/L to mg/dL. Still, even in their case, it can still be easy to read incorrectly if you are used to seeing the same unit of measurement every day.

Final Thoughts

A chronically ill patient knows what they need to do and when to ask for help. It’s a daily task, so they become used to most of the medical language and procedures related to their condition. But this does not mean that they have mastered all the concepts around their condition; they know what they need to know to keep living everyday life (or the closest to it they can) and, on occasions, slightly more so they can adequately deal with emergencies.

We should be aware of the different levels of user knowledge and adapt the terminology used by systems and its features to the user. In this situation, limiting the ability of the glucose meters from switching between different units of measurements was the safest course of action, even if it seems like a retrograde step. Systems, especially critical systems, should be tailored to the user’s comprehension of the procedure: lock the device only to show the glucose level on the patient country’s unit of measurement, avoiding the potentially distressing confusion caused by an incorrect reading.

In critical systems, you can find different sets of technical words, concepts, and graphics. What to write and display on the system’s interface and how to say it and show it is a delicate balance between convention, safety, procedure and user knowledge.

We are building systems to be used by real humans who have real limits on their knowledge of specialist terminology. If we ignore them in this equation, we risk more than just needing to rethink a system. In the realm of medical devices at least, the consequences could be fatal.