Usability Heuristics
Match Between System and the Real World
Speak the user's language — use familiar words and conventions, not internal jargon.
Where it comes from
It's the second of Jakob Nielsen's ten usability heuristics, distilled from years of evaluating interfaces. The principle: a system should speak the user's language, using words, phrases, and concepts familiar to them rather than internal jargon.
Why it matters for your website
Your interface should speak your visitor's language, not yours. Nielsen Norman Group's second heuristic says words, phrases, and concepts should match the real world. When they don't, users have to translate — and translation costs attention and trust.
Every internal term you expose is a translation you've outsourced to the visitor. When a label uses your company's vocabulary instead of the user's — 'utilise our provisioning portal' rather than 'set up your account' — the user has to decode it, and decoding costs attention and quietly signals that the product wasn't built with them in mind.
Matching the real world goes beyond words to concepts and conventions: ordering things the way users expect, using metaphors they recognise, presenting information in a familiar sequence. The closer the interface sits to the user's existing world, the less translation it demands.
Wrong vs right
Navigation and labels built from internal jargon ('Provisioning', 'Entities', 'Resources') that mean nothing to the visitor.
Labels in the user's own language ('Your account', 'Billing', 'Help') that need no translation.
Error messages full of technical or system terms the user has to decode.
Messages in plain, real-world language that say what happened and what to do.
Presenting concepts in the system's internal order rather than the order the user expects.
Following familiar conventions and sequences, so the interface matches the user's mental model.
Understanding Match Between System and the Real World
Match between system and the real world is the second of Jakob Nielsen's ten usability heuristics. It holds that an interface should speak the user's language — using words, phrases, and concepts the user already knows — rather than the internal vocabulary of the people who built it. The goal is to make information appear in a natural, familiar order.
The cost of failing it is a hidden tax of translation. Every time a label, message, or concept uses internal jargon, the user has to convert it into terms they understand before they can act — and that conversion costs attention, slows them down, and subtly signals that the product wasn't designed around them. Familiar language, by contrast, is understood instantly.
Matching the real world extends past vocabulary to conventions and concepts: presenting things in an expected order, using recognisable metaphors, and following the patterns users bring from elsewhere. The closer the interface sits to the user's existing world, the less translation it demands — and translation is exactly the friction this heuristic removes. It connects to mental models, Jakob's Law, and plain language.
How Kweri checks it
Kweri can flag some likely violations it can recognise — internal jargon in labels and navigation, technical terms in user-facing messages, and concepts presented in system rather than user terms — and prompt you toward the user's own language. What it can't always know is which vocabulary your specific audience actually uses, since 'the user's language' depends on who they are. So Kweri surfaces probable jargon and system-centric wording, and prompts you to match your audience's real-world terms, while confirming the right vocabulary is a matter of knowing your users.
FAQ
What does 'match between system and the real world' mean?
It's Jakob Nielsen's second usability heuristic: an interface should speak the user's language — familiar words, phrases, and concepts — and present information in a natural, real-world order, rather than using internal jargon or system-centric terms.
Why is using the user's language important?
Because internal jargon forces users to translate your terms into ones they understand before they can act. That translation costs attention, slows them down, and signals the product wasn't built around them. Familiar language is understood instantly.
What's an example of violating this heuristic?
Labelling navigation with internal terms like 'Provisioning' or 'Entities', writing error messages full of technical jargon, or presenting concepts in the system's order rather than the user's expected order — anything that makes the user decode your vocabulary.
How do I match the real world in design?
Use the words and concepts your users already know, follow familiar conventions and ordering, and use recognisable metaphors. Replace internal jargon in labels, messages, and navigation with the user's own language.
How is this related to plain language?
They're closely linked. Plain language is about clarity and simplicity; matching the real world is specifically about using the user's familiar vocabulary and conventions. Both reduce the effort between the user and understanding.
Related principles
Users arrive with expectations from past experience — break those without reason and you cause confusion.
Users spend most of their time on other sites, so they expect yours to work the same way.
Plain, direct language is understood faster and trusted more — jargon and complexity are barriers.
Good design externalises the knowledge users need to act — it puts it in the world, not in their heads. A product that requires memorisation is a product that requires training.
Attribution & sources
Identified by Jakob Nielsen (1994). Catalogued from Nielsen Norman Group — Match Between System and the Real World.
The second of Nielsen's 10 Usability Heuristics; the linked article is the reference used here.
See Match Between System and the Real World on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →