It’s not just an outline; it’s a prototype

Today, I’m starting the rough draft of a new novelette that I’ve been brainstorming and researching for the last week and a half. As usual, I’ve begun by putting together a detailed outline of the entire story, and as tends to happen, it’s almost ludicrously comprehensive: the current version runs to about 7,000 words for a story that I expect to top out, after revision and cutting, at 10,000 words or so. I’ve justified this approach in the past by arguing that an outline like this is really more of a stealth first draft, allowing me to work out issues of plot and character without worrying about details of language and expression. And in approaching the writing process in this way, I’m unconsciously following the good advice of David Mamet:

As a writer, I’ve tried to train myself to go one achievable step at a time: to say, for example, “Today I don’t have to be particularly inventive, all I have to be is careful, and make up an outline of the actual physical things the character does in Act One.” And then, the following day to say, “Today I don’t have to be careful. I already have this careful, literal outline, and I all have to do is be a little bit inventive,” et cetera, et cetera.

All the same, I sometimes look at the outlines I write and wonder if they consume more of the process than they really should, and I’m occasionally reminded of Borges’s parable about the map of the empire that was the size of the empire itself.

Really, though, a detailed outline isn’t a map or a blueprint—it’s a prototype. Over the last month, I’ve been reading Jesse Schell’s appealing book The Art of Game Design, inspired by the fact that some of my most meaningful recent insights into structure and narrative have come from video games. Schell spends a long chapter discussing the importance of prototyping and testing, which he sums up as The Rule of the Loop: “The more times you test and improve your design, the better your game will be.” The problem, at least when you’re operating under a deadline, is that it’s hard to build and test a full working version of a complex system like a game—or a novel—more than a handful of times. And the solution is to start with a very rough model that addresses potential problems without troubling itself too much about quality. Schell advises game designers to employ the spiral model of software development, as conceived by the engineer Barry Boehm:

1. Come up with a basic design.
2. Figure out the greatest risks in your design.
3. Build prototypes that mitigate those risks.
4. Test the prototypes.
5. Come up with a more detailed design based on what you have learned.
6. Return to step 2.

On its face, this isn’t so different from what most writers do: we start with a rough draft that we know isn’t going to be pretty, read it over to get a sense of the major issues, then take it through iterations of revision and editing until it starts to resemble the story we hoped to create—or takes a different, more surprising shape altogether. What’s worth remembering, though, is how rough that initial prototype can be. As Schell points out, when you’re designing a video game, you can make a version on paper to test the basic mechanics of the premise: you can cut Tetris pieces out of cardboard and slide them down a paper screen, or use graph paper to map out a level of a first-person shooter like Doom, pushing around cutout monsters while a player moves and attacks. It’s crude, and it can’t be mistaken for a finished game, but that’s part of the point: the rougher it is, the more likely you’ll see fundamental problems that a more polished version might have misled you into overlooking.

Which brings us back to the outline. The outlines I write are rough, ugly versions of entire stories, or of large sections of a novel, and reading them over before I start the day’s work allows me to think about the story on a relatively high level: I’ll often print it out and make changes by hand to fix things like transitions, the order of scenes, and anything that doesn’t seem clear or logical, which is much more efficient than confronting these problems after I’ve already begun the draft. Later, of course, there will be issues I can’t address directly until some version of the story itself has been written, but it’s rare that I’ll get that far only to find that some major element of the narrative is untenable, as occasionally happened in the old days. The result is a fast version of the loop that Schell describes, and it allows me to pack a greater number of iterations into the limited time that I have. An outline that approaches the length of the story itself may seem excessive, and it does consume a disproportionate amount of the process. But in the long run, it saves me a lot of trouble.