Why your app shouldn't speak your industry's language.

Design · 6 min read

Every industry has its own language. Acronyms, shorthand, technical terms that insiders use without thinking. When you've been in your field for ten or fifteen years, that language becomes invisible to you. You don't even notice you're using it. But your app's users might not be insiders. And even the ones who are might not process jargon the way you expect when they're trying to complete a task quickly on a phone screen.

This is one of the most common design problems I see, and one of the easiest to fix once you're aware of it.

The research is clear: plain language works better

The Nielsen Norman Group, the most respected usability research organisation in the world, has consistently found that using plain, simple language improves usability. Their research shows that simplifying content can improve task completion rates by over 124%. People find what they need faster, make fewer errors, and report higher satisfaction.

A 2024 systematic review published in the Journal of Clinical Epidemiology found that plain language summaries improved comprehension by an average of 19.8% compared to technical versions. And this was in healthcare, where the audience often has some familiarity with medical terminology. In less specialised contexts, the gap is even wider.

This isn't about dumbing things down. It's about removing barriers between your user and the thing they're trying to do.

Your users are not you

This is the fundamental trap. As a subject matter expert, you're the best person to understand the problem your app solves. But that deep expertise also means you have a vocabulary that your users might not share.

I worked on a project in the NDIS space where the internal team used terms like "service agreement," "plan management," and "support coordination" constantly. These are standard NDIS terminology. But the primary users of the app, participants and their families, often didn't know what those terms meant in practice. They knew what they needed to do, they just didn't recognise the labels being used for it.

When we replaced "service agreement" with "your plan details" and "support coordination" with "your support team," task completion rates improved noticeably. Same functionality. Different words. Better outcomes.

Jargon creates cognitive load

Every time a user encounters a term they don't immediately understand, their brain has to work harder. That's cognitive load, and it's the enemy of good user experience. Research in cognitive psychology has long established that reducing extraneous cognitive load, the mental effort spent on things that aren't directly related to the task, improves learning and performance.

In an app context, every moment a user spends decoding a label or wondering what a button does is a moment they're not spending on the thing they came to do. Stack up enough of those moments and the user gives up. They close the app, go back to their spreadsheet or their paper system, and you've lost them. Not because your app doesn't work, but because the language got in the way.

Hick's Law tells us that the more choices and complexity we present, the longer people take to make decisions. Jargon adds to that complexity, even when the underlying action is simple.

How to find the right language

The best way to find out what language your users actually use is to listen to them. During the research phase of a design project, I pay close attention to the words real users use when they describe their problems and their workflows. Not the terms their industry uses in official documents. The words that come out naturally in conversation.

Those natural phrases almost always make better labels, better button text, and better instructions than formal terminology. If a user says "add a new client" in conversation, that's better button text than "create new contact entity." If they say "check my hours," that's better than "view timesheet records."

Testing is essential here. Put your prototype in front of real users and watch where they hesitate. Every hesitation is a signal that the language might need to change. You don't need a massive study. Five users will reveal most of the language problems.

When technical language is appropriate

There are cases where industry terminology is the right choice. If your app is built exclusively for professionals who use specific terms daily, if those terms are genuinely faster and more precise than plain alternatives, and if using different words would actually cause confusion, then use the technical language.

But even then, be selective. Use technical terms for the core concepts your professional users live with daily, and use plain language for everything else: navigation, instructions, error messages, onboarding. Your users are professionals in their field, but they're not professionals at using your app. Make the app itself easy even when the content is specialist.

Language is a design decision

Most people think of design as visual: colours, layouts, typography. But the words in your app are just as much a part of the design as the buttons and the screens. In many ways, they matter more. A beautiful interface with confusing labels is worse than a plain interface with clear ones.

The difference between a feature and a solution often comes down to language. A feature is what the system does. A solution is how the user experiences it. And the language you wrap around that experience determines whether it feels effortless or frustrating.

Sources
Nielsen Norman Group - Simplifying content improves task completion rates by over 124%.
Journal of Clinical Epidemiology (2024 systematic review) - Plain language summaries improved comprehension by an average of 19.8%.

Related blog posts:

Why subject matter experts build the best apps →

Designing for the person who can't read your app →

The difference between a feature and a solution →