How do you explain the details of something technical to a non-technical audience?

Question

When writing about technical topics it is often difficult to get across the complexity of a topic without getting "stuck in the weeds" and ultimately leaving the audience confused or disinterested. Particularly when the audience lacks the necessary background to explain the topic in it's own terms (e.g. explaining the usage of a certain type of cryptography to management or end-users).

What techniques can you use to help explain the important parts of a topic, and possibly introducing the relevant jargon, while keeping such an audience engaged?

Answer 1

When explaining concepts of any kind to an audience unfamiliar with the knowledge domain, the following methods are highly effective:

• analogy & metaphor - compare (albeit inexactly) what this thing does to how that thing does whatever (in computer software, hardware, and services (among other fields), there is the ever-present "car comparison")
• stories - humans are highly story-oriented beings (it's used in selling, teaching, programming, history, math, etc etc)
• the three pitches (there are variations, like this one, too):
  • 30 second :: aka "elevator pitch" - get someone excited enough to want to keep listening/reading
  • 300 second :: you've got their attention, don't lose it; go into a little more detail - but don't overwhelm
  • 30 minute :: you really want people to buy-into what you're telling them

Communication is like selling - it's all about return on investment. And ROI is all based on understanding abstractions (and how they leak). You need to give the reader/listener enough of a promise they're going to get value at least proportional to the time spent consuming what you're trying to convey that they want to stick around.

Guy Kawasaki promulgates the "10/20/30 Rule of PowerPoint" (in direct relation to pitching to venture capitalists, but the general premise carries into most other realms well, too):

• no more than 10 slides
• no more than 20 minutes
• no font smaller than size 30

If you cannot convey the core basics of what you want your audience to "get" in a few minutes with [the equivalent of] a few bullet points in an easily-followed (ie "large font") manner, you're [probably] not going to be very successful in "communicating".

Once you've accomplished the levels of "hook" you need to get your audience to want to continue through, keep it up: there will be boring aspects of what you need to convey - don't skip them, don't dwell on them too long, don't lie about them, and don't over-simplify them - but try to make them as short and interesting as you can.

Answer 2

The tactic I use most often for this is analogy.

By creating an analogy to a commonly understood topic, you can introduce the core ideas in a way that feels familiar to the audience.

That said, coming up with a quality analogy can be difficult and possibly take a couple of attempts. It doesn't need to be perfect, though, it just needs to lay out the basic structure. Knowing where your analogy doesn't work is about as important and knowing where it does, since those points are where you possibly have the most opportunity to drive home what makes your topic unique and complex.

Answer 3

While there are strategies such as the use of analogy and simplified language that can help somewhat, the real issue is that a non-technical audience is non-technical (for a given domain) because they are not interested in the details of that domain.

We are all technical in some domain or another, and none of us has the interest or the capacity to be interested in every domain of life. Our highly mechanized and organized society is based on hiding as much of the technical detail of every aspect of life from people as you possibly can. You don't want to see how the sausage is made, not just because it is icky, but because if you want affordable safe sausages, you should stick to what you do best and leave the sausage making to the experts.

So, unless you are writing learning material for people who actually want to become technical in a given area, you should be worrying less about how to convey the details and more focussing on hiding the details as much as you can.

The aim of technical communication is to give people the confidence to act correctly. Throwing a bunch of information at people that they only half understand and don't really care about is not a recipe for building their confidence. So ask yourself, how little do people actually have to know in order to act correctly and with confidence. The less you can tell them, the better.

Forcing people to be more technical in order to use your product or service simply means making that product or service harder to use. Don't focus on how to explain the details. Focus on how to conceal as many of the details as you possibly can while still allowing people to act correctly and with confidence. Every detail you add after that will reduce, not enhance, the effectiveness of your documentation.

Answer 4

One common technique is to introduce new concepts gradually, accompanied by practical tasks or specific use scenarios. This mostly applies to longer texts, such as tutorials.

Divide your text into steps/sections and only introduce a minimum number of new concepts in each section, only those that are necessary to perform the task.

Clearly mark which parts of the text contain explanation, and which parts are specific instructions.

Include a clear "preview" of the whole content of the text, if it is a longer one. You can also summarise each section/step with a sort of "what we learnt today" note (although depending on the situation be careful not to sound to school-ish/patronising).

Link to more advanced descriptions of a given concept (if you have them), but clearly note whether reading them is necessary for following a given instruction, or if it's just supplementary material.

Answer 5

I'm personally hostile to analogies and "dumbing down", because it can have the unintended effect that people take the analogy too far, or get stuck with the dumbed down version.

Your goal is to show the complexity, but without overwhelming the audience. You can do that by providing multiple layers.

In the main part of the text, speak mostly about consequences, leave out technical details: Encryption ensures the confidentiality of documents because knowledge of a key is needed to decrypt and thus read the document. This layer is written for the non-technical audience and should require no technical knowledge to understand. You would explain, say, the difference between encryption, hashing and cryptographic signatures, but not how they work.

Then you provide an option for the reader to study the topic more in detail, e.g.: see Appendix B for recommended encryption schemes.

Then in the appendix, you can dig into more technical details, e.g. which encryption algorithms and keylengths are recommended. This layer is written for a technical person or a person with basic technical knowledge, someone who can stomach technical terminology and a little bit of math. You would explain the different algorithms and their application, how to correctly use them and technical details of methods, but not explain the algorithms themselves.

Again, for the very low detail, like how ECB differs from CBC or why the CV is important except in those modes which use a nonce... you refer to footnotes or endnotes or another way to hide the third layer out of the way of the immediate text flow.

And if you want, you can add a fourth layer where you actually explain how AES or DH, etc. work. Though that layer has already been written by others and you could just refer to it.

You can apply the same principle to implementation details - the top layer speaks to the user, describing what the software does. The second layer speaks to the system administrator describing how to install and maintain it. The third layer speaks to the developer and describes the source code, how to modify it, etc.

The basic idea is to provide the details, but move them out of the way so that a reader not interested in them (or afraid that he'll not understand) can skip over them easily. The best way to accomplish that is to not have them in the main text. Appendices, footnotes, etc. were all invented for this purpose. You can also add a "technical part" at the end with individual chapters and refer to those. All you need is some references (back and forth!) so the reader who does want to dive into the details can quickly find his way back to the main text.

Answer 6

Elegance is unavoidably beautiful, but implementation details are tedious at first. I'd not give a section on motivation followed by a section with more details as much as I'd have the whole thing following gradually and naturally from fascination you've built about the subject.

---

For example try drawing a loop with a smooth curve. This may be on a piece of paper or by using a loop of string. The loop can pass ocer itself as much as you like as long as there are no places where three lines meet in exactly the same place.

I might now pose a question or three, which may if your lucky (hint, this is mathematics) turn out to unexpectedly and inexplicably be related:

1. Given the loop you've drawn can you add a square somewhere, oriented and sized as you wish but so that all 4 corners touch the sides of the loop.

2. Can you notate each crossing to show what line passes "over" and which passes "under" the other.

3. Can you colour/label each region "black" or "white"?

Obviously you can't always do these things. Except (surprise) it turns out that you always can, so you can start taking this for granted and move on.

Perhaps now an algorithm could be written to calculate the specifics of the above 3 points given a specific loop, how?

Properties can be used to find other properties, this is a property of properties. Another impressive example with loops involves hanging picture around a given number of pegs. This can be done by looping the string above the picture back and forth over and under the pegs to ensure that when another given number of pegs are removed the picture falls. For example 5 pegs, any 3 of which must be removed.

How are things like this, and anything else you may wish to understand and do worked out? One approach involves translating any specific loop to another rearrangeable mathematical object, specifically you can change any specific loop into an equivalent equation. In the case of the colouring example we may well want instead to use graph theory.

---

The above was only an example, but at this point you probably want to know yourself. I think a lot of knowledge is very naturally like this. Start with high level ideas, and build to "Blah corp recommends you do the calculation in this order" level details with your readers interest.

Answer 7

If your audience is starting out non-technical but wants to get more in-depth knowledge, start by giving them credit for the motivation they have. Assume that someone digging deeper wants to learn as much as you can provide. Be clear, but don't over-simplify.