I read through a dozens of book proposals each year. They often feature compelling prospective titles, succinct and illuminating blurbs, and proposed take-aways that make me wish I could run out and buy them today.
But rarely do I encounter a proposal author who knows where they’ll take their reader. Call it whatever you like—narrative arc, table of contents, reader journey—but proposed book structures tend to be, well, weak—if they exist at all. Weak structures generally lead to a difficult writing experience and a crappy reader experience.
It’s not surprising: most people who submit book proposals have very little experience with long-form prose. They’re too close to their material, so they lose sight of the big picture. And let’s face it: it’s really hard to map out a journey through some hundreds of pages.
So I’ll offer three simple exercises that can really help. They come straight from the information architecture playbook. Well, this information architect-turned-publisher’s playbook.
The first two start with your proposed book’s high-level outline. These exercises are best done concurrently and iteratively, as they inform each other—that’s why I list them as “1A” and “1B,” rather than “1” and “2”:
Exercise #1A: The Writing Budget
First, set a budget for how long your book should be. At Rosenfeld Media, we find the sweet spot for our user experience books is in the 175–250 page range (at 300 words/page). And because writing concisely is so challenging, I suggest you shoot for the low end of that range, as your word count will invariably run longer than you’d planned. Also, don’t worry about front and back matter for now. Let’s go with 200 pages.
Now allocate those 200 pages to your outline’s major topics. Avoid slumber-inducing chapters that run more than 20 pages, and choppy ones fewer than, say, seven pages long.
You’ll find that this exercise is much tougher than it appears, as you’ll be forced to grapple with such vexatious questions as:
- Split or slim? Is this 30-page chapter really a single chapter, or should I split it into two chapters? Or maybe I’m covering too much, and I should slim it down to something closer to 20 pages?
- Add or axe? Does this three-page chapter merit standing on its own as a chapter, or can its content be added to another chapter? Or should I just get rid of it all together?
- Must I really kill my babies? Yes. Yes, you must. You’re chock full of great ideas, but some are greater than others. And if you’re writing a book, you’ll likely have other opportunities to write in the future. So save those secondary topics for your book’s blog, an interview, or—shudder—your next book.
It’s awfully difficult and painful to shorten your proposed book from, say, 350 to 200 pages, but I guarantee you this: a good short book will be far, far more successful than a good long book. And very few of us have a good long book in us.
Exercise #1B: Microsurgery
While you’re working your way through the forcing function of the above exercise, you’ll need to delve deeply into each of your individual chapter’s content — perhaps more than you have before. After all, you’ve got to figure out what content will or won’t fit into each chapter.
In effect, you’ll also be applying the budgeting cudgel to each individual chapter. Use the opportunity to develop one or, better, both of these things:
- A high-level outline of what you’ll cover in each chapter
- A brief charter or prospectus—three sentences tops — that explains what you’ll cover in each chapter
While you’re digging deeply, there’s a good chance that patterns will emerge, especially among the content elements that keep appearing in your book’s “meat” chapters. For example, you might decide that the expert interview you cleverly decided to feature in one of those meaty chapters would really make sense to include in all of them. Great idea! Of course, that’ll impact the overall page count (see exercise #1A)…
Both of these chapter scoping techniques will help you immensely with your overall budgeting work. You’ll jump back and forth between the exercises, and I’m sure you’ll be frustrated along the way. But by the end, you’ll have a much clearer picture of your proposed book’s journey—certainly for the reader, but for you, the author, as well.
Extra Credit: ToC Testing
If you’ve survived those two exercises, you’re ready to test your book’s structure (which, by the way, has now officially graduated to table of contents status!).
Take the highest-level of your proposed table of contents: just the chapter titles. Now share it with a colleague who hasn’t seen your proposal before. Ask them to pretend that they’d picked up your book in a bookstore and flipped to the ToC to try to quickly understand what your book is about.
If the ToC leaves them confused, there are two likely culprits:
- The chapter sequence is out of whack. Did you start with a case study before you framed your idea’s guiding principles? Did you jump into a long discourse on the history of your approach before justifying its value to the reader? Can the reader skip over the “why” and “what” content to quickly find their way to the very-useful “how” material? Consider “talking” through the ToC out loud; it’s a fabulous way to nip this problem in the bud.
- The chapter titles are inconsistent. Stay true to a single style in your ToC. For example, don’t frame some chapter titles as questions (“Why do some people pound bricks?”), but not others (“Why some people prefer to pound cake”). Avoid making some of them verb-dominant (“Running with the dogs”) while others noun-centric (“Cats and pilates”). Keep the titles’ length fairly consistent. In general, minimize any discord that creates red flags in the reader’s mind: if you can’t even get the ToC right, they might assume your prose is worse.
Your table of contents absolutely must tell your book’s story. If it doesn’t, you really should go back to the drawing board before you start writing in earnest. But take heart: the Writing Budget and Microsurgery exercises we’ve covered here are just as useful for guiding you through tuning your book’s structure as they are for generating it in the first place.