How to explain a technical concept simply (without dumbing it down)

To explain a technical concept simply, reverse the usual order. Don’t start with the definition; start with the problem the concept solves. Then carry the explanation with one familiar metaphor, break the mechanism into three steps the viewer can picture, and only at the end give the real name of the thing. Simple doesn’t mean wrong: you leave out details, never truth.

Why technical explanations go wrong

Experts usually explain things in the order they learned them, or in the order of the documentation: definition, components, edge cases. That order makes sense once you understand the topic, and almost none before. The other classic traps:

• The curse of knowledge: you no longer notice which words are jargon. “Request”, “latency”, “token” all feel like plain English to you.
• Completeness: you add every caveat so nobody can say you’re wrong, and the main idea gets buried.
• Abstraction: “the system processes the data” gives the viewer nothing to picture.
• Too many metaphors: a pipe, then a library, then a post office, in the same minute.

The five-step method

1. Start from the problem

Every technical concept exists because something was hard without it. Encryption exists because messages travel through machines you don’t control. Caching exists because fetching the same thing again is slow. Open with that problem, in the viewer’s terms. It gives the rest of the explanation a reason to exist, and it doubles as a hook.

“When you send a message, it passes through a dozen computers you’ve never heard of. So why can’t any of them read it?”

2. Pick one metaphor and stick to it

A good metaphor maps the important parts of the concept onto something the audience already knows, and maps them correctly. Test it: list the three or four key parts of the concept and check that each one has a counterpart in the metaphor.

Once you’ve chosen, use the same metaphor from start to finish. If you need a second one for a different part of the concept, it’s probably a second video.

3. Show the mechanism in three steps

Break the mechanism into the smallest number of steps that are still true. Three is ideal for a 60-second video: it’s enough to show a process, and few enough to remember. Each step should be one sentence and one picture.

1. “Your friend sends you an open padlock. Anyone can see it.”
2. “You put your message in a box and snap the padlock shut.”
3. “Now only your friend, who kept the key, can open it. Every computer along the way sees a locked box.”

4. Give the real name last

Once the viewer has the picture, name it: “That padlock is called a public key, and the key your friend keeps is the private key.” The jargon now lands on something they understand, so it sticks. Introduce at most two or three technical terms per short video.

5. Say where the metaphor breaks

Every metaphor is wrong somewhere. One sentence acknowledging it (“in reality, the padlock is a very large number, and copying it doesn’t help anyone open it”) keeps experts on your side and prevents beginners from over-extending the picture.

Language rules for technical topics

• Use verbs, not nouns. “Your phone measures the delay”, not “delay measurement is performed”.
• Name the actors. “Your browser asks the server”, not “a request is made”.
• Use concrete numbers, rounded. “About a tenth of a second” is easier to picture than “100 milliseconds”, as long as it’s accurate.
• One idea per sentence. If a sentence has a comma and an “and”, split it.
• Ban the empty words: “basically”, “simply”, “just”. If it were simple, you wouldn’t need to say so.

Make it visual

Technical concepts are often easier to see than to hear. In a video, each step of your explanation should have a visual that builds as it’s spoken: a box that appears, an arrow that travels, a number that counts up, a diagram that gains one element per sentence. This is exactly what motion graphics are good at, and why animated explainers suit technical topics better than a talking head.

A useful test: for each sentence of your script, write the visual next to it. If you can’t, the sentence is too abstract. The storyboard guide shows how to do it, and the storyboard generator can draft the visual column for you.

A complete example: what is an API? (about 140 words)

“Every app on your phone talks to other apps, and they almost never share their code. So how do they work together? Think of a restaurant. You don’t walk into the kitchen; you read the menu and tell the waiter what you want. The menu lists what you can ask for. The waiter carries your order to the kitchen. The kitchen cooks, and the waiter brings back your plate. A weather app works the same way. It reads the menu of a weather service, sends an order, “forecast for Paris”, and gets back a plate of data. That menu-and-waiter system has a name: an API, an application programming interface. Of course, real APIs don’t take tips, and the menu is a strict format, not a suggestion. But the idea holds: ask through the menu, never through the kitchen door.”

Notice the order: problem, metaphor, three steps, a real example, the name, the limit of the metaphor. The dev concept template and the security explainer template are built on the same pattern.

Adjust for the audience

The same concept needs a different explanation for beginners, practitioners and decision-makers.

Metaphor mistakes to watch for

A bad metaphor is worse than none, because it gives the viewer a wrong picture that feels right. Need a starting point? The analogy generator proposes a few candidates for a concept; check each one against these failure modes:

• It maps the wrong part. Comparing RAM to “the computer’s memory, like a library” suggests it stores things forever. A desk you clear every evening maps better: fast to reach, limited space, emptied when you switch off.
• It needs its own explanation. If your audience has never seen a switchboard, “it works like a telephone switchboard” adds a second unknown.
• It’s too cute. A metaphor that gets a laugh but doesn’t carry the mechanism will be remembered instead of the concept.
• It hides the key limit. If the most important property of the concept (for example, that a hash can’t be reversed) has no counterpart in the metaphor, say it explicitly.

Handling numbers and scale

Technical topics are full of numbers that are too big or too small to feel: nanoseconds, billions of requests, key lengths. Raw figures rarely help a general audience. Translate them into a comparison the viewer can picture, and keep the real figure on screen for those who want it.

• Express a duration through a familiar one: “if a blink took a full day, this would take a few seconds”, but only once you’ve checked the math.
• Express quantities through a physical image: a stack of paper, a stadium, a lap around the planet, again with verified numbers.
• Use one scale comparison per video. Three in a row cancel each other out.
• When the exact figure doesn’t matter to the point, drop it and keep the order of magnitude: “thousands of times faster” is honest if it’s true and you can’t be more precise.

In a video, a number that counts up while the narration says it, or a bar that grows next to a familiar reference, does more than any sentence. It’s one of the simplest effects to plan in a storyboard, and one of the most effective.

Test your explanation

1. Read it to someone outside the field. Ask them to explain it back in their own words.
2. Note where they hesitate or use your jargon without understanding it: that’s where to rewrite.
3. Ask an expert to check it for errors. Simplification is fine; mistakes are not.
4. Time it. Use words to minutes to check it fits your target length.

For more on structuring the whole script, see the explainer video script template, and for keeping viewers until the end, explainer videos that hold attention.