Explaining Technical Problems to Non-Technical People

A technical problem can be difficult enough to solve. Explaining it to someone who does not work in IT can be just as challenging.

A user may report that “the internet is broken”, “the computer has frozen” or “the system deleted everything”. A technician may respond with references to DNS, authentication tokens, storage latency, driver conflicts or failed background services.

Both sides may be describing the same problem, but they are speaking different languages.

Good technical communication bridges that gap. It helps people understand what has happened, what it means, what needs to happen next and what they should do differently—without overwhelming them with unnecessary detail.

The objective is not to prove how much you know. It is to leave the other person feeling informed, reassured and able to make the right decision.

Start With the Person’s Actual Concern

The technical fault may not be the user’s biggest concern.

They may be worried about:

• Losing important files
• Missing a deadline
• Being unable to serve customers
• Making the problem worse
• Being blamed for what happened
• Unexpected costs
• A security breach
• How long the repair will take

Before explaining the technology, identify what matters most to them.

For example, instead of beginning with:

“The operating system has entered an automatic repair loop after a failed boot configuration update.”

Start with:

“Your files are still present. The problem is preventing Windows from starting properly, and we are working on repairing that startup process.”

The second version answers the user’s most urgent question before introducing the technical cause.

Lead With the Outcome

Most people want to know four things:

1. What is wrong?
2. What does it affect?
3. Can it be fixed?
4. What happens next?

Answer those questions early.

A useful structure is:

“The issue is with the network connection between this computer and the server. Your data is safe, but the connection is currently too unstable for the application to work reliably. We are testing the local network first, and then we will check the provider connection if needed.”

This gives the listener a clear mental model without requiring them to understand every protocol involved.

Use Plain Language Without Being Patronising

Plain language is not the same as childish language.

Avoid speaking to adults as though they are incapable of understanding technology. Most people can understand a complex issue when it is explained clearly and in the right order.

Replace jargon where a normal phrase works.

Instead of:

“The endpoint failed to renew its DHCP lease.”

Say:

“The computer did not receive a valid network address from the router.”

Instead of:

“The application is experiencing authentication-token expiry.”

Say:

“Your sign-in session has expired, so the application needs you to authenticate again.”

Instead of:

“The storage array is experiencing degraded redundancy.”

Say:

“One of the drives has failed. The system is still running, but it has lost part of its protection against another drive failure.”

The simplified version should remain accurate. Avoid replacing technical language with explanations that are easier but misleading.

Explain One Layer at a Time

Technical problems often involve several connected systems.

A slow website might involve:

• The user’s device
• Wi-Fi
• The router
• The broadband provider
• DNS
• Internet routing
• The website’s own server

Do not explain all of them at once.

Start with the layer most relevant to the current diagnosis.

For example:

“Your broadband connection is working. The delay begins after the traffic leaves your provider, so the problem appears to be on the route to that particular website rather than with your whole internet service.”

Further detail can be added only when needed.

Use Familiar Comparisons Carefully

Analogies can make an abstract concept easier to understand.

Bandwidth

“Bandwidth is like the number of lanes on a road. More lanes allow more traffic to move at once.”

Latency

“Latency is the travel time. A wide road can still involve a long journey.”

Storage

“The drive is like a filing cabinet. The files are still there, but the index used to find them has become damaged.”

DNS

“DNS is similar to a contact list. It translates a name into the address the computer needs.”

Firewall

“The firewall is like a security desk that decides which connections are allowed through.”

Backup

“A backup is a separate copy stored somewhere that will survive the failure of the original system.”

Analogies are useful only when they clarify the real behaviour. Do not stretch one comparison so far that it becomes inaccurate.

For example, describing the cloud simply as “someone else’s computer” can be memorable, but it leaves out redundancy, shared infrastructure, access control and service design. It may be a starting point, not the whole explanation.

Avoid Unexplained Acronyms

IT conversations are full of acronyms:

