Analogies That Work, and When to Drop Them

Tuesday, 08:50, at Redbrook Engineering. Hana, a site engineer, is on the phone from a client's quarry, in a site hut with one bar of signal. "Why do I have to turn the VPN thing on? Everything's slower with it." Leo on the desk starts well and goes wrong in the same breath: "It's an encrypted tunnel that..." Hana cuts in. "A tunnel to where?" Leo stops, thinks, and tries again. "Think of it as a private corridor from your laptop back into our building. While you're in the corridor you're inside the office, even though you're sitting in a hut in a quarry. The corridor is longer than walking across the office, so things take a moment more." There is a pause. "Okay," Hana says. "So when I've finished with the drawings I can close the corridor and the rest of my day will be quicker." Yes. That is exactly it, and Leo did not have to say "encrypted" once.

An analogy is a comparison between the unfamiliar thing you are explaining and a familiar thing the listener already understands. It is borrowed for one job, which is to give them a picture, and returned as soon as the job is done. It is the most powerful tool in the explainer's kit and the easiest to misuse. A good analogy feels so much like the truth that both people forget it is a loan. This article is part of our Explaining Technical Things to Non-Technical People series. It is about choosing the loan, checking it, and giving it back.

It covers what an analogy is for and what it is not, and the rule of one physical, generic analogy per concept. Then come three tests to run before you use one, and how to tell when the analogy has done its job and must be dropped. Next are the seven things a desk explains most, with the comparison that works for each and the sentence that says where it stops. It ends with analogies in writing rather than speech, a short war story, and the analogy bank table to copy and keep, in that order.

What an Analogy Is For, and What It Is Not

An analogy buys the listener a place to stand. Before Leo's corridor, Hana had nothing to attach the word VPN to, so every further sentence about it slid off. After the corridor she had a picture, and the picture let her predict the next thing correctly. A corridor can be left, so the VPN can be turned off. That prediction is the whole value. An analogy succeeds when the listener can work out, on their own, something you have not yet told them, and gets it right.

An analogy is not the truth, and it is not a substitute for the truth. A VPN, a virtual private network, is not a corridor. It is traffic wrapped so that nobody between the laptop and the office can read it, carried over the ordinary internet. The corridor says nothing about encryption, nothing about why it is slower in a quarry, and nothing about what happens when it drops. It was never meant to. It was meant to get Hana from "what is this thing" to "I can turn it off when I'm done", and it got her there in two sentences. Asking it to do more is asking the loan to be the house.

The difference matters because the listener cannot tell where the analogy stops unless you tell them. To you, the corridor is a picture; to Hana, it is now what a VPN is, and she will reason from it. Most of the damage analogies do comes from a listener reasoning past the point where the comparison still holds. They reason correctly, from a picture that was only ever meant to go so far. The explainer's job is to say out loud where the picture ends. This article will keep coming back to that sentence, because it is the one most explainers skip.

One Analogy Per Concept, Physical and Generic

Use one analogy for one concept, and do not change it mid-explanation. Leo's corridor would have broken the moment he added "and the password is like a key, and the data goes through the pipe". Three pictures for one thing is no picture. The listener is now holding a corridor, a key and a pipe and wondering how they fit. One comparison, held steady for as long as it is needed, gives them something to build on. If it turns out to be the wrong comparison, replace it and say you are replacing it. Do not stack a second one on top.

Make it physical. The listener should be able to see it, hold it or walk through it: a corridor, an address book, a key, a photocopy, a waiting room, a notepad by the phone. Abstract comparisons ("it's like a relationship between two systems") give the listener nothing to picture and are usually jargon wearing a hat. Physical ones work because everybody has stood in a corridor and lost a key. The picture arrives whole, with its rules attached, and the rules are what the listener will reason with.

Make it generic. The comparison must be something nearly every adult has met, in a kitchen, a street, a building, a post office, a library, a doctor's waiting room. Never a brand, a product, a film, a game or a sport. A brand dates and may not be known; a film has fans and people who have never seen it. A sport is national; a game divides a room by age. An analogy that one listener in three does not recognise is not an analogy, it is a second thing to explain. (I once watched a colleague explain a cache using the rules of a card game to someone who did not play cards. It took longer than explaining the cache.)

