Explain a Technical Diagram to Someone Outside Your Field
Explain a Technical Diagram to Someone Outside Your Field
Your team reads the diagram in four seconds. Your buyer reads it in four seconds too, and then asks about pricing. That isn't a failure to persuade. It's a failure to say what happens.
The reflex fix is cosmetic — fewer boxes, calmer colors, a warmer label. You end up with a diagram that is easier to look at and no easier to understand. What changes comprehension is the relationship the diagram shows: one path from the event that starts things to the result that ends them, with every connection on that path explainable and the decision governing the outcome still visible. Colors and box count follow from that, or they don't matter.
I'll use one running example, invented for this article: a service that turns a supplier invoice into a payment. Its parts are Intake, Extract, Match, an approval step, and Post. The company, the product, the customer and the finance lead are all fictional. The diagram problems are ones you already have.
Give the diagram one question to answer
A diagram is not a tour. It's an answer to a question the reader is already holding, and if the title doesn't announce that question, the reader supplies their own — usually "what am I looking at?"
For the invoice example, the question is narrow on purpose: what happens between an invoice arriving and money leaving? That gives you a starting event, an ending event, and one path between them. Anything that doesn't sit on that path or change it is a candidate for deletion, and most of your boxes will be candidates.
Two things go wrong here. The first is leading with components. "Extract worker" is a fact about your implementation; "reads the supplier, invoice number and line items off the file" is a fact about the process, which is what a finance lead can actually evaluate. The second is the friendly name. Calling something the Brain or the Hub tells the reader nothing about what it does. You'll explain the function anyway, so put the function on the slide and let the internal name live in your repository.
The question does more than focus the diagram. It decides what gets cut. If the question is "how does an invoice get paid?", the retry handler is noise. If the question is "what happens when the vendor's system is down for an hour?", the retry handler is the entire diagram and the payment step is the noise. Same system, different slides. That isn't a compromise; it's two diagrams doing two jobs.
Make every connecting line say something
Go through the arrows one at a time and ask what each one asserts. In business diagrams a line usually means one of four things, and they are not interchangeable.
Information moves. A file, record, or message goes from one place to another. The receiving end now has it.
Work is handed to someone. The next actor has a task. Nothing has necessarily moved; something now has to be done.
A decision is made. Someone or something chooses among outcomes — approved or held, above or below a threshold.
One part depends on another. Something is read, referenced, or required, but not consumed or changed.
An arrow that is none of these is decoration. An arrow that is two of these at once is a small lie, because the reader will pick one meaning and reason from it.
The C4 model's notation guidance (c4model.com/diagrams/notation) makes a similar ask: state the diagram's scope, say what each element is responsible for, and give relationships labels and a direction that matches what they mean. The principle travels; the notation doesn't. That page is an author's guidance for software architecture diagrams, and its component and protocol conventions are not a standard you should impose on a business deck — I've taken the part about scope, responsibility and labelled direction and left the rest. It's guidance, not a validated notation standard, and nothing about it is evidence that a particular diagram lands with a particular reader.
Practically: don't draw four meanings with one arrow. But don't encode four meanings in four subtly different arrowheads either; at slide size nobody can tell a dotted line from a dashed one from a thin one. Use two or three clearly distinct treatments, put them in a key, and accept that a key is part of the diagram rather than an admission of failure. What is a problem is a key listing four arrow types when your diagram uses one — that key tells the reader to look for distinctions that aren't there.
Direction matters too. Draw the arrow the way the work goes. If the invoice moves left to right and your arrow points left, readers believe the arrow.
The simplification that lies
Now the redraw, in three versions.
The version you have. The example version has nine boxes: an API gateway, a job queue, an extract worker, a matching service, a Postgres store, an audit log, a retry handler, an admin console, and a posting service, joined by one thin grey arrow. Read it as a stranger and three things are unclear immediately. Is the admin console a screen or a person? When the arrow leaves the matching service for the posting service, does the invoice travel there, or does the posting service merely get notified? And does anything in this chain wait for a human being?
The version you'll be tempted to publish. Delete everything not obviously on the money path:
Invoice in → Smart processing → Payment out
Three boxes, one arrow type, no key. Much easier to look at. It also makes a claim the product can't support: that the service approves payments by itself. The finance lead has vanished. The purchase-order list has vanished, so "processing" compares the invoice against nothing the reader can name. The boundary has vanished, so the buyer can't tell what they own and what you operate. If a finance lead later says "well, I approve these," the slide has already told them otherwise, and now you're correcting your own deck in the room.
That's the trap worth naming. Deleting a step the reader needs doesn't simplify the diagram; it swaps in a different and less true claim. The question isn't "is it simpler?" It's "does the reader still know who decides?"
The corrected version. Four decisions do most of the work.
- The title states the question: How an invoice becomes a payment.
- A key defines three connection meanings, and each line uses the one that matches its job.
- The path visibly stops at a person. Nothing reaches Post without passing through that step, and the step is labelled with the role that owns the decision — the customer's finance lead — not with the screen that displays it.
- A boundary line separates the customer's systems from yours, because the reader's first practical question is what they own.
The same fictional content, written out:
Key
[solid] information moves: a file or record changes hands
[open] work handed to a person: someone now has a task
[plain] reference read: a plain line, no arrowhead — looked at, not changed
Path, one invoice
Accounting system --[solid]--> Intake
Intake --[solid]--> Extract
Extract --[solid]--> Match
Purchase-order list ---[plain]--- Match
Match --[open]--> Finance lead approves
Finance lead approves --[solid]--> Post
Post --[solid]--> Accounting system
Nine boxes became five: the API gateway and the job queue merged into Intake, and the Postgres store, the audit log and the retry handler came out. Nothing the finance lead does changes because the retry handler exists. If your audience is engineers, the retry handler earns its place and something else leaves instead — the question picks the cut, not the count.
Notice what stayed. The approval stayed, because the answer to "how does an invoice become a payment" is incomplete without it. The boundary stayed, because it tells the buyer where their systems end. The reference read stayed, because Match comparing the invoice against a purchase-order list is the reason the service exists rather than a convenient place to put a checkbox.
Deeper implementation detail doesn't get deleted from the world; it moves to a second view. If someone asks about the queue or the audit trail, that's a different diagram answering a different question, and you can show it in the same meeting without putting both on one slide.
The corrected path, said in sentences
A diagram and a sentence about the same system should agree on three things: what moves or gets handed over, in which direction, and who decides. Write the sentence, then check it against your arrows.
An invoice file leaves the customer's accounting system and crosses into Intake. Intake passes it to Extract, which reads the supplier, the invoice number and the line items. Extract passes those details to Match. Match reads the customer's purchase-order list — reads it, doesn't change it — and flags any line that doesn't line up. Match then hands the decision to the finance lead, and the automated path stops there. The finance lead reviews the flags and approves or holds. Only an approved invoice reaches Post, which writes a payment instruction back into the accounting system.
Read that beside the drawn version. The sentence says the automated path stops at a person, so the drawing has to stop there too. If the drawing shows a line from Match straight to Post with the approval off to one side, the drawing says the approval is optional, and a reader who has been burned by software will assume exactly that.
The sentence is also a diagnostic. If you can't say what an arrow does without hedging — "well, it kind of passes it, but also triggers…" — that's the arrow telling you it's carrying two meanings. Split it, or decide which one is true. And when the sentence and the diagram disagree, resist the instinct to fix the sentence. Your slide is what the room remembers.
Ask for a retelling, not a preference
The last step isn't a review. It's a question, asked of someone who doesn't work on the product. A colleague from another function will do; a real buyer is better if you have one.
Show them the revised diagram with its key. Ask three things:
- What starts this process?
- What does this connection mean? (Point at two or three specific arrows, including the reference read and the handoff.)
- Who authorizes the result?
Then write down what they said, close to verbatim, and compare it to what the diagram claims. Don't ask whether it looks clear. "Looks cleaner" is a statement about the previous diagram, not a finding about this one, and it will send you off editing the wrong layer.
Some answers tell you the diagram is still doing the wrong work. If they say "the system checks the invoice and pays it," your human step is drawn as a stop along a conveyor rather than a gate that has to open. If they say "the finance lead gets notified," your handoff is reading as a notification. If they can't say what Match compares against, the purchase-order list is drawn as scenery rather than as an input. I can't tell you which of these you'll hear — it depends entirely on the person in front of you, and the whole reason to ask is that you cannot guess it from your own diagram, because you already know the answer.
Two limits on what you get back. A retelling that goes well is a finding about this explanation for this reader; it isn't evidence that your product is reliable, secure, or broadly accessible, and it doesn't replace a technical owner's check that the drawn mechanism matches what the system actually does. And revise at the level of the misunderstanding. If they missed the boundary, redraw the boundary — don't bolt an explanatory paragraph underneath, because the paragraph won't travel with the slide when the slide does.
What the exercise leaves you
The finished slide is two things that agree: a diagram where one path runs from a starting event to an outcome, each connection doing a single named job, the human decision still standing between the automated work and the result, and the customer's edge drawn where it actually is — and beside it, a sentence in plain language saying the same thing in the same direction with the same authority.
The over-simplified middle version is worth keeping in your working file, just not in the deck. It's the cleanest demonstration of the whole problem: a diagram can lose detail, get easier to look at, and become less true. The detail you're allowed to remove is detail the reader doesn't need. The decision they do need — who says yes — isn't detail. It's the answer.
Keep both artifacts, because they age differently. Your system will change and the picture on the slide won't. The sentence is the part you can re-read in thirty seconds and notice that it no longer matches what Intake does. That's the cheap check. The arrows are what your reader remembers.
Frequently asked questions
What is the main job of a technical diagram for an outside reader?
It should answer one question the reader already holds. A title can state that question; for an invoice example, it might be what happens between an invoice arriving and money leaving. That gives a starting event, an ending event and one path between them. Components and friendly internal names are not the same as the process the reader can evaluate.
What can a connecting line in a business diagram mean?
A line usually means one of four things: information moves, work is handed to someone, a decision is made, or one part depends on another. Those meanings are not interchangeable. An arrow that is none of them is decoration; an arrow that is two at once is a small lie because the reader will pick one meaning. Use two or three clearly distinct treatments and put them in a key.
Why can deleting steps to make a diagram simpler make it less true?
Deleting a step the reader needs does not simplify the diagram; it swaps in a different and less true claim. In the example, cutting to Invoice in → Smart processing → Payment out removes the finance lead, the purchase-order list and the customer boundary. It implies the service approves payments by itself. The question is not only whether it is simpler, but whether the reader still knows who decides.
What should a corrected diagram include?
A title that states the question; a key with two or three connection meanings used consistently; a visible stop at the person who owns the decision; a boundary line separating the customer's systems from yours; and any reference read shown as looked at, not changed. A plain-language sentence should agree with the diagram on what moves or is handed over, in which direction, and who decides.
How should you test a revised diagram with someone outside the product?
Ask for a retelling: what starts the process, what specific connections mean, including a reference read and a handoff, and who authorizes the result. Write down the answers close to verbatim and compare them to the diagram's claims. Don't ask whether it looks clear. A good retelling is a finding about this explanation for this reader; it is not evidence that the product is reliable, secure or broadly accessible, and it does not replace a technical owner's check that the drawn mechanism matches the system.