• DNS
• DHCP
• VPN
• MFA
• SSD
• RAM
• CPU
• RTO
• RPO
• VLAN
• NAT

Acronyms can make an explanation faster for technical colleagues and harder for everyone else.

When one is genuinely necessary, explain it the first time:

“Multi-factor authentication, often shortened to MFA, requires an additional confirmation beyond the password.”

After that, using the acronym is reasonable.

Do not introduce an acronym the listener will never need again.

Do Not Use More Detail Than the Decision Requires

The right amount of explanation depends on what the person needs to decide.

A business owner considering replacement of an old server may need to understand:

• The risk
• Expected downtime
• Cost
• Available options
• Consequences of waiting

They probably do not need a detailed explanation of RAID controller firmware, sector remapping and disk queue depth.

A useful explanation might be:

“The server is still running, but its storage system has begun reporting hardware failures. We can replace the failed part, but because the platform is already outside support, that would only address the immediate fault. Replacing the server would reduce the risk of another failure and restore vendor support.”

The technical evidence supports the recommendation, but the explanation remains focused on the decision.

Separate the Cause From the Symptom

Users often describe symptoms:

• “The screen is frozen.”
• “The internet is slow.”
• “My password keeps changing.”
• “The printer is offline.”
• “The files have disappeared.”

A good explanation distinguishes what the user experiences from the underlying cause.

For example:

“The spinning wheel is the symptom. The underlying problem is that the application is waiting for a network folder that is not responding.”

Or:

“The password itself has not changed. The account is being repeatedly locked because an old saved password is still being used on another device.”

This helps people understand why a surface-level fix may not be enough.

Be Clear About What You Know and What You Are Testing

Do not present a theory as a confirmed diagnosis.

Use language such as:

• “The evidence currently points to…”
• “We have ruled out…”
• “The most likely cause is…”
• “We are testing whether…”
• “We have not yet confirmed…”
• “There are two realistic possibilities…”

For example:

“The internet connection is stable, and other websites work normally. That makes the website or the route to it the most likely cause, but we are running another test before confirming that.”

This creates trust. False certainty may sound reassuring initially, but it damages confidence when the diagnosis changes.

Avoid Blame

People often become defensive when technical explanations imply that they caused the problem.

Avoid statements such as:

• “You deleted it.”
• “You clicked the wrong thing.”
• “You should have known not to do that.”
• “The user caused the issue.”
• “It works for everyone else.”

Use neutral descriptions:

“The file was moved into the archive folder.”

“The link opened a fraudulent sign-in page.”

“The device was still using an older saved password.”

“The update did not complete successfully.”

When user action is relevant, explain it without judgement:

“The attachment was designed to look legitimate. Opening it allowed the malicious document to request additional access.”

The purpose is to prevent recurrence, not embarrass the person reporting it.

Do Not Blame Another Supplier Without Evidence

It can be tempting to say:

• “It is Microsoft’s fault.”
• “The ISP is throttling you.”
• “The software vendor broke it.”
• “The website is down.”
• “The printer manufacturer is useless.”

Unless the evidence is clear, describe what has been established:

“The local network is working normally. The failure begins when the application connects to the vendor’s service, so we have raised it with them.”

This is accurate, professional and easier to defend.

Explain Risk in Concrete Terms

Technical risk is often described using vague phrases such as:

• High risk
• Critical vulnerability
• Unsupported system
• Security concern
• Single point of failure

These phrases need practical meaning.

Instead of:

“The server is a critical single point of failure.”

Say:

“This server hosts the shared files and accounting application. If it fails, both services will be unavailable until the server is repaired or restored.”

Instead of:

“The firewall is end of life.”

Say:

“The firewall no longer receives security updates. New vulnerabilities may remain unpatched, and the manufacturer may not assist if it fails.”

The listener can now understand the consequence rather than merely hearing a warning label.

Use Timeframes Carefully

