|
–Geoff-Hart.com:–Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Resources --> 2006 --> Effective outlining: designing workable blueprints
Vous êtes ici : Ressources --> 2006 --> Effective
outlining: designing workable blueprints
By Geoff Hart
Previously published as: Hart, G. 2006. Effective outlining: designing workable blueprints for writing. Intercom September/October 2006:18–19.
There's a famous saying used by carpenters: “Measure twice, cut once.” What they mean is that it pays to plan carefully before you begin the actual work; that way, you'll only have to cut a potentially irreplaceable piece of wood once because you'll have done the work necessary to cut it correctly the first time. Fail to invest that time, and you may ruin the wood—and incur a large expense in time and money to replace it; at best, you'll have to make the cut again, wasting time and sweat. Those of us who grew up using typewriters instead of word processors remember the pain of having to retype an entire page or a long range of pages because we'd omitted something important somewhere in the middle.
As modern writers, we tend to ignore the carpenter's wisdom because we work with words on the screen, for which there appears to be no cost: electrons are cheap, and any mistake can be undone quickly. Or so we assume. In fact, failing to plan can lead to considerable wasted time, whether because we’ve created an ineffective sequence that requires considerable resequencing later, or because we've spent time writing about things that don't need to be described at all. Lack of planning can also lead us to make several attempts to create an acceptable draft even for things that are essential and need to be described. And if our colleagues review the unacceptable drafts, we waste their time reviewing text that will have to be reworked—not to mention the credibility we sacrifice each time we send a poorly prepared document for review.
Just as architects create and carefully review a blueprint before they begin construction on a house, technical communicators can avoid the abovementioned problems by beginning their work with an outline. But not all outlines are created equal, and an effective outline—one that covers all the essential points and minimizes time spent reviewing and revising the resulting manuscript—is more than just a hasty sketch of the table of contents. There are three steps to creating an effective outline:
Just as architects start the design process by determining whether they will be designing a concert hall, apartment building, or residence, writers must rough out the basics of their manuscript. For example, brainstorming what will appear in the table of contents of a proposed manual is a great start in preparing an outline but unfortunately, many writers stop there. The resulting outline is no more effective than if you were building a home and asked your architect to produce a design with three bedrooms and two bathrooms—without specifying where those rooms should go, how large each should be, the numbers of windows and closets required, and the desired functional relationships between the rooms. Without this information, the architect will undoubtedly produce a satisfactory house, but not a home that meets your unique needs.
When I work with authors who have difficulty writing, I sit down with them to help define their audience and their goals for the manuscript; those goals are the audience needs they must meet, and understanding those goals provides powerful insights into how to address their audience. In cases where we don’t already have a familiar, standardized outline designed to meet the needs of a specific audience, such as the journal article schema used by scientists, I use the “five Ws” approach. Asking who, what, when, where, and why? helps to identify the most important characteristics of the audience and how these characteristics will affect the writing. This information can then be quickly rearranged to provide an effective framework for the outline, just as a concrete foundation provides the base for the framework of a house.
The next step in building a house is to create that framework and add the cladding. In this part of the outlining process, the goal is develop a list of everything that must be presented within the broader areas defined in the previous step. In providing these details, I refuse to accept the kinds of vague generalities you'll often find in ineffective outlines. For example, weasel phrases such as “I'll compare the productivities of methods A and B” must be replaced with the results of that comparison: “Method A was 25% more productive than method B.” In the first case, the author has provided nothing more than a statement of intent; in the second case, the author has provided the results of that intention. A short list of points created in this manner provides the beginnings of a story, and because the points are brief and focused, it’s easy to confirm whether their sequence makes sense and to identify any gaps.
Another advantage of this approach is that it helps us exclude useless information that doesn't answer reader questions, producing a decent first draft of the manuscript that will require minimal additional work. In the worst-case scenario, if there is no time to write anything more than the outline, then the sequence of definitive, detailed statements that results from this step provides an acceptable, if somewhat spartan, description of everything the reader needs to know. Perhaps the result isn’t as elegant or refined as it would be with considerably more revision, but the content will prove satisfactory—and in most of the writing done by technical communicators, content is more important than form. In the best case, of course, there will be time to refine the presentation of these key thoughts and conclusions, just as the builder brings in painters and interior decorators only after the house is watertight and functional.
The final step in producing an effective outline is to obtain a reality check from all stakeholders who will approve the final document: these include any subject-matter experts, audience representatives, and managers who must sign off on the final document. This review helps to ensure that we haven't missed anything important, misunderstood anything, or included irrelevant details that would waste our time if we chose to document them fully. The ideal result of this review process will be a blueprint that lists everything we must write and nothing that we shouldn't write, and thus provides a clear understanding of the writing tasks that lie ahead. This review minimizes the most time-consuming and difficult parts of the final revision process: adding missing information as the deadline approaches and we must scramble to research that information, and revising sections that are factually incorrect or misleading. It also makes the best possible use of each reviewer's time, since the content and structure are already known to be largely correct, and all that remains to review is how the writer has implemented the design.
The hardest part of our work as writers is the thought process that identifies the needs of our audience and develops a design to meet those needs. The actual writing is something we can be trusted to get right with few revisions, but if the design is flawed, much of our writing and much of the review of that writing will be wasted effort and will have to be redone. The approach described in this article works because it focuses on the needs of the audience, which includes both those who will actually use the document and those who will approve the document for release to those users. As a result, it makes effective use of the writer's, reviewer's, and manager's time. Moreover, it builds a sense of collaboration among stakeholders in the creation of effective documentation, since writers work together with all their clients rather than working in isolation.
Of course, the reality is never quite so neat and tidy, particularly when the writing task involves documenting an evolving product such as software. In that case, outlining sometimes achieves another, wholly unexpected benefit: it helps the product developers see the bigger picture. In some development projects, individual developers may be tasked with creating only a small subset of the larger product, and the only people who see the big picture are the technical communicators who created the outline. Even the managers who are expected to see the big picture may sometimes lose sight of it when responding to demands for new features from the sales staff or marketing department. Working with the developers and their managers to create an effective outline early in the project won't prevent feature-creep and endless revision of key components of a product, but it can sometimes mitigate both problems by helping these key people see where new things could fit logically within the design or recognize the disruptive effects of changes.
©2004–2024 Geoffrey Hart. All rights reserved.