I write a pretty good amount of content. These days, I edit almost as much as I write. And in doing so, I’ve picked up on some interesting trends in how people write. This has led me to mentioning a few tips and tricks, if I can bore you with the details for a bit:
- Define the goal. What do you want to say? The text on the back jacket of most of my books was written before I ever wrote an outline. Sometimes I update the text when I’m done with a book because the message can change slightly with technical writing as you realize some things you’d hoped to accomplish aren’t technically possible (or maybe not in the amount of time you need to use).
- Make an outline. Before you sit down to write a single word, you should know a goal and have an outline that matches to that goal. The outline should be broken down in much the same way you’d lay out chapters and then sections within the chapter.
- Keep your topics separate. A common trap is to point at other chapters too frequently. Technical writing does have a little bit of the find your own adventure aspect, but referencing other chapters is often overused.
- Clearly differentiate between section orders within a chapter. Most every modern word processing tool (from WordPress to Word) provides the ability to have a Header or Heading 1 and a Header or Heading 2. Be careful not to confuse yourself. I like to take my outline and put it into my word processing program and then build out my headers from the very beginning. When I do so, I like for each section to have a verb and a subject that defines what we’re going to be doing. For example, I might have Header 1 as Install OS X, with Header 2 as Formatting Drives followed by Header 2 as Using the Recovery Partition followed by Header 3 of Installing the Operating System.
- Keep your paragraphs and sentences structured. Beyond the headings structure, make sure that each sentence only has one thought (and that sentences aren’t running on and on and on). Also, make sure that each paragraph illustrates a sequence of thoughts. Structure is much more important with technical writing than with, let’s say, science fiction. Varying sentence structure can keep people awake.
- Use good grammar. Bad grammar makes things hard to read and most importantly gets in the way of your message getting to your intended audience. Strunk and White’s Elements of Style is very useful if you hit a place where you’re not sure what to write. Grammar rules are a lot less stringent with online writing, such as a website. When it comes to purposefully breaking grammatical rules, I like to make an analogy with fashion. If you show up to a very formal company in $400 jeans, they don’t care that your jeans cost more than most of their slacks; they just get cranky you’re wearing jeans. Not everyone will pick up on purposeful grammatical lapses. Many will just judge you harshly. Especially if they hail from the midwest.
- Define your audience. Are you writing for non-technical users trying to use a technical product? Are you writing for seasoned Unix veterans trying to get acquainted with a new version of Linux? Are you writing for hardened programmers? The more clearly you define the audience the easier it is to target a message to that audience. The wider the scope of the audience the more people are going to get lost, feel they’re reading content below their level, etc.
- Know your style guide. According to who you are writing for, they probably have a style guide of some sort. This style guide will lay out how you write, specific grammar styles they want used, hopefully a template with styles pre-defined, etc. I’ve completed several writing gigs, only to discover I need to go back and reapply styles to the entire content. When you do that, something will always get missed…
- Quoting is important when writing code. It’s also important to quote some text. If you have a button or text on a screen with one word that begins with a capped letter, you don’t need to quote that in most style guides. But if there’s only one word and any of the words use a non-capped letter or have a special character then the text should all be quoted. It’s also important to quote and attribute text from other locations. Each style guide does this differently.
- Be active. No, I’m not saying you should run on a treadmill while trying to dictate the chapter of a book to Siri. Use an active voice. For example, don’t say “When installing an operating system on a Mac you should maybe consider using a computer that is capable of running that operating system.” Instead say something like “Check the hardware compatibility list for the operating system before installation.”
- Be careful with pronouns. When I’m done writing a long document I’ll do a find for all instances of it (and a few other common pronouns) and look for places to replace with the correct noun.
- Use examples. Examples help to explain an otherwise intangible idea. It’s easy to tell a reader they should enable alerts on a system, but much more impactful to show a reader how to receive an alert when a system exceeds 80 percent of disk capacity.
- Use bullets or numbered lists. I love writing in numbered lists and bullets (as with these tips). Doing so allows an author to most succinctly go through steps and portray a lot of information that is easily digestible to the audience. Also, if one of your bullets ends with a period, they all must. And the tense of each must match.
- Use tables. If bullets are awesome then tables are the coolest. You can impart a lot of information using tables. Each needs some text explaining what is in the table and a point that you’re usually trying to make by including the table.
- Judiciously use screen shots. If there’s only one button in a screen shot then you probably don’t need the screen shot. If there are two buttons you still probably don’t need the screen shot. If there are 20 and it isn’t clear in the text which to use, you might want to show the screen. It’s easy to use too many or not enough screen shots. I find most of my editors have asked for more and more screens until we get to the point that we’re cutting actual content to fit within a certain page count window. But I usually have a good idea of what I want to be a screen shot and what I don’t want to be a screen shot from the minute I look at the outline for a given chapter. Each screen shot should usually be called out within your text.
- Repetition is not a bad thing. This is one of those spots where I disagree with some of my editors from time to time. Editors will say “but you said that earlier” and I’ll say “it’s important.” Repetition can be a bad thing, if you’re just rehashing content, but if you intentionally repeat something to drive home a point then repetition isn’t always a bad thing. Note: I like to use notes/callouts when I repeat things.
- White space is your friend. Margins, space between headers, kerning of fonts. Don’t pack too much crap into too little space or the reader won’t be able to see what you want them to see.
- Proofread, proofread, proofread. And have someone else proofread your stuff.
- Jargon, acronyms and abbreviations need to be explained. If you use APNS you only have to define it once, but it needs to be defined.
- I keep having editors say “put some personality into it” but then they invariably edit out the personality. Not sure if this just means I have a crappy personality, but it brings up a point: while you may want to liven up text, don’t take away from the meaning by doing so.
- Don’t reinvent the wheel. Today I was asked again to have an article from krypted included in a book. I never have a problem with contributing an article to a book, especially since I know how long it takes to write all this stuff. If I can save another author a few hours or days then they can push the envelope of their book that much further.
- Technical writing is not a conversation. Commas are probably bad. The word um is definitely bad. Technical writing should not ramble but be somewhat formal. You can put some flourish in, but make sure the sentences and arguments are meaningful, as with a thesis.
- Be accurate. Technical reviewers or technical editors help to make sure you’re accurate, but test everything. Code, steps, etc. Make sure that what you’re saying is correct up to the patch level and not just for a specific environment, like your company or school.
- Use smooth transitions between chapters. This means a conclusion that at least introduces the next chapter in each. Don’t overdo the transitions or get into the weeds of explaining an entire topic again.
- Real writers publish. If you write a 300 page document and no one ever sees it, did that document happen? If the document isn’t released in a timely manner then the content might be out of date before getting into a readers hands. I like to take my outline (step 2) and establish a budget (a week, 20 hours, or something like that).