Skipping the Jargon Without Dumbing It Down

Monday, 14:05, at Ashgrove Housing. Tariq has just fixed a housing officer's shared folders and is writing the reply. "Hi Bea, a stale authentication token cached in your profile failed to renew after the domain controller migration at the weekend; I've purged the credential cache and re-established your session. Let me know if the policy refresh doesn't apply at next logon." He reads it back, is pleased with it, and sends it. Bea's reply arrives four minutes later. "Thanks Tariq! Is it fixed?" Everything he wrote was true. The one thing she needed to know was not in it. Or rather it was, in a form only he could read.

Jargon is the vocabulary a trade uses among itself: accurate, compact, and closed to anyone outside the trade. Dumbing down is what people fear doing when they are told to avoid it. It means something quite different: removing the facts along with the words, until the reply is friendly and says nothing. The skill this article teaches sits between the two. You keep every fact and swap every word the reader cannot use. And the result is both plainer and more exact than the version you started with. This article is part of our Explaining Technical Things to Non-Technical People series, and it is about the words.

It covers why jargon is not the same as precision and why dumbing down removes facts rather than words. Then comes the substitution habit for finding the plain word. We cover the rule for naming the technical term once and then using the plain one, followed by the acronym rule. Next come the words that mean something else outside the desk and being precise without vocabulary. We finish with a short war story and the jargon-to-plain table to copy, in that order.

Jargon Is Not the Same as Precision

Technicians reach for jargon because it feels precise, and among technicians it is. "Stale authentication token" means one specific thing to Tariq's colleagues and saves them a paragraph. The precision, though, lives in the reader, not in the word. A word is precise when the person reading it forms exactly the picture you meant. For Bea, "stale authentication token" formed no picture at all, which makes it the least precise phrase in the reply. The same fact in her words, "your laptop was still holding an old sign-in from before the weekend", is exactly as true and lands exactly where it was aimed.

This is the mistake behind most jargon-heavy replies: confusing the precision of the term with the precision of the communication. The term is a compressed file. It unpacks perfectly on a machine that has the right software and not at all on one that does not. Sending a compressed file to someone who cannot open it is not a precise act, however well compressed the file was. The reply has to unpack on arrival, in the reader's head, with whatever they already know.

Plain words can also be more precise than the jargon, because they are checked against what the reader can see. "The server" could be any of six machines; "the machine that holds the shared folders" is one. "Your session" is an abstraction; "your sign-in from before the weekend" is a thing Bea remembers doing. When you are forced to say what a thing does rather than what it is called, you often discover that you were not sure which thing you meant. The plain version makes you decide. Jargon lets a writer be vague with great confidence.

Dumbing Down Is Removing the Facts, Not the Words

The opposite failure is real, and it is the one people point to when they defend jargon. "There was a little glitch with your account and it's all sorted now" is plain, warm, and empty. It does not say what happened, so Bea cannot tell whether it was her fault. It does not say what was done, so she cannot tell whether it will happen again. It does not say what to watch for. The reply has removed the words and the facts together, and the reader is left with a feeling instead of information. A competent adult notices this, and resents it.

The test that separates plain from dumbed-down is whether the reader can predict and act. After a plain reply, Bea knows that the cause was an old sign-in, that the fix was resetting it, and that the folders work now. She knows that if a password prompt appears tomorrow she should reply to the ticket. After a dumbed-down one she knows that something happened and someone says it is fine. The first version has all the facts of Tariq's original in it. It has simply put them in words Bea can use. The second has thrown the facts away to make room for reassurance, which is not what she asked for.

The two failures, jargon and dumbing down, have the same cause. The writer is thinking about how the reply makes them sound rather than what it lets the reader do. Jargon sounds expert. Dumbing down sounds kind. Neither sounds like a person telling another person what happened to their shared folders. The plain version sounds like that. It is the hardest of the three to write, because it requires knowing exactly what happened and deciding which parts the reader needs. The wider question of why explanations miss is in Why Technical Explanations Fail; this article is about the words themselves.

The Substitution Habit

The plain word is almost always found by saying what the thing does rather than what it is called. "Authenticate" is what it is called; "sign in" is what it does. "Provision a mailbox" is the name of the task; "set up your e-mail" is the task. "Latency" is the measurement; "delay" is what the reader feels. When you cannot find the plain word, start the sentence with "the thing that..." and describe the function. For example, you could write "the thing that holds the shared folders" or "the thing that checks your password". Then take the scaffolding away. The description that is left is usually the plain word you wanted.

Some substitutions are one for one and can be learned as a list. "Reboot" is "restart", and "credentials" are "your username and password". "Deploy" is "install", and "sync" is "copy the latest version to". "Roll back" is "put back the previous version", and "patch" is "update". "The backend" is "the part on our servers". The table at the end of this article holds the ones a desk uses most. Learn them the way you learned the shortcuts on your keyboard, so the plain word arrives without a search.

