Explaining Technical Problems to Non-Technical People

A technician tells a team, "The sync job failed because the certificate on the endpoint expired, so I'm going to renew it and restart the service." Every word is accurate. The people listening wanted to know one thing: can they still send invoices today? They nod politely, understand nothing, and walk away worried.

This gap between what the technical person knows and what the listener needs is common in IT. Closing it is a skill, and it can be learned. This entry offers a method you can use in speech and in writing, with before-and-after examples and a short template for status messages. It applies to help desk work, to managers, to family members and to anyone who explains technology. The U.S. Bureau of Labor Statistics lists communication, listening and customer service among the skills for support work, which shows how central the skill is in practice. For role context, see help desk and IT support roles.

Start with the person, not the problem

Federal plain language guidance says that content for the public should be written for its specific audience. The same idea applies to conversation. Before you explain, answer three questions about the listener:

1. What do they already know? A person who uses spreadsheets all day knows files and formulas, but may not know what a server is.
2. What do they care about? Usually it is their work, their time or their data, not the cause of the fault.
3. What do they need to do? Sometimes nothing. Sometimes one specific action.

If you do not know the answers, ask. "Have you used this before?" and "What were you trying to do?" are friendly questions that also give you useful facts. Listening comes first, because a good explanation answers the question the person really has.

Lead with what matters to them

Technical people often explain in the order they discovered the problem: what they saw, what they tried, what they found. Listeners want the opposite order. Put the conclusion first, then the detail.

A useful order has four parts:

1. What is happening, in one sentence.
2. What it means for the listener.
3. What you are doing, and when they will hear next.
4. What, if anything, they need to do.

Compare two versions of the message about the expired certificate.

The second version has no jargon, says what it means for the reader, gives a time frame, and tells them to stand down. It also avoids a promise it cannot keep. "Expect" and "I will message you" are honest about uncertainty.

Swap jargon for plain words

Jargon is not bad in itself. It saves time among experts. It becomes a problem when the listener cannot follow it. Replace a term with a short description of what it does, and use the term only when it helps.

Define any term you keep. If you must say "VPN", add a few words the first time: "the secure connection to the office network, called a VPN". Short sentences help too. When you notice a sentence with two or three technical ideas, split it.

Use analogies, and say where they stop

An analogy compares the unfamiliar to something familiar. A network can be described as roads and addresses, and a backup can be described as a spare key kept in a different place. Good analogies make the main idea easy to hold. Many people understand what an IP address does faster once they hear it compared with a street address.

Every analogy breaks somewhere, so follow it with a limit. "A firewall works like a security guard at a door, checking who is allowed in. A basic firewall mostly checks traffic crossing its boundary, not what people already inside are doing." That last sentence prevents a wrong belief from forming. Do not stack many analogies on one topic; pick one and stay with it.

Check understanding without talking down

After you explain, check that the message arrived. Do not ask "Does that make sense?" because most people answer yes to be polite. Try one of these instead:

• "Tell me how this sounds from your side."
• "What would you like me to explain again?"
• "What's your next step from here?"

If the answer shows a gap, the gap is in your explanation, not in the listener. Say it a different way. The Digital.gov guidance on plain language covers testing content for understanding, and the principle is the same in conversation: you learn whether the message works by seeing how someone uses it.

Tone matters as much as words. Avoid phrases like "it's simple" or "you just need to". They make a person feel slow when they struggle. Admit when something is genuinely confusing.

Write it down: a status message template

In writing, structure replaces tone. The following template suits a message about a fault, and it works in email or chat.

Subject: Invoice sending is paused (fix in progress)

What is happening: Invoices are not sending.
Who is affected: Everyone who sends invoices from the billing system.
What it means: Invoices created now will be queued and sent later. Nothing is lost.
What we are doing: Renewing the credential that connects the systems.
Next update: By 3:00 p.m., or sooner if it is fixed.
What you need to do: Nothing for now.

Keep each line short. Use the same labels each time, so readers learn where to look. Update on schedule even if the news is "still working on it". Silence causes more worry than a short, honest update. A matching note at the end, once fixed, closes the loop.

Common mistakes

• Starting with the cause. The listener wants the impact first. The cause can follow if they ask.
• Hiding behind jargon. It can feel safe, but it leaves people confused and less likely to ask next time.
• Over-simplifying until it is wrong. An analogy should not leave a false belief. Add the limit.
• Promising what you cannot control. Say "I expect" and give a range, not "it will be fixed in ten minutes".
• Blaming the person. "You must have clicked something" shuts down honest reporting. Ask what happened and focus on the fix.
• Skipping the follow-up. People worry about problems they hear nothing about. Say when the next update will come, then send it.

FAQ

How do I explain something I only half understand?

Say what you know and what you do not. "I am still finding the cause, and I will update you at noon" is better than a confident guess. Then find out the rest.

Should I avoid all technical terms?

No. Use terms when the listener needs them to act, such as the name of an error to search for or a setting to open. Explain each one the first time.

What if the person gets annoyed?

Frustration usually comes from lost time or fear of lost work, not from you. Acknowledge it briefly, then give the next step. See help desk and IT support roles for how support teams handle this daily.

Does this matter outside support work?

Yes. Developers explain trade-offs to managers, analysts explain results to teams and administrators explain outages to everyone. The skill appears in every area on the map of IT roles.

How can I practice?

Explain a topic you know well to a friend outside IT, then ask them to repeat it back. Compare their version with yours. Over time you will find which words work. More skill guides are in the Careers and Skills section.