How to Turn Technical Jargon Into Information People Can Actually Understand

I spent years in commercial fit-out explaining complicated processes to clients.

👉 There were building codes, safety regulations, council requirements and enough acronyms to make an alphabet soup!

BCA. NCC. ESD. WHS. BP. OP. CDC.

Even typing that list slows me down…

Now imagine sitting across from someone who is about to say all of that out loud to you, expecting you to nod along. We understood every acronym, however our clients didn't.

I watched it happen in real time.

Their eyes glazed over, questions stopped, and the conversation became one person talking and another person trying to keep up.

The problem wasn't that the information was too complicated, it was that we were explaining it from our perspective, rather than theirs.

💡That realisation changed the way I communicated technical information, and I stopped trying to translate every technical term - instead, I started telling stories.

The problem with technical jargon

👉 Jargon isn't inherently bad.

Every profession has language that makes perfect sense to the people working inside it.

• An engineer needs to talk about engineering.

• A lawyer needs to talk about legislation.

• A financial adviser needs to talk about financial products.

• A software developer needs to talk about APIs, frameworks and architecture.

The problem starts when that language crosses the boundary between people who work in the field and people who don't.

• We know what the acronym means - they don't.

• We know why the regulation matters - they don't.

• We know what happens next in the process - they don't.

And when we keep using the language that makes sense to us, the other person has to do the translation in their head while also trying to understand the actual decision we're discussing.

That's exhausting!

I've sat in meetings where you can see someone switch off because they've decided they don't understand what's being said.

They might not say it, and simply nod along, but you can see it all over their face.

💡We're no longer communicating with them - we’re talking at them.

The simplest test: "What does this mean for me?"

👉 This is one of the questions I refer to whenever I'm speaking about communication.

“What does this mean for me?”

Not:

• "What does this regulation say?"

• "What is the technical definition?"

• "How can I demonstrate that I know this subject?"

The person listening usually wants to know:

“What does this mean for me?”

That was particularly obvious during my time in commercial fit-out.

For example, I could have said to a client:

"To ensure compliance with the BCA to obtain the CDC, we'd need to install a supplementary air con in your boardroom."

Technically, that communicates the information, but imagine you're the client.

You've just heard BCA, CDC and supplementary air con in one sentence, and you’re probably wondering what any of that has to do with the meeting room you're trying to build!

So instead, I could say:

"If you'd like 10 people meeting in your boardroom, we need separate air conditioning - otherwise it gets warm and uncomfortable. It's a legal requirement, and it has to be on the plans before we can get the design approved."

👉 Same information.

👉 Same regulation.

👉 Same outcome.

But suddenly we can picture it.

💡There's a boardroom with 10 people sitting in it - so there's an air-conditioning requirement and a reason for it, plus there's something that needs to happen before the design can be approved.

The jargon hasn't been made ‘simpler’, the information has been made relevant.

That's a very different thing.

Storytelling gives technical information somewhere to live

👉 This is where storytelling becomes incredibly useful in professional communication.

When we hear a technical explanation, we're often trying to hold a collection of abstract ideas in our heads.

• Regulation

• Process

• Requirement

• Risk

• Deadline

• Cost

It's a lot to juggle.

A story gives those ideas somewhere to live - suddenly there is a person, a room, a situation, a decision, and a consequence.

Instead of explaining what a rule is, we’re showing someone what that rule does - and that's often what people actually need.

Think about the difference between these two explanations:

"The system requires two-factor authentication for security purposes."

Versus:

"If someone gets hold of your password, they still can't access your account because they'll need the second code from your phone."

The second explanation creates a scene.

Someone has your password, they're trying to get into your account, however there's another step standing between them and your information.

We don't need to understand the architecture of the security system to understand why it matters.

💡That's the power of a story: it gives the listener something they can feel and see.

Try the "What's the scene?" test

👉 The next time we have to explain something technical, don't immediately ask:

"How do I simplify this?"