Generic also means evergreen. The desk will use these comparisons for years, write them into replies, and put them in the knowledge base. A picture built from a kitchen and a street will still work when every product you could have named has been renamed or retired. The analogy bank at the end of this article is built from household things on purpose. Nothing in it has a logo.

Three Tests Before You Use One

The first test is prediction: does the analogy lead the listener to the right answer for the question they are about to ask? Hana's next question was always going to be "can I turn it off?", and the corridor answers it correctly. If the next likely question is "why is it slow?", the corridor is weaker. In that case, you may want to add "and the corridor runs over the public road, so it is only as quick as the road". Think one question ahead and check the picture gives the right answer to it. If it gives the wrong one, choose another picture.

The second test is the break point: where does the comparison stop being true, and is that place close to anything the listener will do? Every analogy breaks somewhere. The address book for name lookup breaks because a real address book is not copied to thousands of places with delays between them. The question is whether the listener will reach the break. If they will, you say where it is in the same breath. Say: "it's like an address book, except there are copies of it all over the world and they take a while to agree". If they will not, leave it.

The third test is emotion. Some comparisons arrive carrying feelings the thing does not deserve. "A virus" was borrowed from medicine and brings fear and contagion with it. That is why a requester who hears "your laptop has a virus" wonders whether they should stop e-mailing people. "Quarantine" does the same. "Corrupted" sounds like a moral failing. Before you use a comparison, ask what the listener will feel when they hear it, and whether that feeling will help them do the next thing. A picture that frightens a requester into unplugging their machine is not a neutral tool.

A worked example. A cache is a store of recently used information kept close at hand so it does not have to be fetched again. A browser keeps copies of pages, and a computer keeps copies of recent name lookups. The analogy that passes all three tests is the notepad beside the phone. You jot down numbers you have looked up recently so you do not have to open the directory every time. It predicts correctly: the notepad can be out of date, so "clear the cache" means tear off the page and look the number up fresh. It breaks at a point the listener rarely reaches: real caches have expiry rules and the notepad does not. And it carries no fear. Nobody has ever been alarmed by a notepad.

Knowing When to Drop It

An analogy has done its job the moment the listener can use the real term, or asks a question the picture cannot answer. Hana said "close the corridor", and the right move was to say "yes, turn the VPN off" and never mention corridors again. From that point the real word is doing the work, and the corridor is scaffolding, which is for taking down. Explainers who grow fond of their analogy keep it standing long after the building is up. The listener ends up with two vocabularies for one thing.

The failure to watch for is the stretch. The listener asks a follow-up, and the explainer answers inside the analogy. The listener asks another. Five exchanges later the two of you are discussing the plumbing of a corridor. Each step felt reasonable. The sum is a listener who now has a detailed, confident and wrong model, built with your help. The stretch is the most common way an analogy does harm, and it happens to good explainers because stopping feels rude when the conversation is going well.

Stop with a sentence that names the stopping. "That's about where the comparison stops being useful. The real thing is a bit different there: ..." and then say the real thing in plain words. This is not a confession of failure. It is the second half of the loan, the part where you give the picture back. Listeners trust an explainer more, not less, when they hear it. The signals that the listener's picture has gone wrong, the question that reveals a gap, and how to catch it without quizzing them are in Confirming They Understood Without a Quiz.

The Seven Things a Desk Explains Most

Most desks explain the same handful of things over and over, which means the analogies can be chosen once, tested once, and shared. Seven come up more than the rest: name lookup, the VPN, the cache, permissions, backups, certificates, and the queue itself. Three are worth walking through here; the full set, with the sentence that says where each stops, is in the bank at the end.

Name lookup is how a computer turns a name like fileserver.example.com into the numeric address it actually connects to. The system that does it is the Domain Name System, DNS. The comparison is the address book: you know your colleague's name, the book tells you the number to dial. It predicts correctly that a wrong entry sends you to the wrong place even though you asked for the right name, which is what most "DNS issues" are. It stops being true at copies: there are many address books, all over the world. A change takes time to reach all of them. If the listener's problem is a change that has not "propagated", say that part out loud, because the picture of one book will mislead them.