Avoid vague statements such as:

• Soon
• A while
• It should not take long
• We are nearly there
• It will probably be fixed today

Where possible, give a realistic range:

“The initial diagnosis should take about 30 minutes. If the drive needs replacement, the full repair and data transfer may take most of the day.”

When the timeframe depends on another organisation, say so:

“We have completed the local checks and passed the fault to the broadband provider. Their current response target is four working hours, but the repair time will depend on what they find.”

Do not promise a completion time you do not control.

Explain Downtime Before It Happens

When a repair may interrupt service, state:

• What will stop working
• When it will happen
• How long it is expected to last
• What people should do beforehand
• What contingency exists

For example:

“The firewall needs to restart to apply the update. Internet access and cloud phone calls will stop for approximately five minutes. We recommend doing this after 6pm, when fewer staff are working.”

This allows the user to make an informed choice.

Explain Costs in Relation to the Problem

A technical quote makes more sense when the person understands what each option achieves.

Instead of presenting:

• Option A: £400
• Option B: £1,900

Explain the difference:

“The lower-cost option replaces the failed drive and returns the existing system to service. It does not extend manufacturer support or address the server’s age. The replacement option moves the data to supported hardware, improves resilience and reduces the likelihood of another age-related failure.”

The person can then assess value rather than comparing prices without context.

Give Recommendations, Not Just Technical Possibilities

A non-technical decision-maker may be overwhelmed by a long list of technically valid choices.

It is useful to present options, but also state which one you recommend and why.

For example:

“There are three ways to restore access. We recommend repairing the existing Windows installation first because it has the best chance of preserving the applications and user settings without a full rebuild.”

Or:

“We could add another wireless extender, but we recommend installing a wired access point because it will provide more reliable coverage and avoid another weak wireless hop.”

A recommendation should be supported by the person’s priorities, not just technical preference.

Use a Simple Problem–Impact–Action Structure

A reliable explanation can be built from three parts.

Problem

What has happened?

“The laptop’s storage drive is failing.”

Impact

What does that mean?

“The computer may become slower, files may become unreadable and the device could stop starting altogether.”

Action

What should happen next?

“We recommend backing up the current data immediately and replacing the drive before attempting further repairs.”

This structure works well in conversations, tickets, emails and management reports.

Add Prevention Only After Solving the Immediate Concern

When someone is dealing with an outage, they may not be ready for a lecture about long-term improvements.

First address the immediate problem:

“We have restored access to the shared folder.”

Then explain prevention:

“To prevent the same issue recurring, we recommend replacing the unsupported storage device and enabling monitoring for drive failures.”

The timing matters. Prevention advice is more likely to be heard once the immediate pressure has reduced.

Explain Security Incidents Calmly

Security incidents require clarity without panic.

Avoid dramatic statements such as:

• “You have been hacked.”
• “They have everything.”
• “The entire network is compromised.”
• “Your data is gone.”

Unless those conclusions have been established, use precise language:

“The account was used to sign in from an unfamiliar location. We have reset the password, revoked existing sessions and are checking whether any email or files were accessed.”

Or:

“The device ran a malicious program. We have isolated it from the network and are now checking what the program changed or transmitted.”

People need to know:

• What is confirmed
• What remains uncertain
• What has been contained
• What actions they must take
• When they will receive another update

Do Not Hide Seriousness Behind Reassuring Language

Plain language should not minimise a genuine risk.

Avoid saying:

“It is probably nothing.”

when the issue could involve data exposure.

Use calm but accurate language:

“We do not yet have evidence that data was taken, but the account was accessed without authorisation, so we are treating it as a potential security incident.”

Reassurance should come from the actions being taken, not from pretending the problem is less serious.

Use Screenshots and Diagrams When They Help

Some issues are easier to understand visually.

Useful examples include:

• A simple network diagram
• A before-and-after workflow
• A screenshot showing the correct button
• A storage-capacity chart
• A timeline of an incident
• A diagram showing backup copies
• A traffic-light risk summary

