The best books on Technical Communication

You’re a writer and communicator about maths topics, which are hard to make fun and accessible. Have you developed any general principles about how to communicate technical topics effectively?

I’d say there are two important principles. The first is to have empathy for what it’s like to be a beginner. Immediately after you learn something, you forget what it was like to not know it. We call this the curse of knowledge. You’ve forgotten what it’s like to not know how to read, to not know how to tie your shoes. Have empathy for the beginner. Remember that moment of transition from confusion to epiphany.

The second principle is to start with analogies. Since preliterate times, people have used stories to understand concepts. Our brains are wired to remember stories. Before launching into the technical details, provide an analogy that helps your listener to grasp the reason or the purpose of the lesson.

Let’s jump into the five books you’ve recommended for us on technical communication. Your first pick is Don’t Make Me Think by Steve Krug. Can you introduce us to this book?

This is a beautiful, short, funny little book about software usability. Usability is the art of communicating the point of software. In the modern world, a large percentage of our time is spent on apps, devices, phones, and on. It’s important to be able to understand how to build them and how to communicate your intent. If you can remove the reason for someone to have to think, that’s great. The book’s title, Don’t Make Me Think, is a beautiful summary of this idea.

We think that complexity is good. For a lot of people, having so many options causes decision fatigue. It’s overwhelming. You can address this by removing a few of the options or presenting them in a particular order. If you have ten options, don’t present all ten options on the first screen. Instead of giving people everything up front, you might start by presenting two options. Then, depending on what the user selects, present two more options, and so on.

The same principle may be applied to communication. Instead of giving people the entire picture or story up front, give them a high-level overview, and they can drill into more details as needed. Don’t Make Me Think presents examples of how to communicate what someone needs to do and how they need to do it, and software is a use case of how to do that.

You talked about empathy before, and it seems like this is related. How do you guide someone who’s navigating a software app or reading a manual, remotely? You can’t look over their shoulder and point it out when they get something wrong.

It comes back to providing the right analogy. While you can’t necessarily explain all the steps in perfect detail, you can give someone an analogy for what they need to do. I would compare this to giving someone a map as well as giving them directions. If you give me only directions and I make a wrong turn, I will have no idea exactly where I went wrong and it will be hard to backtrack. But if you give me directions along with a map of where I am going, I will understand why I’m going in this direction, down this street, around this obstacle, and across this river.

If you provide the user with only the details, and you do not show them the big picture, they cannot build a mental model of what needs to happen. Providing the big picture makes the user more resilient. If they make a mistake, they will be able to understand what went wrong fundamentally, instead of only at the superficial level.

Your next recommendation for us is A Mind for Numbers by Barbara Oakley. This was a book that accompanied a very successful Coursera MOOC (Massive Open Online Course). Can you tell us more about this book and how it can help technical communicators?

I highly recommend the course as a companion to this book. It can be challenging to get people to approach math because it is a topic that most people are afraid of, and Oakley does a great job of making it seem less intimidating. A few of the key concepts in this book come back to analogies.

Oakley identifies two modes of thinking: focus mode and diffuse mode. We might be in focus mode when we’re learning math, crunching through arithmetic, and solving problems step by step. We are in diffuse mode when we’re looking for connections and analogies and trying to form a big picture. We need both of these modes.

Most people think only about focus mode, because this engages us in the type of learning that prepares us for a test; however, part of learning requires getting familiar with diffuse mode. Oakley demonstrates that diffuse mode is equally integral to learning. If you’re explaining a topic (and particularly if this topic is new to the listener), you might share some of the analogies that have helped you and let people explore them instead of discussing it in purely technical terms.

Another key concept she discusses is chunking, which involves breaking information or concepts into more easily digestible pieces. It is useful to look at the big picture in the beginning. Then, you work on these pieces or chunks and get to grips with them, and then step back and see how they connect.

Chunking might involve using mind maps or making lists. You can isolate individual skills to work on and then come back to the big picture. Chunking effectively allows the learner to toggle between focus mode and diffuse mode.

The accompanying online course is titled “Learning How to Learn.” When you’re trying to teach someone a concept that’s new to them, do you first learn the material and only teach it once you’ve mastered it? Or is there a value to teaching others material that you’re still actively learning?