Instead, ask:

"What's the scene?"

And consider:

• Who is involved?

• What are they trying to do?

• What problem are they facing?

• What changes because of the information you're giving them?

• What happens if they don't act?

• We don't need to invent an elaborate story.

Often, the best story is simply a realistic situation our audience recognises.

For example, if you’re explaining a complicated workplace process, start with the moment when someone actually encounters that process.

• If you are explaining a new software system, don't begin with its architecture - instead start with the employee sitting at their desk trying to complete the task.

• If you are explaining a financial concept - start with the decision the client is trying to make.

• If you are explaining a technical project to a non-technical stakeholder - start with what will actually change for them.

💡Then bring in the technical detail they need.

Here's a simple four-step approach

1. Start with the person, not the terminology

👉 Before we explain a technical concept, think about who is listening and ask:

• What do they already know?

• What are they trying to achieve?

• What are they likely to care about?

The same piece of information can require completely different explanations depending on who's sitting in front of us.

💡We might explain something one way to an engineer and another way to a client - neither explanation is more ‘correct’, they're simply designed for different listeners.

2. Find the real-world situation

👉 Ask yourself:

“Where would this actually happen?”

And put the information into a scene:

• A meeting room.

• A construction site.

• A customer's account.

• A sales conversation.

• A project deadline.

• A person sitting at their desk.

• A team trying to make a decision.

Once you've found the scene, the explanation becomes much easier to follow.

3. Explain the consequence

👉 This is the part people often leave out.

We explain the rule but forget to explain what the rule changes.

• Don't just tell me that something is required - tell me what happens because it is required.

• Don't just tell me the system has a particular feature - tell me what that feature allows me to do.

• Don't just explain the process - show me what happens if we follow it, and what happens if we don't.

4. Bring the jargon only when it becomes useful

👉 We don't have to eliminate technical language, we need to find the right time for it.

Once someone understands the situation, the technical term suddenly has somewhere to land.

For example:

"We need separate air conditioning in the boardroom because of the number of people using the space. That's a BCA requirement and it'll need to be included before the design can be certified. BCA stands for Building Code of Australia"

💡Now the acronym isn't floating around on its own, it's attached to something the person already understands. That's a much easier way to remember information too.

Your expertise isn't measured by how much jargon you can use

👉 There's a temptation, particularly when we’re an expert, to demonstrate our expertise by showing how much we know - I understand that.

We spend years learning our subject, we've earned the right to use the language.

However, the person sitting across from us doesn't need a demonstration of everything we know.

They need to understand the part that matters to them, and that's a different communication skill. It's one that becomes increasingly important as your career progresses.

We might be brilliant at our technical discipline and still find ourselves struggling when we have to present to senior stakeholders, explain our work to clients, speak to another department, or interview for a role outside our immediate area of expertise.

💡Our technical knowledge gets us into the room, our ability to communicate that knowledge determines what happens once we’re there.

The next time you have something complicated to explain

👉 Before you start speaking, pause for a moment, and ask yourself three questions:

• “Who am I talking to?”

• “What do they actually need to know?”

• “What's the scene?”

Then build your explanation around that.

Give them a situation they recognise, show them what changes, and explain why it matters.

Then bring in the technical detail. Good communication isn't about removing your expertise, it's about making your expertise accessible to the person listening.

I've spent a lot of my life thinking about how we take what's happening in our heads and turn it into something another person can understand.

Sometimes that starts with a story.

Sometimes it starts with a pause.

And sometimes it starts with putting the acronym away for a moment and telling someone what it actually means for them.

💡That's when a technical explanation becomes a conversation, and that's when people start listening.

Want to put this into practice?

👉 The next time you have something technical to explain, try the “What’s the scene?” approach.

And if you want a few more practical tools to strengthen the way you prepare, think and communicate, you can download my free Speaker Toolkit.

💡 It’s a simple collection of practical resources you can use before your next presentation, conversation or speaking moment.