Keep diagrams simple.

A non-technical explanation rarely benefits from a network map containing every switch port, IP address and firewall zone. Show only the parts necessary to understand the problem.

Show the Sequence of Events

Timelines are useful when several events contributed to a fault.

For example:

1. The user changed their password.
2. A phone retained the old password.
3. The phone continued attempting to sign in.
4. The account was repeatedly locked.
5. Outlook displayed a password error.

This is easier to understand than a long paragraph about cached credentials and authentication failures.

Explain Why a Quick Fix Is Not Always the Right Fix

Users may understandably ask:

• “Can you just restart it?”
• “Can we bypass the warning?”
• “Can you turn the security off?”
• “Can we keep using it until it breaks?”
• “Can you recover only this one file?”

Explain the trade-off:

“Disabling the security control may allow the application to run, but it would also remove protection against untrusted software. We recommend repairing the application instead.”

Or:

“Restarting the server may restore service temporarily, but the hardware errors will remain. We need to back up the data and replace the failing component.”

Do not simply say “no”. Explain why the proposed shortcut creates risk.

Avoid Saying “It Is Complicated”

Telling someone that a problem is complicated without explaining it can sound dismissive.

Replace:

“It is complicated.”

with:

“There are two separate issues: the internet connection is stable, but the application’s server is responding slowly. We are testing them separately so we do not replace the wrong equipment.”

Complexity can still be acknowledged:

“Several systems are involved, but the important part is that we have narrowed the fault to the application’s connection rather than your computer.”

Avoid Saying “It Should Work”

When something does not work, saying that it should work is rarely helpful.

Use:

“This configuration is supported, so the next step is to identify why this device is behaving differently.”

Or:

“The service is expected to work in this setup, but the logs show that authentication is failing.”

Focus on evidence and next actions.

Avoid Saying “Nothing Is Wrong”

A user reporting a problem has experienced something, even when your test does not reproduce it.

Instead of:

“Nothing is wrong.”

Say:

“The connection is working normally during our current test, but the fault may be intermittent. We will monitor it and need the approximate time of the next occurrence.”

This validates the report while remaining honest about the available evidence.

Check Understanding Without Testing the Person

Do not ask:

“Do you understand?”

People may say yes simply to avoid embarrassment.

Use more practical checks:

“Does that explanation match what you were seeing?”

“The important next step is to leave the laptop switched on tonight. Is that workable for you?”

“Just to confirm, which service will be unavailable during the restart?”

This verifies understanding without making the conversation feel like an exam.

Invite Questions Without Opening an Endless Technical Lecture

A useful phrase is:

“The key point is that your data is safe, but the computer’s startup system needs repairing. Is there one part of that you would like me to explain further?”

This keeps the conversation focused while giving the person control over the level of detail.

Tailor the Explanation to the Audience

Different audiences need different information.

End user

Usually needs:

• What happened
• Whether data is safe
• What to do
• When it will be fixed

Manager

Usually needs:

• Business impact
• Risk
• Cost
• Timeline
• Options

Finance team

Usually needs:

• Financial exposure
• Replacement cost
• Contract implications
• Downtime cost

Compliance or security team

Usually needs:

• Scope
• Evidence
• Containment
• Data affected
• Reporting obligations

Technical colleague

May need:

• Logs
• Error codes
• Versions
• Configuration
• Test results
• Reproduction steps

The same fault should not be explained in exactly the same way to every audience.

Use Layered Communication

A useful technique is to provide information in layers.

First layer: one sentence

“The application is unavailable because its database server has stopped responding.”

Second layer: short explanation

“The application itself opens, but it cannot retrieve customer records. We have confirmed that the network is working and are restarting the database service.”

Third layer: technical detail

“The database service stopped after the storage volume reached capacity, and the transaction log could no longer expand.”

