By Geoff Hart, Contributing Author
Previously published at NAIWE website (www.naiwe.com) as Hart, G. 2021. Creating truly effective outlines.
Editor’s note: This is a revised and expanded version of an April 2008 presentation that the author presented for STC Milwaukee. Although intended for editors who do substantive editing, it offers useful guidance for writers who need to outline before they begin writing.
One thing I discovered early in my editing career was that few writers learned how to create truly effective outlines. Sure, everyone learned to list the section titles in a plausible order or adopt a pre-existing order, such as starting with the executive summary and ending with the appendices. But the problem with this approach is that it does little or nothing to make the writing process efficient and often ends up wasting the writer’s time when it turns out that a lot of revision is required.
Helping writers stay on course is where we editors enter the picture: Through developmental editing, we help writers focus their efforts right from the start so they can write faster and more effectively. If we do our job well, we won’t have to shuffle chunks of the document around late in the revision process because most of the text will already be in the correct place. We won’t have to point out major omissions because there should be none.
We’ll be able to focus on the clarity of the language.
A good outline is like an architectural blueprint: It tells you where every part fits and its relationships with the other parts. It goes far beyond merely saying “a room goes here”; it provides specific details of what kind of room and how that room relates to all the other rooms. Writing without a strong outline is like trying to build a house, but without knowing how many rooms, their functions, their spatial relationships, or their sizes. You’ll end up with a building at the end of the process, but it might be an office building. Even if you end up with a house, it’s not going to be a very comfortable or livable home.
When I first gave the presentation on which this article is based, I designed it for technical writers, most of whom were documenting computer software and hardware, or working for technology companies. Hereafter, I’ll refer to that type of manuscript as documentation. But the approach I’ll describe can be used for many other types of writing, including education (e.g., teaching a subject such as chemistry), creative nonfiction, and fiction. I’ve retained the documentation content because the examples will be familiar to most readers, who grapple daily with their computers and related software. But I’ll expand the method to include fiction so if you don’t edit manuscripts from a technology-related field, you’ll see how the same basic approach works in a very different genre and, mutatis mutandis, across a range of genres.
Note: If you hang out with fiction authors, you’ll eventually be asked whether you’re an outliner or a pantser. In this context, pantser comes from “by the seat of your pants” and refers to authors who prefer to let their stories evolve organically rather than strapping them to the rack while they torture them into shape. Pantsing works very well for some writers, but tends to work best for someone who has a clear idea of what they hope to achieve with their story. The best pantsers seem to have some kind of subconscious overall outline that guides their work.
Although I’ll focus on the role of editing in this article, the advice also works very well for writers. The main difference is that instead of working with an editor, you may be self-editing long before someone else has a chance to edit your manuscript.
Why outline?
an The whole point of an outline is to help you define all the components that a manuscript requires and the most effective way to assemble them. The ideal process is for author to sit down (in person or otherwise) with their editor to discuss the outline and ensure that it’s effective before beginning to write. While authors are learning to outline, it may be more productive creating their outlines interactively with their editors. At my previous employer, this collaborative outlining was a key component of our report-production process (Hart 2006a, 2011a). This approach proved to be far more efficient then letting authors submit a finished manuscript and leaving me to infer the manuscript’s outline.
There are several criteria for a great outline:
- It provides a precise blueprint for the writing.
- It focuses work during the writing and revision stages.
- It reduces rework. As the carpenters say, “plan and measure twice, cut once!”
- It permits flexibility when the inevitable revisions arise.
For documentation, effective outlines:
- Organize the content around user goals and the tasks they must perform to reach those goals. These tasks form task clusters. For example, creating a page layout in desktop publishing software requires an understanding of the task cluster that includes defining the page size, margins, gutters, and paragraph characteristics (spacing before and after, margins, line spacing, widows, and orphans).
- Comprehensively list all product features that support these goals, grouped logically by task cluster. This is often called an inventory.
- Rely on architectures that make the form and content of each topic consistent with all other topics of the same type (e.g., multi-step procedures).
- Concisely summarize what you’ll write. That is, each part of an outline is specific, not general; it describes what you’re going to write in enough detail that it is distinct from all other topics of that type.
Fiction is more diverse and thus, more difficult to standardize. Nonetheless, the equivalents to a documentation outline might be:
- For each section or chapter, define the character’s goals, your goals for the character, and how to reconcile the two.
- List all the constraints and opportunities created by previous decisions (whether by the character or by yourself). List the actions or happenings required to lead into future chapters.
- Define any recurring patterns you’ll use for a given type of chapter. For example, one type of chapter may begin with a challenge created by the cliffhanger in the previous chapter, continue with the rising action until the character or characters are forced to act, then conclude with a denouement that gives the characters time to catch their breath before you create yet another cliffhanger. Harrison Demchick (2021) provides some good insights into this process.
Before you can start creating an outline that achieves these goals, it helps to understand the differences among inventories, architectures, and outlines.
Inventories, architectures, and outlines
Let’s start by defining some key terms. An outline is not an inventory. An inventory only defines what topics you’ll include, although it should be comprehensive. An outline is not an architecture. An architecture summarizes the categories of information you’ll include in each topic (for documentation) or each chapter (for fiction) and the relationships among them. An outline uses an inventory to list all the topics you’ll include in the manuscript, and an architecture to summarize the relationships among the topics and their components. For documentation, the outline defines what must appear in each topic (inventory) in what order (architecture).
It’s also helpful to specify what should not appear. For fiction, an outline defines all the key events that will occur between the start and end of the story, the decisions characters make that are caused by or lead to these events, the consequences of those decisions for subsequent chapters, and how the characters change in response to those consequences. However, the outline must also state what you’ll write about each topic or in each chapter. (The details will come later, once you begin writing.)
Note for technical writers: An architecture functions much like a document type definition (DTD) or schema in XML or SGML authoring.
Sound simple? Sort of. Most writers and many editors forget two key things when they plan an outline. First and foremost, we must remember the audience’s needs. Understanding those needs will help us develop a user-centered document structure that focuses on the reader. Second, for writing that occurs in an institutional context, we need to obtain approval from all stakeholders — anyone who will have a chance to reject a manuscript or send us back to the drawing board for revision. Gaining approval for the overall plan of attack before you begin writing greatly reduces the frequency of unpleasant surprises late in the review and revision cycle. In fiction, the equivalent to the management and expert review of a document is the review of a pitch (story proposal) by your agent or by a publisher’s acquisition editor. This is rarely required for short fiction, but is often essential for long-form fiction such as novels.
Understand audience needs and gain stakeholder approval
The role of your audience is easiest to understand for documentation: The users of a product read documentation to find solutions to a problem. Thus, outlines must support finding solutions and solving problems. Product-centered documentation, which is organized around the product’s features, only describes the product features and forces users to sort through a potentially long list to find the features that might conceivably solve their problem; that is, it forces them to infer how to combine those features to achieve their goal. The more complex the product being documented, the larger and less fair the burden this places on the product’s user. Sure, it’s easier for the writer. But as Richard Brinsley Sheridan noted in 1772, “you write with ease, to shew your breeding; but easy writing’s vile hard reading.”
In contrast, user-centered documentation focuses on the user’s goals, and groups descriptions of the product’s features to help the user attain those goals. The difference is night and day. In product-centered documentation, you might as well just list the product’s features in alphabetical order, since you’re not attempting to present them in an order that supports the user’s goals. But in user-centered documentation, it’s necessary to carefully consider how your audience plans to use the product. That use will define the sequence of tasks as well as the sequence within each task. For example, a plausible sequence for desktop publishing software would be to define the characteristics of the pages that will hold the paragraphs, define the characteristics of the paragraph types that will hold the words (e.g., headings vs. body text), and then define the typographic characteristics that will shape the sentences and words in each paragraph.
Note: Reference manuals can be product-centered because their purpose is to define how each feature works — for an audience that already knows what features they need to use. For some types of documentation, such as dictionaries (or glossaries) and encyclopedias, this structure may be a good choice.
Fiction readers have more abstract needs. They are reading to be entertained, so their needs don’t relate to tasks. The editor’s challenge then becomes how to understand the literary tools the author will use to present a character’s progress through the story. For example, the plot might lead a character to a crisis point where the character’s choices are constrained by some past event. They might confront a large and hideous spider in the bedroom and be forced to kill it, defenestrate it, or deport it, but to do so, they must overcome their arachnophobia. One approach would be to describe the event that triggered that fear, then move forward through many chapters to the present spider-induced crisis. This spider is the horror equivalent of Chekhov’s gun: “If in the first act you have hung a pistol on the wall, then in the following one it should be fired.”
Alternatively, you could end a section or chapter with the character’s gasp of horror, use a flashback to reveal why the spider represents a problem, and then return to the present to see how our heroic character overcomes this past trauma — or fails to do so. In this case, the outline would clarify that the new words actually appeared in the past. To use the term I defined previously, the architecture for flashback chapters states that chapters must begin with a few words to clarify that the timing of events changed: “Nearly half a century ago, when Geoff was a child, a spider bit him. He did not acquire superpowers, but he did learn to fear spiders.”
In terms of the audience’s prior knowledge, writing fiction in different genres allows writers to make certain assumptions about what their readers understand. In science fiction, we can discuss starships without defining what one is, whereas in fantasy, we can discuss dragons without a definition. Neither term would be appropriate in detective fiction without adding a few words to explain the meaning. When, as editor, we feel those audience assumptions won’t be met, it’s our job to point out the problem and suggest ways the author can provide the missing knowledge and where those ways fit within the outline.
How to identify user needs
There are many ways to identify user needs. First, and most common, if we lack access to or familiarity with the readers of our manuscripts, we can work by inference — that is, we must imagine ourselves in the reader’s role and pay attention to our thoughts when we/they confront a task. This way of stepping into the reader’s shoes is often described using the term persona, which means a description of the person that’s so vivid we can easily answer the question “What is Geoff thinking and what would he do in this situation?” Making our audience real deepens our understanding of who they are and what their needs are. It also builds empathy and motivates us to care enough about their needs that we try to meet them. For any given product, there may be multiple personas, and each one’s needs must be accounted for. (To learn more about personas, see Hart (2006b, 2011b,c).)
The “five W’s” approach used by journalists is another way to learn about our audience. It, too, relies on inference. In this approach, we ask who will use the product, why they are using it (goals), when and where the use occurs (context), and what they must do to accomplish those goals within that context and under the constraints it imposes. Each of these affects the contents and sequence of an outline. (To learn more about this approach, see Hart (1996, 2002, 2011b,c).)
In addition, we can consult existing references such as computer magazines, “for dummies” books, and the like. The types of help resources that readers buy and read reveal the problems they face, and the range of solutions chosen by other writers. Better publishers have the resources to understand their audiences and design books that sell many copies because of how well they meet their audience’s needs. Such books, therefore, represent a good resource for learning about the needs of those groups of readers.
A third approach, and possibly the optimal one, is to actually talk to the audience and learn how they use the product being documented. Rather than inferring their needs, we can come right out and ask them. The most sophisticated form of this approach, which requires some training, is called contextual inquiry, which is the fancy way of saying direct observation of workers in the context in which they work. In essence, it means that you watch real users using your product in a real workplace to learn what they must accomplish and how they think about that task. This approach lets you build a sophisticated persona for each type of user and design a documentation structure (an outline!) that meets their distinct needs. Contextual inquiry isn’t always possible, since it can require visits to the audience’s workplace or bringing them to you so you can study their behavior in your own test facilities. Fortunately, there are less expensive and more accessible options. Most products now have online discussion forums where you can see the kinds of questions people ask, learn how they think about problems, and learn which solutions are most effective. (If no such forum exists, create one!)
A fourth approach involves reports from other people who work directly with the audience, such as technicians who fix malfunctioning products, corporate trainers, and a company’s technical support staff. All of these people can tell you about the problems that users face and solutions that have been proven effective in the real world.
Once we know these needs, we can revise our outline to account for them. For example, if we know that all users of our desktop publishing software are graphic artists, we don’t need to explain page layout and typography, though we may need to clarify where these tasks are addressed by the software (e.g., menu, toolbar, and palette locations). In contrast, if the users are office workers who have no formal design training, we’ll need to explain more about why certain features should be used (e.g., typography) and how.
In fiction, we can learn most of what we need to know about user needs from reading extensively in the author’s chosen genre. This provides basic familiarity with the terminology used by most authors , the most common plot structures, and the types of expectations that must be met. You can find out how fiction readers read easily enough, but rather than contextual inquiry, attend writers’ workshops where writers learn the tools of their trade or conventions where fans of a particular literary genre gather to discuss their favorite and least-favorite stories. Online reviews, such as those at Amazon or Goodreads, also provide insights. For work where others have done the research for you, consult respected writers’ guides and read reviews by skilled and insightful reviewers to learn what they look for. However, be aware that reviewers take a very different approach to reading than people who read solely for pleasure.
Gain approval from all stakeholders
For documentation, peer review is essential because there’s no other easy way to ensure that you’ve gotten the details right, but many companies rely on peer review because they aren’t willing to hire an editor. Unfortunately, this kind of review is generally insufficient because more people than the product’s designers and the writer’s manager must approve the final documentation. Discovering that you’ve failed to produce a product that satisfies the stakeholders only when you reach the end of a long writing, review, and revision process can be disastrous.
The solution is surprisingly simple: Identify all stakeholders who can approve or reject your work before you begin to produce the outline that will guide your writing. These people include the technical experts, who will review your manuscripts for correctness and completeness; the product’s manager; the writers’ manager, who will review the manuscripts to ensure that they meet corporate standards; training and technical support staff, who will confirm that the manuscript supports their needs; marketing, who will ensure that their needs to evangelize a product are met; lawyers, who ensure that the manuscripts meet legal standards and requirements; and, potentially, managers who run all the way up the corporate hierarchy to a director or vice president. If you’re lucky, the approval chain has far fewer links and ends with a middle manager, but in small companies, the approval chain may run right to the top of the organization chart.
Each of these stakeholders should critique and approve your outline before you invest considerable time doing the actual writing. Problems such as omission of details you think are unnecessary but that they consider important must be identified so the outline can be revised to meet their criteria. Where needs are contradictory, negotiation will be required to solve the contradiction. I’ve used this approach to drastically reduce the time required for approval of documentation (Hart 2006a, 2011a). Surprises are still possible, but there will be far fewer of them if everyone strongly supports your blueprint right from the start. And the surprises will usually be far less serious and easier to fix.
In fiction, there are fewer stakeholders. There’s generally no complex corporate hierarchy, except when you’re writing for a big publisher. Then, you’ll need to pitch your outline to an acquisitions editor and they’ll deal with the publisher on your behalf. However, for both novels and shorter work, many authors enlist a group of beta readers to review the writing before it goes to an acquisitions editor. Note that although the list of stakeholders is shorter, that doesn’t mean the approval process will be simpler. Creative people tend to have strong opinions about how fiction should be written, and it can be tricky finding compromises between an author’s vision and what the publisher will accept. As in most other forms of editing, one of your roles as editor will be to act as the author’s advocate and defend their approach.
Comprehensively list what you’ll need
For product documentation, create an inventory of all the information you’ll need to include.
- For software, list all menu names and all items provided under each menu; all toolbars or palettes and the associated tool icons; and all items in the dialog boxes accessed via these menus, toolbars, and icons.
- For hardware, list all control panels, all physical switches, all buttons, all slots and tabs, and anything else the user may need to manipulate to operate the device. For the hardware’s software components, list the same things described in the previous bullet point.
- For both software and hardware, list all physical things (tools) and metaphysical things (software, knowledge of concepts) required to support a reader’s use of the product.
You can now group the items in your inventory by allocating them among the tasks they support. If something is essential to the completion of more than one task, repeat that information for each task instead of asking readers to hunt through the documentation to find that information. This is easiest if you use a writing tool that supports single-sourcing (i.e., creating a chunk of information once, then reusing that chunk wherever it’s needed). For each task within a task cluster, refer to the architecture I described earlier in this article to figure out how to assemble everything.
If you’re assisting a fiction writer, this part of the editing process resembles the task of creating a story bible. Story bibles contain all the facts that mustn’t change over the course of the story, such as a character’s eye color and handedness, and things that should change, such as their knowledge and thought patterns. For example, a story bible might contain the following.
- Characters: their physical and emotional characteristics.
- Psychology: how the characters think and how that changes in response to the story’s events.
- Physical locations: characteristics such as geography, climate, and the relationships they imply (e.g., distances between places). This will shape things like travel between cities and movement within cities.
- Possessions: the things the characters carry and things they need to acquire (e.g., appropriate clothing, food if they will make a long journey). These must be obtained at some point before the possessions are used, which can define the order of events. That spider on the wall in Act One can’t simply materialize out of thin air in Act Two.
- Histories: both the surrounding societal context (how the story’s society has gotten to where it currently is) and each character’s own history, particularly with respect to defining moments in both society and the character.
- Chronology: when things happen.
Among the items in this list, outlining relates most strongly to the chronology, since you must define sequences of events based both on the needs of the plot and on dependencies. For example, in The Lord of the Rings, Frodo can’t throw the One Ring into the cracks of doom before he has the ring, and even once he has the ring, he can’t do his job before he arrives in Mordor. The sequence must therefore be “get the ring, travel to Mordor, throw the ring into the fire.” Note how this is more specific than “get possession, go somewhere to use it, use it.”
How your word processor can help you reorganize the outline
Now that you know what has to be included in the outline, you can start shuffling it into a logical and effective order. Your word processor can help, since it’s easy to cut and paste sections to move them into new positions. Some software offers additional useful tricks for rearranging an outline quickly and easily. For example, in Microsoft Word:
- View —> Outline: Word’s Outline view mode lets you see the whole structure at a glance and easily move topics (and their associated subtopics) around. Better still, it lets you expand and collapse the whole outline and subsets of the outline, such as a specific section or chapter, and move small chunks or entire sections to new locations.
- View —> Document Map: Word’s Document Map view opens a panel to the left of the document window that displays the manuscript’s headings as clickable hyperlinks. The main document window on the right can then be set to the Outline view mode. This way, you can move quickly between parts of the manuscript by clicking the hyperlinks.
Provide architectures that help ensure consistency
Documentation should be centered on the goals of a product’s users. Those goals often fall into categories that define a consistent, effective architecture. For example:
- Conceptual topics should define the problem, describe the context in which it arises, provide any necessary context (e.g., the basic principles of page layout for an audience of amateurs), and propose solutions and alternatives.
- Reference topics should name the tool, explain where to find it (in menus, toolbars, palettes, or dialog boxes), define all options for that tool, and provide examples of correct and incorrect uses of the tool and its options.
- Definition topics should define a word or phrase, explain incorrect uses, and provide examples of (in)correct uses; the topic should also provide cross-references to synonyms and antonyms to help readers learn to use the terminology correctly.
Fiction is less likely to benefit from or require a formal architecture. However, there are cases where having an architecture is very helpful while writing (Demchick 2021). Consider, for example, a novel in which the narrator begins in media res (i.e., right in the middle of the plot). In each chapter, the novel moves forward from that initial point, but each chapter could begin with a concise scene that digs back into the past to provide an explanation or deeper context for what’s about to happen in the current chapter. Part of the outline will then be based on an architecture in which the outline for each chapter states that there will be a context-establishing flashback, then explicitly states what the key point in that flashback is and how it provides context for the rest of the chapter. (For an example of how this works, see my novel Jester.)
Consider another example, with a different order. If you’re writing something that will be serialized, such as episodes in a TV series or a monthly graphic novel about a group of characters, you need to know where each installment ends and the implications for the next installment. This may be a classical structure such as having each installment end with a cliffhanger and (except for the first installment) begin with a solution to the previous chapter’s cliffhanger. This is particularly useful if you’re working as part of a group of writers, with all of the installments for a season being written in parallel. Each author needs to know, in some detail, where they’re coming from and where they’re going.
Dependencies and consequences of revision
It’s rare to create a successful outline for anything complex in a single step. Most outlines require at least one revision (for manuscripts with a simple and familiar structure), and many require repeated revision as you get iteratively closer to something that works. That’s just part of the game, and I like to describe outlining as being equivalent to carpentry: Good carpenters measure twice (at least)before they cut a piece of wood because once the cut has been made, you can’t undo it. Writing seems easier, because there’s no physical piece of wood that can be destroyed by an injudicious cut. But just as carpenters sometimes have to make an unplanned excursion to the lumber depot to replace a key piece of wood they damaged, writers can waste considerable time on undoing a poorly chosen structure for their manuscript.
The easiest way to check an outline is to walk through it one step at a time and pay attention to where you stumble. Wherever you stumble, revise that step to clarify how to correctly take that step. This is why cooking recipes list the ingredients before the steps of the recipe: If you don’t have all the ingredients you need, it’s better to discover this before you’ve mixed all the other ingredients. Similarly, pay attention to where you get stranded. If you find yourself in a dead end, you need to retrace your steps to the turning point that led you there and more clearly indicate that you should have taken a different turn.
These specific examples reveal the broader topic of dependencies: A dependency exists whenever you need some information or some thing before you can perform a step in a procedure, learn a new concept, or (in fiction) move to the next phase of the plot. For a software procedure, you need to know where the relevant tools are hidden before you can perform any steps using those tools. Thus, rather than assuming that everyone knows the tool location, tell them; even if that information exists elsewhere in the documentation; why make them go looking for it? For learning a concept, ensure that you clearly communicate the basics first; it’s hard to teach the concept of logarithms to a student who doesn’t already understand the concept of exponents. For fiction, your protagonist must meet their allies and gain their trust before they can work with those allies to defeat their antagonist. Frodo can’t throw the One Ring into the cracks of doom before he has the ring or before he travels to Mordor.
To identify dependencies, ask a simple question: what must I know before I can understand the current chunk of information? Then add that required information to the outline before the action that requires that information. To support such efforts, you could create a table with the steps in a procedure in the first column and the dependencies in the second column. Then add information or reorganize the table’s order until all the dependencies are resolved.
This becomes complex for fiction, particularly when there are many characters. For example, if you’re outlining a novel, it’s important to know when a character first appears in the story, when they meet other key characters, when they gain a required possession, and when they use that possession. Creating a timeline helps make that sequence more concrete. If you find you work well with visual aids, find graphics that can stand in for each character and their equipment. Print out the graphics, then cut them out from their background. Move the characters down the timeline, then drag the items on or off the line as you move. When you reach for something the character must use and it’s not already present, go back a few steps until you find a way to add it.
Your outline must also account for consequences. After each step in a procedure is complete or some key action in a plot has occurred, something changes and you must describe that change, describe the situation that results from that change, and understand the constraints that situation imposes on subsequent actions and where the change leads. In documentation, the consequences of copying a chunk of text means that the clipboard is now loaded with the text, the text is now available for pasting, and you can paste the text as often as you like until you replace it with new copied text. In fiction, the antagonist’s master plan may have begun, and the protagonist must deal with the resulting cascade of events, one at a time, until they’re resolved. There may be points where the character can intervene to divert or stop that cascade — or there may not be. Both alternatives need to be spelled out in the outline.
What the outline actually looks like
Okay, so that’s the theory. What does this look like in practice? Let’s start by considering the outline for the topics in a programmer’s guide, stripped down to focus on a few key points. Consider an excerpt from our first example of a bad outline.
—————————————
Programming guide topics:
- FUBAR function
- LAWSUIT function
- CURSE DEVELOPER function
—————————————
The problem here is obvious: This only lists the content, without defining the relationships between commands (their temporal or other sequence), the structure of the explanation of each command (the architecture), or how the commands relate to user goals. Thus, it’s an inventory, not an outline. Let’s consider a more highly developed but still bad example for the same programmer’s guide.
—————————————
Programming guide topic template:
- command name
- summary of its purpose
- syntax, including all options and switches
- several examples (both good and bad)
- cross-references to other relevant commands
—————————————
Here, the problem is more subtle: The “template” is identical for all commands and fails to distinguish between any two commands. Thus, it’s an architecture, not an outline. It’s still useful, but needs to be made specific before it is successful. Now let’s consider a good example of how this would be accomplished for one command from the inventory.
—————————————
FUBAR function:
- FUBAR lets programmers define how and how often the program will foul up a user’s data.
- Syntax: FUBAR [% of data] [frequency]
Switch 1 defines the amount of corrupted data; switch 2 defines the interval between corruptions. - FUBAR must occur before CURSE DEVELOPER, which is optionally followed by LAWSUIT.
- [Detailed examples to follow once parameters for the two switches are finalized]
- See also: debugging, recovering lost data [anything else to add?]
—————————————
This example illustrates both the architecture for all subsequent commands in the guide, and how the architecture is implemented for one function, in a way that distinguishes this function from all other functions. An additional bonus is that this topic is almost completely documented at this point. Details must be added, particularly with respect to the reminder in square brackets, and the inventory and architecture must still be approved, but if this is all you could give to the users of the product, they probably wouldn’t complain too loudly. If nothing else, they’d probably stop at the CURSE DEVELOPER function and not proceed to LAWSUIT.
Now let’s consider fiction, using an example most readers will be familiar with: the various films in the Avengers movie franchise. Let’s start with a bad example.
—————————————
- Scene: Tony Stark bantering with Steve Rogers
- Exchange of banter (one or two verbal attacks)
- Discussion of a serious matter
- Parting banter before scene ends
—————————————
Again, the problem is that this probably isn’t much different from all the other scenes, and it provides no details that distinguish it from those other scenes. It’s all inventory and is therefore only a rudimentary outline. Now let’s consider a slightly more advanced but still unacceptable outline.
—————————————
- Scene: Tony and Steve meet for the first time.
- Tony attacks Steve; Steve replies with his own attack.
- Nick Fury brings the talk back to the serious matter at hand.
- Tony attacks Steve about the serious matter; Steve counterattacks about the serious matter.
- Scene ends.
—————————————
Better, but the same description could still be applied to pretty much any scene, not just the first meeting of these characters. Moreover, we have no idea what the serious issue is or why our two heroes are sparring verbally over it. Now let’s look at a better version of this outline.
—————————————
- Scene: Tony and Steve meet for the first time.
- Tony, jealous of Steve’s bulging muscles, suggests that Steve is all muscle, no brains.
- Steve points out that he doesn’t need a billion-dollar mechanical suit to be a hero.
- Nick Fury interrupts, pointing out that both muscles and brains will be required to defeat Loki.
- Steve points out that it’s a good thing he’s got a brain. Tony responds that his suit’s muscles kind of make Steve redundant, but that Steve wouldn’t be a captain if he didn’t have at least a rudimentary brain, and that it’s good to have backup.
- Scene ends.
—————————————
Still fairly primitive, and we’ve got a lot of work to do to move some of the details from implicit to explicit and actually write the dialog. But we at least see a sketch of the problem (they will need to learn to respect each other), the context (Loki is a threat to everyone), the challenge (they’ll need to learn how to work together), and the solution (they recognize, even if somewhat reluctantly, that each has a strength that will come in useful).
Then, theory meets reality …
Of course, reality sometimes disrupts our best-laid plans. For our poor documentation writer, the problem lies in the chaotic nature of product development, which is never as predictable and smooth as anyone would like. For our poor fiction writer, the muse doesn’t always come when called, and sometimes the muse points out that we’ve actually been writing the wrong story and need to take a big step back and reconsider the real story. (This happened to me in my novel Chords, in which I realized that I’d omitted one crucial character from the alternation of chapters and that without her perspective, the story was very ordinary.)
This kind of problem means both writers and their editors have to be flexible and willing to start over when necessary. Documentation outlines often have to change as the product being documented changes, and stories often change as you gain insights into the characters and realize that they don’t necessarily want to follow your plans; the best characters have desires of their own that conflict with your plans. This is part of the nature of writing, and you have to learn to accept it and find ways to cope. For documentation, maintaining close ties with the development team alerts you to product changes that will have consequences for your outline. For fiction, a strong outline that groups and sequences the key events in the story ensures that you haven’t missed any points and understand the dependencies well enough that you won’t forget them when you revise the outline.
What about hypertexts?
Most of the manuscripts we write or deal with as editors are linear, which is to say that the reader begins in a clear starting location and proceeds to a clear destination. The scale of that linearity may apply to the manuscript as a whole, as in the case of Ikea assembly instructions or a novel, or to individual chapters, as in the case of an encyclopedia article or software manual. (Un)fortunately, modern writers have a broader set of options, including nonlinear hypertexts.
Hypertext is the technical term for documents that don’t necessarily follow a linear course. For example, with Web sites and online help, readers may dip into the body of information for very different purposes, ranging from obtaining an overview of what information is available (i.e., orientation) to finding a specific topic (i.e., problem-solving). Outlining becomes much more difficult, since the order of the information and how it is accessed is no longer linear. In such cases, it may not be possible to outline the overall text as if it were a single manuscript. Instead, it becomes necessary to develop two or more outlines, such as one for orientation and another for solving problems (i.e., task clusters).
For a product’s user manual, the first outline might present the complete list of topics (an inventory), grouped into logical categories such as “page layout,” “print publishing,” and “EPUB creation.” A second level of an outline might be created for each of these categories, with the architecture for each category showing how individual product features function, how they can be combined to design a page, how to produce a PDF file you can send to a printer, or how to produce an accessible and properly formatted e-book.
Fiction is less likely to follow a hypertext structure, since stories tend to follow a linear pattern, apart from occasional diversions such as flashbacks. Thus, the first outline might be based on dependencies; that is, the outline would list what events must happen before it is possible for other events to happen. A second level of an outline might then be the chapters and plot points for each chapter, which would generally take the form of conventional linear indexes within each chapter. Those chapters can then be shuffled for dramatic effect, as long as the dependencies are identified and accounted for.
Advantages of my approach
The approach I’ve described has several advantages:
- Careful planning greatly reduces last-minute changes demanded by stakeholders. In some cases, the approval of some stakeholders may no longer be required because they’ve already given it right from the start and trust the other stakeholders to do the remaining work well.
- The outline provides a decent minimalist user manual if you can’t complete every topic. For fiction, it makes for a nice elevator speech if you’re trying to pitch your story to an editor.
- The approach is modular: You can add to the outline, delete sections, or move sections around as the product changes or the plot and characters evolve.
- The outline will be complete if you inventoried everything you need to write about.
- The outline will be consistent: Architectures ensure that all required information is present for every topic.
- It’s user- or reader-centered.
A second meaning of “outline” is a line that surrounds the outer edges of some object, eliminating all the details so only a vague shape is visible. That’s not the kind of outline that helps authors write, nor is it the kind of outline we as editors want to help them create. An effective outline does most of the hard work of developing a manuscript’s skeleton and muscles before refining the details.
References
Demchik, H. 2021. How to improve story structure for a better novel.
Hart, G.J. 1996. The five W’s: an old tool for the new task of audience analysis. Technical Communication 43(2):139–145.
Hart, G. 2002. The five W’s of online help for tech writers. http://techwhirl.com/columns/the-five-ws-of-online-help/.
Hart, G. 2006a. Designing an effective review process. Intercom July/August 2006:18–21.
Hart, G. 2006b. Personas and the technical communicator. Usability Interface 12(2), October 2006. www.stcsig.org/usability/newsletter/0610-personas.html>
Hart, G. 2011a. Uprooting entrenched technical communication processes: process improvement using the kaizen method. http://techwhirl.com/articles/technical-communication-process-improvement-kaizen-method/.
Hart, G. 2011b. Personas and the five W’s: developing content that meets reader needs, pt. 1. What’s a persona? http://techwhirl.com/articles/personas-and-the-five-ws-developing-content-that-meets-reader-needs-pt-1/.
Hart, G. 2011c. Personas and the five W’s: developing content that meets reader needs, pt. 2. Applying the five W’s.http://techwhirl.com/articles/personas-and-the-five-ws-developing-content-that-meets-reader-needs-pt-2/.
Like this:
Like Loading...
An American Editor 