# How to Explain Complex Ideas Simply to Any Audience

To explain something complex simply, start with a one-sentence summary of what it is and why it matters to this listener. Then add one comparison to something they already know, replace jargon with plain words, and give detail only in the order they need it. Finish by checking understanding with a question that asks them to use the idea, not "Does that make sense?"

By the Speaking Coach team at Sodhera Intelligence. Updated 2026-10-22. Source: https://www.orecci.com/speaking-coach/guides/how-to-explain-things-simply/

## Start with one sentence

Experts tend to explain things in the order they learned them: background, how it works, then what it means. Listeners need the reverse. Before you say anything else, give them a single sentence they can hold on to.

The formula: **what it is + what it means for them.**

| Topic | One-sentence summary |
| --- | --- |
| A database migration | "We're moving our customer data to a new system, which means the app will be faster but offline for two hours on Sunday." |
| Inflation-linked pay | "Your raise is tied to prices, so if prices go up 3%, your pay goes up at least 3%." |
| A machine learning model | "It's a program that learned from past orders to guess which customers are about to cancel, so we can call them first." |
| A new expense approval flow | "Claims under 100 now get approved automatically, so you'll be paid in days instead of weeks." |

If you can't write this sentence, you're not ready to explain it yet. Writing it first also stops you rambling, because you know where you're going. The [pyramid principle](/speaking-coach/glossary/pyramid-principle/) is the formal version of this idea.

## Layer the detail

After the summary, add detail in layers. Stop after any layer if they have what they need.

1. **The summary.** What and why it matters to them.
2. **The comparison.** One analogy to something familiar.
3. **The how.** Two or three plain steps, no more.
4. **The detail.** Numbers, exceptions, technical terms, only if asked or needed.

Most non-expert audiences need layers one and two, sometimes three. Decision-makers often want layer one plus the cost or risk.

## Use one good analogy

An analogy borrows understanding from something people already know. Rules that keep it useful:

- **Match it to the audience.** A cooking analogy for a general audience, a spreadsheet analogy for finance people.
- **Keep it to one.** Switching between three comparisons confuses more than it helps.
- **Say where it breaks.** "It's like a library catalog, except the books move around." This stops people taking it too far.

Examples:

| Idea | Analogy |
| --- | --- |
| An API | "A waiter: you tell it what you want, it goes to the kitchen and brings it back. You never go into the kitchen yourself." |
| Encryption | "A locked box only the recipient has the key to. Anyone can carry the box, but only they can open it." |
| Technical debt | "Shortcuts in a house build. Each one saves time today, but every future repair takes longer." |
| Cache | "Keeping the things you use most on your desk instead of walking to the filing cabinet each time." |

## Swap the jargon

Jargon is fine among experts. With anyone else, it costs attention: each unknown word makes the listener stop and guess, and they miss the next sentence.

| Instead of | Say |
| --- | --- |
| Leverage | Use |
| Latency | Delay |
| Deprecated | Being retired |
| Bandwidth (for people) | Time |
| Stakeholders | The people affected (name them) |
| Root cause | The real reason |
| Scalable | Works just as well when it gets bigger |
| KPI | The number we're judged on |

If you must use a technical term, define it once, in passing: "We'll run a regression, which is a way of checking which factors actually move the number."

## Before and after: an example

A made-up example: a developer explaining a release delay to a sales team.

### Before

> "So basically the release is blocked because the auth service had a breaking change in the token schema, and our mobile clients are still on the old SDK, so we need to do a coordinated rollout with backward compatibility, which means adding a shim layer, and QA needs another sprint to regression test all the flows."

### After

> "The new version will ship two weeks late, on the 18th instead of the 4th. The reason is that the login system changed, and older versions of the app wouldn't be able to sign in. It's like changing the locks while people still have old keys: we're building a step that accepts both, then testing every way people log in. For your customer conversations, nothing changes until the 18th, and nobody will be locked out."

What changed: the date and impact come first, the jargon is gone, one analogy carries the technical part, and it ends with what the listener needs to know.

## Check understanding the right way

"Does that make sense?" almost always gets a yes, even when it doesn't. People don't like admitting they're lost. Ask questions that make them use the idea:

- "What would you tell a customer who asks about this?"
- "Which part of this affects your team most?"
- "If you had to explain it to your manager in one line, what would you say?"
- "What's the first question you'd get asked about this?"

If their answer is off, you've found the part to re-explain, without anyone feeling tested. Watch faces too: frowns or people glancing at each other mean it's time to go back a layer.

## Practice it out loud

Explaining is a speaking skill, so practice it by speaking. Pick a concept from your work and explain it out loud in 60 seconds to someone outside your field, or to a partner who interrupts when they're lost. In Speaking Coach you can describe any situation, like explaining a delay to a nontechnical manager, and the AI partner plays that person and asks about what you actually said. This also prepares you for the interview question [tell me about a time you explained something complex](/speaking-coach/interview-questions/tell-me-about-a-time-you-explained-something-complex/).

## Questions people ask

### How do I explain something technical to a non-technical person?

Lead with a one-sentence summary of what it is and what it means for them, use one everyday analogy, drop the jargon, and stop before the detail unless they ask for it.

### Should I use slides or a diagram?

A simple drawing of boxes and arrows often helps more than text-heavy slides. Say the one-sentence summary first, then show the picture, and talk through it one box at a time.

### How do I know if I'm oversimplifying?

If an expert would say your summary is wrong, not just incomplete, you've gone too far. Simple and accurate is the goal; leaving out detail is fine, changing the meaning isn't.

### How long should a simple explanation be?

Aim for 30 to 60 seconds for the first pass: summary, analogy and the key "how". Then let questions guide what comes next.

### How do I explain something complex in a job interview?

Use the same layers: the one-line summary, why it mattered, and what you did. Interviewers often test this on purpose, so keep it short and check if they want more depth.

---
Speaking Coach on the App Store: https://apps.apple.com/app/id6767124039
Speaking Coach on Google Play: https://play.google.com/store/apps/details?id=com.sodhera.speakingcoach