This lets each reader stop at the level appropriate to them.

Write Better Support Tickets

Internal support notes can be technical, but user-facing updates should remain clear.

Avoid sending the user a note such as:

“Checked NIC, flushed DNS, renewed lease, disabled EEE, updated Intel driver, issue resolved.”

Use:

“The laptop’s network connection was using an outdated driver and was repeatedly dropping. We installed the current driver and confirmed that the connection now remains stable.”

Keep detailed commands and logs in the internal ticket where they belong.

Write Better Incident Updates

During a wider outage, each update should answer:

• What is affected?
• What is working?
• What has changed?
• What are we doing?
• When is the next update?

Example:

“Staff cannot access the customer-management system. Email, internet access and phones remain available. The issue is with the application’s cloud provider, which is investigating. We will provide another update by 2:30pm or sooner if service is restored.”

Avoid sending repeated messages saying only:

“We are still investigating.”

Explain Resolutions as Clearly as Faults

A user should know what was fixed.

Weak resolution:

“Resolved.”

Better resolution:

“The Wi-Fi access point had stopped responding and was restarted. We also installed its pending firmware update. Devices have reconnected and we have tested the connection from the affected meeting room.”

A strong resolution message may include:

• Root cause
• Action taken
• Result of testing
• Any remaining limitation
• Prevention work

Be Careful With Error Codes

Error codes can help technicians but mean little without context.

Instead of:

“It is error 0x80070005.”

Say:

“Windows is reporting error 0x80070005, which means the program is being denied access to a file or setting it needs.”

Do not assume that quoting the code explains the problem.

Be Honest When the Root Cause Is Unknown

Some faults disappear before they can be fully diagnosed.

Do not invent a cause simply to make the ticket feel complete.

Use:

“The service recovered after the router re-established its connection. We have not confirmed why the connection dropped, so we are monitoring for another occurrence.”

You can still describe useful evidence and prevention steps.

Do Not Overload the Conversation With Every Possibility

A technician may think through ten possible causes internally. The user does not need to hear all ten at once.

Instead of:

“It could be DNS, DHCP, the switch, the firewall, the ISP, the driver, the cable or the server.”

Say:

“The fault is either on the local network or the provider connection. We are testing the local network first because that will tell us which side needs attention.”

Share possibilities in a controlled order.

Explain What the User Needs to Do

Instructions should be specific.

Avoid:

“Try again later.”

Use:

“Leave the computer switched on and connected to power. Do not restart it while the repair is running. We will contact you when it is safe to use.”

Avoid:

“Check the cable.”

Use:

“Please check that the blue Ethernet cable is firmly connected to the laptop dock and the wall socket. You should hear a click at each end.”

Where safety is involved, be explicit:

“Do not open the power supply or touch the damaged cable. Switch the socket off and move away from the equipment.”

Use Numbered Steps for Actions

When the listener must perform several actions, present them in order.

For example:

1. Save any open work.
2. Close Outlook.
3. Restart the laptop.
4. Wait for the sign-in screen.
5. Connect to the company VPN.
6. Open Outlook again.

Do not place essential actions inside a long paragraph.

Describe Buttons and Menus Precisely

Avoid vague instructions such as:

“Go into the settings.”

Use:

“Open Settings, choose Network and Internet, select Wi-Fi and then choose the office network.”

When menu names vary, say so:

“The option may be called Software Update or System Update, depending on the phone.”

Screenshots can help when the interface is difficult to describe.

Use Consistent Names

Do not call the same item:

• The server
• The box
• The host
• The machine
• The main unit

within one explanation.

Choose one label and use it consistently.

For example:

“The file server stores the shared folders. The file server is still running, but one of its drives has failed.”

Consistency reduces cognitive load.

A Practical Explanation Template

Use this structure for everyday support:

What happened

“The laptop lost its connection to the office Wi-Fi.”

Why it happened

“Its wireless driver stopped responding after the latest update.”