Other substitutions depend on which part of the thing matters to this reader, and that is where the habit beats the list. "The database" might be "where your records are stored" to one reader and "the system behind the booking screen" to another, and both are right. The question to ask is what the reader would call it if they had to point at it. Bea does not call anything a profile; she calls it "my login". Use her word. The reader's own word for a thing is always the most precise word available to you, because it is the one they will not misread.

Write the jargon version first if that is how it comes out, then translate it. Tariq's first draft was fine as a first draft; the mistake was sending it. Technicians think in the trade's words, and asking them not to is asking them to think more slowly. Let the first draft be what it is, read it once as the reader, and swap each closed word for an open one. After a month the swaps happen during the typing. After a year you will have to make an effort to write the jargon version at all. That is a strange thing to notice about yourself and a good one.

Name the Term Once, Then Use the Plain One

Sometimes the reader will meet the technical term again, and then they need to recognise it. If an error message on their screen says "certificate", a supplier's help line says "VPN", or the next technician says "cache", a reader who only ever heard the plain word is stranded. The rule is to name the term once, in brackets beside the plain phrase, and then use the plain phrase for the rest of the reply. "Your laptop was holding an old sign-in (what we call a cached credential) from before the weekend; I have cleared the old sign-in and the folders open now." The term has been introduced, attached to its meaning, and set aside.

Name it once only when the reader is likely to meet it. Bea will never see the phrase "authentication token" on her screen, so introducing it does nothing for her except add a word to worry about. She may well see "certificate" in a browser warning, so that one is worth naming. The test is to ask where the reader will next encounter the word. On screen, from a supplier, in a knowledge base article they will read, or from a colleague: name it. Only in conversations between technicians: leave it in the internal note, where it belongs.

The order matters: plain phrase first, term in brackets second. "A cached credential (an old sign-in)" puts the closed word first and asks the reader to hold it while the explanation catches up. "An old sign-in (what we call a cached credential)" gives them the meaning, then the label for it. It is a small difference in the sentence and a large one in the reader's experience. The first version makes them feel briefly stupid and the second makes them feel briefly informed. The right physical comparison, when one helps, goes in the same bracket and is dropped the same way. That is the subject of Analogies That Work, and When to Drop Them.

The Acronym Rule

Expand every acronym the first time it appears in every reply, even if you expanded it to the same person last week. An acronym is a word made of initials, like VPN for virtual private network or SLA for service level agreement. And the trouble with acronyms is that they look like words and behave like locked boxes. The reader either knows what is inside or they do not. And they will not ask, because asking what three letters mean feels like admitting more than it should. Expanding costs you five words. Not expanding costs the reader the sentence.

After the expansion, decide whether the reader needs the acronym at all. There are three kinds. The first the reader will see on screen or hear from others: VPN, Wi-Fi, PDF (the portable document format), URL (a web address). Expand once, then use the acronym, because it is the word they will meet. The second is internal to the desk or the trade. Examples include DC for domain controller, GPO for group policy object, and AD for the user directory. They also include DHCP for the service that hands out network addresses and KE for known error. Never use these to a requester; use the plain phrase and leave the initials in the note. The third is an acronym that is the ordinary name of a thing even to non-technical people. And there are fewer of these than technicians think. When in doubt, it is the second kind.

Watch for acronyms that have escaped from the desk into the organisation's own speech with a changed meaning. In many organisations "SLA" has come to mean "the deadline" to managers, which is not what it means to the desk. In those organisations, a reply that uses it will be read as a promise about time rather than a description of a target. "Ticket" itself is a word of this kind: to the desk it is a record; to some requesters it still sounds like a fine. The reply can avoid both by saying "your request" and "the time we aim to respond in". Nobody has ever been confused by "your request". The word has no initials to hide behind.

Words That Mean Something Else Outside the Desk

The most dangerous jargon is not the obscure word but the ordinary one with a second, technical meaning. The reader knows the word, so they do not ask, and they build their picture from the meaning they know. "Domain" is a kingdom or a field of expertise. "Host" is someone who gives a party. "Client" is a customer. "Execute" is alarming. "Kill the process" and "abort" are worse. "Fatal error" has made more than one requester wonder whether to call someone. "Corrupted" sounds like a moral judgement on their file. "Legacy" sounds like an inheritance. "Deprecated" sounds like an insult, which, to the software, it is.