It’s important to have both halves. It would be difficult to be a chef if you didn’t taste the food you were preparing. As a communicator, if you’re always speaking and never listening, you might miss some of the insights. I think this course is about seeing the learning process from both sides.

When you impart information, you have to put yourself in the place of the person who is receiving it. It all comes back to empathy. You have to remember what it’s like to see something for the first time. It is important to understand things from both perspectives.

When I’m learning, I’ll make notes as I go along, especially of moments of confusion and a-ha! moments. I love those epiphanies, when something complex suddenly seems simple because you encountered the right example or the right metaphor. I’ll make note of that and think, now I have an example to use. I’ll be able to share what the difficulty was and how I resolved it. As the time passes between learning something and teaching it, the curse of knowledge sets in. You’re likely to forget some of the little steps you made, so I think it’s important to keep track of them.

Having said that, I don’t feel comfortable teaching something until I’ve gone over it thoroughly and quizzed myself on it. We all make mistakes, but I try to minimize that as much as possible. While I won’t teach material I’ve only just learned, I want to keep in mind the sense of discovery I enjoyed during the process.

Your next recommendation for us is On Writing Well by William Zinnser. This is a very popular book about writing in general. Why do you think it’s applicable and relevant for technical communicators?

Integral to communication is execution. You may have a wonderful idea for a song, but you still need to be a good musician to make that come across. You should play the notes in key and on time; your instruments should be in tune. Having a great concept is not enough, you must explain it fluidly and fluently.

While the book contains sections on technical communication, there’s a craft of communication, a craft of writing, and we need to build up those skills. This book contains the best general writing guidance.

Also, the writing process is a thought process. It’s not as if you have a perfectly formed thought and then you write it down; the act of writing shapes your ideas and forms new ones, and you build on that. Being more comfortable with writing in general allows you to brainstorm on paper, and to come up with new and better ideas.

Your next recommendation for us on technical communication is The Non-Designer’s Design Book by Robin Williams. What does this book do well?

This is a great example of ‘show, don’t tell.’ This design book teaches you the principles of design by showing you examples of good design and bad design. As well as going into the specifics about colors and other design elements, Williams explains the high-level principles, which she acronymizes as CRAP: contrast, repetition, alignment, and positioning. She provides various images that you can assess in terms of these principles, thus gaining fluency in them.

By the way, acronyms are a good example of chunking, as described in Oakley’s book. An acronym breaks a concept into small pieces and makes each piece memorable.

Williams does an excellent job of communicating the low-level details and the high- level principles and giving you examples to work through on your own. It’s a very short and concise read, which is merciful for the reader. As writers, we may imagine people hanging on our every word, but readers want the information to be delivered as quickly as possible. Books can be entertaining, but the goal is to help the reader to achieve the desired outcome. Keeping it short and sweet is definitely key.

It does feel like much of the art of good communication is about making what you say memorable, so that people can access it later.

We’re lucky if we can remember three things from a book we’ve read. How many books have you read? You might have retained a sentence or two. If you can make that sentence content-packed by using an acronym, then that’s perfect. A year after someone’s read a book, what can you hope that they remember? If it’s an acronym and they know how to use it, that’s excellent.

Your last recommendation for us is The Happy Body by Aniela and Jerzy Gregorak, both of whom have won multiple World Weightlifting Championships. This is a book about posture. Why do you think this is a useful book for technical communicators to read?

It’s a great example of technical communication. You might think posture would be very difficult to communicate through a book. One might assume that to communicate about posture, you would need coaching videos and so on. But a book is a very inexpensive way to communicate, and it’s lasting, so we wish we could convey the information that way.

Aniela and Jerzy Gregorek have distilled their posture fix into one exercise. It’s essentially an overhead squat. You squat down with your arms stretched overhead in a doorway, and you try to go as low as you can while keeping your arms up. That helps align your spine. They distilled all of their knowledge on anatomy, physiology, and exercise into one move that, done enough times, will fix your posture. It has done for me. I think it’s a great example of taking something which was very intricate and complicated and finding the shortest path through that topic.