What it affected

“The laptop could not reach email, shared files or websites, but the wider office network remained available.”

What we did

“We restarted the wireless adapter and installed the corrected driver.”

Current status

“The connection is now stable and has passed a 20-minute test.”

What happens next

“No action is required from you. We will apply the same driver update to the other affected laptop.”

Example: Explaining Slow Wi-Fi

Technical version:

“The client is roaming poorly between two access points because the received signal strength remains above the sticky-client threshold.”

Clear version:

“The laptop is staying connected to the access point in the other room instead of moving to the nearer one. We are adjusting the wireless settings so devices switch more reliably as people move around the office.”

Example: Explaining a Failed Backup

Technical version:

“The incremental job failed because the repository was offline and the retention chain could not merge.”

Clear version:

“Last night’s backup did not complete because the storage device receiving the backup was unavailable. The previous successful backups are still present, and we are rerunning the failed job.”

Example: Explaining a Security Patch

Technical version:

“The update remediates a remote-code-execution vulnerability in the edge appliance.”

Clear version:

“The firewall update fixes a security weakness that could allow an attacker to run unauthorised commands. Installing it requires a short restart, so we recommend completing it outside working hours.”

Example: Explaining Email Quarantine

Technical version:

“The message triggered the impersonation-protection policy and was placed in administrative quarantine.”

Clear version:

“The email was held because it looked like someone was pretending to be a senior member of staff. It has not been delivered, and we are checking whether it is genuine.”

Example: Explaining a Full Disk

Technical version:

“The system volume reached 100% utilisation, causing service failures and transaction-log errors.”

Clear version:

“The server ran out of storage space. Once it became full, the application could no longer save new information. We have created temporary space and are now addressing what caused the storage to fill.”

Example: Explaining a DNS Problem

Technical version:

“The configured resolver is timing out on recursive queries.”

Clear version:

“The connection is working, but the service that translates website names into network addresses is not responding reliably. We are switching to a working resolver while the original service is investigated.”

Example: Explaining Double NAT

Technical version:

“Two routing devices are performing NAT, preventing inbound port mapping.”

Clear version:

“The network has two routers creating separate private networks. That is why gaming and remote access cannot open the connections they need. We will leave one device as the router and change the other to provide Wi-Fi only.”

Common Communication Mistakes

Avoid:

• Starting with jargon
• Explaining every possible cause
• Speaking too quickly
• Using unexplained acronyms
• Blaming the user
• Promising an unconfirmed repair time
• Treating a theory as fact
• Saying “nothing is wrong”
• Using an analogy that changes the meaning
• Giving instructions without context
• Ending without a clear next step
• Assuming silence means understanding

A Checklist Before You Explain

Before speaking or writing, ask:

• Who is the audience?
• What are they most worried about?
• What is confirmed?
• What remains uncertain?
• What is the business or personal impact?
• What decision do they need to make?
• What action do they need to take?
• Which technical details are genuinely necessary?
• What is the next update or milestone?
• Could any wording sound blaming or dismissive?

Clear Communication Is Part of the Fix

Solving the technical problem is only part of good IT support.

A user who does not understand what happened may:

• Repeat the same risky action
• Resist a necessary change
• Lose confidence in the support team
• Misreport the issue to colleagues
• Make the wrong purchasing decision
• Interrupt a repair
• Assume their data is lost
• Believe the problem is resolved when it is not

A clear explanation creates confidence and improves the outcome.

Start with the person’s concern. Explain the problem in plain but accurate language. Separate symptoms from causes, state what is known, describe the impact and finish with a clear next step.

The best technical explanation is not the one containing the most detail. It is the one that helps the listener understand what matters and act correctly.

Hamilton Group helps businesses simplify complex technology, communicate IT risks clearly and make confident decisions about support, security and infrastructure.

Call 0330 043 0069 or visit hgmssp.com to speak with one of our experts.