I have learned by experience that not every outline is a good outline. I’ve read outlines that seemed to say what they wanted, and yet although I felt that I followed them, I didn’t give the developer what he wanted. I came to see redlines as the point at which the developer really told me what he wanted. Sometimes I was told, “you were supposed to do it this way!” and I had to bite my tongue to keep from pointing out that I can’tread minds.
Then I was lucky enough to get some very good outlines. The manuscript I turned in was almost exactly what was wanted, and very few changes had to be made. I noticed certain trends in the outlines that lead to manuscripts that matched the developer’s expectations, and the ones that didn’t as well. I’ll share them with you here, so that you can better communicate your desires with your writers.
Say What You’re Thinking
This is far and away the biggest problem I’ve seen with outlines handed to freelance writers. Too many outlines don’t convey what the developer is really thinking. Many of the suggestions that follow in this article are all about ways to communicate what it is that you really want.
“They Should Ask Questions!”
Sure, it’s great to say that the writer can and should ask questions when they aren’t sure of things. Unfortunately, I’ve seen a lot of outlines that seemed perfectly clear in their intent, yet later it turned out that they didn’t adequately get across what the developer wanted.
In that case, what is the author supposed to do? Go through the outline paragraph by paragraph and ask if you really meant what you said? Or go through line by line and ask if you left anything out? The outline seems clear; as far as the writer is concerned, there are few if any questions to be asked. But that doesn’t mean you’ve gotten your point across.
Level of Detail
Some developers worry too much about leaving room for an author to get creative. Others worry too much about making sure that the author does exactly what they want.
In the former case, you often end up with an outline that doesn’t convey those overarching elements of mood and theme that the developer does want, and surprise surprise, he doesn’t get what he wanted. In the latter case, you often end up with an outline that focuses on the details, and doesn’t get across (once again) some of the overarching things the developer cares about. (Not to mention that you end up with an outline that feels like a straightjacket, and plenty of writers won’t be comfortable with that.)
While it’s obviously a good idea to take both of these matters into account (getting across what you want; leaving room for an author to be creative), don’t let them rule your outline. Otherwise you’re likely to miss some of the more important things.
One of the things developers only rarely make use of is the suggestion, and this is a sad thing indeed. Suggestions are perhaps the best way to get across what you want while leaving room for the author to do his own thing. The best outlines I’ve ever gotten contained plenty of suggestions.
Say you hit a topic where you have a pretty good idea of what you want, but it isn’t set in stone. Then deliberately phrase your ideas as suggestions. Say “you need to address this subject. One possibility is to do it this way.” Because of the suggestion the author knows what you would consider to be a good approach to the problem. But he isn’t restricted to doing it in that one way. He can if it inspires him, but he can also be creative in another way if he wants to. He’s just more likely to be creative in a way that matches up with what you want, now that he knows what that is — withthe added bonus that your suggestions don’t feel like that straightjacket.
Make Clear What Is a Suggestion and What Isn’t
If a detail is actually set in stone, though, make that clear: “This must be done in this way.” “Only change this if you talk to me first and I agree” is also a good way to do this; that way you’re still leaving room for the small possibility that the author could have a stroke of genius, while making sure that you’re very likely to get what you want.
Offer Help When Needed
When an area of the project would be easy to do wrong, encourage the author (in the outline) to speak to you about the decisions he comes to. “I’m not entirely sure how to solve this problem, so I’m leaving it to you. Let me know what you come up with and we can talk about it.” Also encourage the author in general to ask any questions he has about the outline, or to run weird ideas past you.
Be available to answer those questions! It doesn’t help to tell the writer he can ask anything he wants and then not get around to answering his calls or emails.
Also, treat his ideas calmly. If you really want him to be creative and to talk to you about his ideas, then don’t ridicule those ideas. A simple “no, don’t do it that way” works just fine. The most amazing and creative person has dumb ideas. The only thing you do when you ridicule the suggestions an author sends you is convince him that he shouldn’t ask you about such things any more. And that defeats the whole purpose!
The best outlines I’ve ever gotten (and the ones for which I ended up producing manuscripts that were pretty much exactly what the developer wanted) are the ones that babbled a bit. They read a little like a stream-of-consciousness. The developer sat down and dumped everything onto the page that he could think of — what he wanted, what he didn’t want, where he had ideas, where he didn’t, where he wasn’t sure what he wanted, and so on.
Don’t Structure Yourself Too Much At First
Sometimes, if you’re paying too much attention to trying to structure your outline, you aren’t paying attention to making sure you say everything. You aren’t writing a book that has to stand up to critical acclaim; you’re trying to make sure you don’t forget anything when communicating what you want. Your writing should be clear, but sometimes structuring it too early in the process causes you to forget the little details (or the big ones!).
Just get everything down on paper. Then worry about making sure it makes sense and has some order to it.
Include As Much Information As Possible Internally
Don’t explain all of your moods, themes, styles, or whatever in terms of outside works. Particularly don’t do this in place of an actual, in-outline explanation. The worst outline I ever got explained everything I was supposed to know in terms of massive, hundreds-of-pages, mostly out-of-print books.
Why is this bad? It’s the quickest way to turn off a writer from doing the necessary research, for one. Also, I’ve never seen a contract that actually included
enough time for an author to hunt down the books and read them all before starting the writing. And if any of those books are out-of-print, it can take weeks at best, even months, for the author to find them — if she can find them at all.
It also means that she can’t just look back at your outline when she needs a reminder of how to do things; she has to go page back through that massive tome of information. In addition, she doesn’t get a good overall feel for the book when she reads your outline. She’s left with gaps of understanding, which causes problems in the image she builds of the work you want.
It’s all right to give references, but you must also explain what on earth you mean right there in the outline. After all, if you’re using a vocabulary that the writer doesn’t understand, then you aren’t communicating what you want.
There’s also the matter of what I call “in-company research.” Say that a writer is working for a roleplaying company that has a long-standing, complex, intertwined world. He finds that in order to be familiar with the background for the measly 6,000 words he’s writing for them, he has to read seven whole books. Maybe he only needs a little bit of information from those books, but he has to read the whole books in order to find out which pieces of information he needs.
Put yourself in the shoes of that author. You aren’t getting paid a huge amount of money for those 6k words, and you have rent to pay, groceries to buy, medical appointments to pay for–which means that you have to fit as many contracts as possible into the time you have. Now you find that you’re going to have to spend even more time on the reading than you will on the writing (possibly much more), without getting paid any extra. That’s a pretty quick way to convince the author not to work for you again. Or it’s a quick way to convince him not to do the research, which means he won’t give you what you want.
Sure, some research is to be expected in any contract, and you have a right to ask for that. If you want to be able to hire full-time writers, however, then make that research as easy on them as possible. Include as much information as you can in the outline. Tell them exactly which sections or pages of which books you’d like them to read, so they don’t have to read the whole thing just to find those two paragraphs of relevant information.
Obviously, customize these suggestions to you and your own work. If you find that a particular style of outline works, go with that. If you find that a particular author needs to be told things in a certain way, then go with that. Pay attention to which outlines work well, which don’t, and why. In fact, instead of railing at an author for not reading your mind, ask him why he didn’t get what you wanted out of the outline. You might learn something!
Include a Sheet of Pet Peeves and Stylistic Considerations
Every developer or editor who’s developed at least one project has a set of pet peeves and desires for the writing he receives. Write this up separately and include the sheet with every outline you send out. Update it with further projects as you come to more realizations about what you do and don’t like. This includes things like “don’t use passive voice,” or “remember to use concrete examples along with any abstract concepts.” If there are any major themes or moods across all of your projects that the authors must remember, you can include them here just to make sure you’ve gotten them across.
Sometimes when a writer gets caught up in his writing he can forget about things like this. It’s handy to have a sort of checklist to run down when he edits the piece. It also means that the more he writes for you, the more he should learn to automatically work your likes and dislikes into his writing.
With a little work you can produce outlines that are more likely to get you what you want. Unfortunately I think too many developers concentrate on what they’re putting onto the paper rather than what the writer is getting out of it. These are two separate things and both must be taken into account. That’s what writing is, after all: the art of communication, of realizing what your reader is going to see when he reads your words. And outline-writing is still a form of writing.