Permissions are the rules that say which people may open, change or delete which files and folders. The comparison is keys to rooms in a building. You have a key to your office and the meeting room, not to the finance cupboard. The keys say nothing about whether you are trusted; they say which doors you need for your job. It predicts correctly that being refused is about the door, not the person, which takes the sting out of "access denied". It stops being true at inheritance: a key to the building does not automatically open every room. But a permission on a folder often does apply to everything inside it. Say that if the listener is about to share a folder.

Backups are copies of your files taken on a schedule and kept somewhere else, so that what is lost can be put back. The comparison is a photocopy of everything, taken every night and kept in a fireproof cabinet. It predicts correctly that a file deleted this morning can be recovered from last night's copy, and that changes made since the copy are gone. It stops, hard, at how long the copies are kept. A real cabinet keeps paper until someone empties it. A backup keeps copies for a fixed number of days and then overwrites the oldest. That stopping point is the subject of this article's war story. It is the one sentence about backups that every requester needs to hear and almost none do.

Analogies in Writing

In a written reply the analogy has to be shorter and has to carry its own stopping point. You cannot watch the reader's face and you will not be there for the follow-up question. Use one sentence of comparison, with the real term named once in brackets beside it. Put the break point in the same sentence or the next: "Your laptop keeps a notepad of recent lookups (the cache) and one entry on it was out of date; I have cleared it, which just means it will look everything up fresh." That is the whole analogy, and it leaves nothing for the reader to stretch.

Writing is also where the shared bank earns its keep. Five technicians writing five different comparisons for the same thing give requesters five pictures of one mechanism, and the requesters talk to each other. A desk that agrees on the address book, the corridor and the notepad speaks with one voice. A requester who heard the notepad from Leo on Monday recognises it in Dev's reply on Thursday. Keep the bank where every technician can reach it while typing a reply, which for most desks means an internal knowledge base article. If you run QuerySolv, the knowledge base already separates articles for agents from articles for everyone. In that case, the bank can live next to the public how-to guides without ever being mistaken for one. The wider question of sounding like one desk rather than five people is in One Voice Across Five People.

Two cautions for the written form. An analogy is never the whole reply. It sits inside the three-part shape of what happened, what it means for the reader, and what happens next. The shape is what the reader needs most. And a written analogy must still be checked for the words it introduces, because "corridor" is plain but "tunnel" is halfway back to jargon. A comparison that needs its own explanation has failed before it started. The substitutions for the words themselves are in Skipping the Jargon Without Dumbing It Down. The five ways any explanation goes wrong, analogies included, are in Why Technical Explanations Fail.

A Short War Story: The Fireproof Cabinet at Harbourview Clinic

Sofia, the technician at Harbourview Clinic, explained the nightly backup to the practice manager, Grace. Sofia called it "a photocopy of everything on the shared drive, taken every night and kept in a fireproof cabinet". Grace, who was sharp and had asked a good question, took the picture exactly as far as a picture of a cabinet goes: everything, every night, kept. Four months later, short of space on the drive, Grace deleted a folder of two years of scanned referral letters. Grace reasoned that the photocopies were in the cabinet if anyone ever needed one. The backup kept thirty nightly copies and overwrote the oldest each night. So by the time a doctor asked for a letter five weeks later the folder had gone from every copy there was. Two receptionists spent the better part of three weeks asking neighbouring surgeries to re-send a hundred and forty letters. The clinic reported the loss to its regulator. Sofia's analogy had been a good one. The lesson the desk wrote down was that a good analogy still has an edge. The edge is the sentence you must say out loud: "the copies are kept for thirty nights and then replaced, so a backup can bring back what you lost last week, not what you lost last spring."

The Analogy Bank

The bank below is the template for this article. It has one row per thing the desk explains, one physical comparison per row, and what the comparison predicts correctly. It also has the sentence that says where it stops. Copy it into an internal article and keep the wording of the stopping sentence exactly. Add a row only when a comparison has been used three times and landed. Retire a row the first time it misleads someone, and write down why. Each stopping sentence is written to be said or typed as it stands.

Two rows carry most of the weight. One is the backup row, because its stopping sentence is the one that prevents the war story above. The other is the queue row, because it is the analogy the desk uses about itself, every day, to requesters who have been waiting. Sofia added the backup stopping sentence to Harbourview's bank the week after the referral letters. The sentence has been said to every new practice manager since, usually before they ask. None of them has deleted a folder on the strength of a cabinet.

Frequently Asked Questions