A good bookend reflects the beginning....

I taught a Technical Writing course to a bunch of college kids last fall (stop me if you’ve heard this story). The purpose was to get them ready for the business writing they’d have to do in their professional careers, so I spent a semester teaching them about resumes and project proposals, memos and business letters, and before every class I’d put in hours figuring out my lecture. At every step of the way I wanted to make sure they understood all aspects of the documents they were working — when to use them, how to write them, why to care.

Then it came time for the final exam, and I had one of my brilliant ideas. Instead of giving them some big multiple-choice test, I decided to have them demonstrate, in a more practical way, the things they’d been learning all along. I told them a couple weeks in advance what to expect, then when the final exam period rolled around, I had them convert some assigned information into a clearly-defined document type (in this case, a wiki). The twist was that this time I wouldn’t tell them how. It was all up to them to figure it out.

I figured by that point they wouldn’t have any trouble. I’d shown them the process plenty of times. I’d dumped a ton of detailed examples on them, so I was confident my students could handle the challenge. So confident, in fact, that I didn’t do any preparation for that class period. I didn’t brush up on the wiki format, didn’t put together any general guidelines or notes…didn’t even really stop to consider all the things that could go wrong. I just showed up to class, told them where to find their source material and how much time they had to make me a wiki out of it, and then I sat down at my desk to watch brilliance happen.

You could have heard a pin drop in the silence that followed. I waited for them to sprint into action — or at least start talking it through — but no one moved. Sixteen pairs of eyes stayed fixed on me, waiting for the instructions I hadn’t bothered to prepare.

How to Write a Conclusion

How’s that for a happy ending? After fifteen weeks of teaching these kids — guiding them from total obliviousness through all the major topics, techniques, and types of technical writing — I got to their most important class (grade-wise), and my final, lasting impression, and let them fall flat on their faces.

How often have you made the same mistake, in your writing? You figured you’d explained the issue well enough in your introduction, you’d provided all of the relevant information in your body paragraphs. Your readers could figure it out, right? They’re all smart people. So what’s the point of laboring over a conclusion that’s probably not even necessary?

The point is to avoid those blank stares. The point is to drive your readers to action (not vague confusion). A good conclusion finishes the message you’ve been building throughout the document. It’s your last word to your students before they walk out that door forever. What are they going to think of you, and of what you’ve had to say?

The key to writing strong conclusions, just like good introductions, is to think about your readers. Consider their experience as they approach the end of your document, and tell them what they need to know to get the most out of your work.

Some Examples

How do you know what your readers need? A good writer takes some tips from his document type.

• If you’re writing a story, your reader needs resolution
• If you’re writing a humorous anecdote, your reader needs a punchline.
• If you’re writing a persuasive piece, your reader needs a call to action.
• If you’re writing an essay, your reader needs to know what’s the point.

More than that, your resolution should be a part of your overall document structure. It’s not a separate note tacked on to the end but an integral piece of the overall document design. In other words, you should be writing toward your resolution from the very beginning of the document.

The Conclusion in the Body

Think about your conclusion when you’re choosing your organization method. When you’re figuring out which supporting ideas you want to include in the body of your document, remember that your conclusion should flow out of those ideas, not just be a restatement of them.

That’s a common problem new writers have, and I hinted at it back when I introduced this series. If you find yourself asking, “Didn’t I already say all this?” go back and check the document body. Chances are good you already wrote the conclusion — as your final body point.

The problem with that is that you probably weren’t in “Conclusion Mode.” You were still dumping information, not guiding your reader to the end of your message. In that case, you’re going to need to either cut out that final point and rewrite it in your conclusion, or work on revising the body paragraph to make sure it does everything a conclusion needs to do.

The real way to make conclusions easier in the future is to learn how to write a document that supports a conclusion, and make sure the final bits end up in the right place. Learn to recognize the difference between supporting evidence and your argument’s point, and save that point to use as the meat of your document’s conclusion.

The Conclusion in the Intro

Of course, it’s not just about what you say, but also about how you say it. That’s part of what I meant when I talked about “Conclusion Mode.” There are some style tricks you can use to make sure your conclusion has the right feel for your reader. That’s almost as important as the information, creating a sense of closure and purpose to the overall document.

A call to action achieves that well, but one of the most powerful techniques for wrapping up a document smoothly is the callback — sometimes referred to as bookending — when you refer back to your introduction to tie your whole message into one cohesive bundle.

To do that well, you have to do it on purpose. Write an introduction that draws the reader in, but leave it open. Find ways to keep it in the reader’s mind throughout the body, so it’s still fresh when you turn back to it.

The End

That was my saving grace, in the Tech Writing final. I’d started out the first class by dividing them into groups, each specialized in certain aspects of documentation, and kept that up throughout the semester. On that last day, as quiet seconds stretched into awkward minutes, those groups suddenly pulled together. The guys on the back row figured out the system, the group on the left came up with a method, and the group on the right put it into practice. It took them the whole class period, but by the time it was over, they’d made something amazing.

When you do it right, sometimes the end just takes care of itself.