Status words are the worst offenders because the desk uses them in every reply and never notices. "Resolved" means to the desk that the technician believes the fix is done. To the requester it means it is fixed, and if it is not, the word becomes a small lie. "Pending" means to the desk that the next step belongs to someone else; to the requester it means nothing is happening. "Escalated" means the ticket moved to someone with more skill or authority; to a requester it can sound like they have been reported. "Closed" means the record is finished; to a requester whose problem has returned, it sounds like a door. The desk is not wrong to use these words internally. What statuses should be called so they mean something to both sides is in Statuses That Mean Something. In a reply, say what the status means in words: "I believe this is fixed; please tell me if it is not."

Emotional loading is the other thing to check. A word can be technically exact and still frighten or insult. "Your account was compromised" is precise and terrifying; "someone else got hold of your password" is exactly as precise and tells the reader what to do about it. "Your machine is infected" has the reader wondering whether to touch it. "Invalid credentials" tells a person who typed their own name that they are invalid. For each word in a reply, ask "will they understand it?" Also ask "what will they feel when they read it, and does that feeling help them do the next thing?" If the feeling is fear and the next thing is "change your password", the fear is in the way.

Precision Without Vocabulary

Precision in a plain reply comes from four things the reader can check: times, names of things they can see, numbers, and actions. "The shared drive was unavailable between 09:10 and 09:50" is more precise than "the file server experienced an outage", because the reader can hold it against their own morning. "The S: drive" is more precise than "the network share" for a reader who sees a letter S on their screen and has never seen the word share. "Three of the forty files" beats "some files". "Restart your laptop, then open the folder" beats "re-initialise the client". None of these needs a technical word. Each of them is exact.

Precision also comes from saying what you do not know, in plain words, with a time. "I do not yet know why the old sign-in did not clear on its own. I will find out and tell you by Wednesday whether it could happen again" is precise about the boundary of your knowledge. The jargon version, "root cause is under investigation", is a phrase that means "we do not know" dressed as a status. The reader can tell. Everyone can tell. Honest uncertainty in plain words is read as competence. Vague confidence in technical words is read as the opposite, which is the reverse of what the writer intended.

The technical version is not lost; it moves. Every reply that goes to a requester has a note behind it that goes to the next technician. And the note is where "stale cached credential, purged, re-authenticated, check policy applies at next logon" belongs, in full, with the trade's words. The next technician needs the compression. If you run QuerySolv, every reply and note stays on the ticket's event history. In that case, you can read your own replies from six months ago and see which words came back as "sorry, what does that mean?" That is the cheapest jargon audit there is. Writing the note so a stranger can use it is the subject of Notes for the Stranger. The reply and the note are two documents for two readers, and neither should be made to do the other's job.

Templates deserve one line here, because a template is where jargon goes to live forever. A canned reply written by a technician in a hurry three years ago will carry "please clear your browser cache and cookies and re-authenticate" into a thousand mailboxes. Nobody will read it back as a requester because nobody wrote it this week. Run the substitution habit over every template once, and the plain version goes out a thousand times instead. How to write a template that reads like a person is in Writing a Template That Does Not Sound Canned.

A Short War Story: The Decommissioned Printer at Northgate Retail

Jonah, on the desk at Northgate Retail, e-mailed all store managers on a Tuesday: "The legacy print server will be decommissioned on Friday. Print queues have been migrated to the new host and clients will be repointed via policy. No action is required." Ruth, who managed the Harbor Street store, read "legacy" and "decommissioned". She took them to mean that her store's printer was being withdrawn. She ordered a replacement on the store card so that she would not lose a weekend of price labels. The managers of two other stores did the same, for the same reason, after Ruth mentioned it on the managers' call. Three printers arrived the following Monday to three stores whose printers had worked perfectly all weekend. Two went back with a restocking charge. The third was kept because nobody could face the paperwork. The regional manager spent a lunch he had not planned explaining the store-card policy. Jonah's e-mail had been accurate in every word and had told the readers, in its last sentence, that no action was required. The desk's lesson, written into its announcement template that week, was that a word the reader has to guess at will be guessed at. The guess will be made in the reader's own world, where "decommissioned" means "taken away" and nothing else.

The Jargon-to-Plain Table

The table below is the template for this article. It lists the words a desk uses most and the plain phrase to use instead. It says whether the term is worth naming once because the reader will meet it. It also gives the everyday meaning that will mislead if you leave the word in. Copy it into an internal article, add a row each time a word comes back as a question, and read it against every template you own. The "say instead" column is written to be pasted as it stands.

Tariq's reply to Bea, run through the table, becomes: "Hi Bea, your laptop was still holding an old sign-in from before the weekend's server move, so the shared folders refused it. I have cleared that old sign-in and the folders open now. If anything asks you for a password tomorrow morning, reply here and I will look straight away." There are three sentences, every fact from the original, and no word she has to guess at. There is a clear answer to "is it fixed?" before she has to ask. The original went into the internal note, in full, where his colleagues read it with gratitude and Bea never had to.

Frequently Asked Questions