We’ve spoken before, you and I, about the importance of taking your readers into account as you write. We’ve discussed interpreting feedback from your earliest readers. We’ve covered how to find those early readers and solicit their help. Today I am looking forward to rambling on at length on the topic of how to deliver direct and useful beta feedback to a fellow writer if you should ever be tapped to do the dirty reading deed.
When trying to learn something, I have to do whatever it is personally before I can fully understand it. I need to actually step through whatever process it is myself. No amount of guidance, no amount of detailed step-by-step instructions, will ever be able to substitute for actually muddling through the task. The only thing I can do in advance to prepare to learn a new process or task is to understand its purpose. Once I understand the purpose of whatever it is I’m expected to do, I can take that and figure out the task. I might be able to refer to instructions once I’m elbows deep in whatever it is, but anything I read beforehand, in the absence of practical, hands-on knowledge, means nothing to me.
Not everybody learns that way, but I do. It’s terribly awkward when someone is trying to teach me something ahead of time and then two weeks later when it’s time to actually try my hand at the task I have retained zero percent of what I was told.
After I’ve done the first two things—understood the purpose of the task and then muddled through it the first time—I can get proficient very quickly. With proficiency comes the next level of understanding: The ability to explain the thing I now understand to another person and show them how to do it. I’m deliberately avoiding the word teach because to teach someone how to do something implies real mastery on the part of the teacher. But I can at least demonstrate the task or process so that another person can learn it as well.
In summary, a three-step process:
Understand the purpose
Actually perform the process enough times to gain proficiency
Pass this understanding and ability on to another person
Kind of like I’m doing right now. Kind of. You’re probably not learning anything. That’s because I’m not very good at this yet. I’m still in the gaining proficiency stage.
All this is to say, if you are out there asking someone to beta read your work, you may need to explain to them what you need them to do. You may need to walk them through the task. In order to do that, you need to be sure you understand the purpose of the beta read well enough to ask for the feedback you need with specificity, and you must also understand how to perform the process of beta reading well enough to pass this ability on to another person.
If you know—or if you’re hiring—an experienced beta reader, then this is a nonissue for you and you can move on. But if you are interested in learning to excel at beta reading for the purpose of providing that service to fellow writers or to pass the skill on to your own beta readers, I think you’ll find some useful information in this article.
The first step to learning anything is grasping the full purpose of whatever it is. Its meaning. I know people who can follow instructions carefully and successfully complete a task without understanding what the purpose is, but I’m not good at that. I have a difficult time putting anything together from component parts. I need to see the big picture.
The purpose of a beta read is to get early feedback on a manuscript from the perspective of a member of the intended audience. The beta reader is not just any reader. If you’ve written a genre-bending science fantasy epic with a diverse cast of groundbreaking characters, maybe don’t give it to your grandma’s bible study buddy to beta read.
(Actually, now I think about it, the bible is a bit of a genre-bending science fantasy epic with a diverse cast of groundbreaking characters so maybe that’s a bad example.)
Your beta reader needs to be someone who fits the profile of your target audience. If you’re writing a romance novel, your beta reader should be someone who understands the genre well and enjoys it. If you give the manuscript to your editor friend who isn’t interested in and doesn’t read a lot of romance, you’re not going to get as good a result as you would if you gave it to a not-at-all-editorially-minded friend who reads a lot of romance (and particularly, if you can swing it, reads and loves the subgenre of romance you’re writing).
The feedback the beta reader provides is broad and general. They must first and foremost confirm (or deny) that the manuscript’s premise is interesting. If you give your potential reader the thirty-second elevator pitch, do they want to hear more? If you give them the first chapter, are they hankering for the second or are they giving you the thumbs down? You don’t need a copyeditor for that type of feedback. You need a real reader—or as close as you can get.
Next, the beta reader looks for big-picture items that aren’t working for the story. Which scenes feel forced? Which characters aren’t getting the intended reaction? What details, worked into the story early on, never pay off? What curveballs come out of left field in the second half of the book that weren’t set up beforehand? And, importantly—what just doesn’t make sense?
It’s normal for a reader—for a consumer of any type of media—to have questions as they delve into a work of storytelling at the beginning. Pretty much every story begins with some kind of question that the reader wants to know the answer to. That’s what gets anyone to turn that first page. Depending on what kind of media you’re creating—what kind of story you’re telling—your reader’s expectation for getting that initial question answered (and possibly their attention span, if you’re writing for a younger audience) will vary widely.
For instance, let’s say you’re writing a literary mystery/thriller. Let’s say you’re writing Gone Girl. The question that you introduce at the very beginning isn’t going to be answered for a while. In fact, just when the reader thinks they might be getting at toward the heart of the question, you’re going to cut the narrative off and throw something else at them. Let’s also say your beta reader isn’t familiar with this genre. Your beta reader reads a lot of romance novels. In a romance novel, the initial question that gets thrown out to hook the reader (“oh no, what has happened to wreck this heroine’s day and/or life?”) is answered rapidly (“her husband cheated/engagement has been broken/job is relocating her big-city self to a picturesque gazebo-ridden small town in Vermont”) introducing, in the process, a bigger and more enduring question (“how will she start over and find love and success again?”). Your romance reader in this example is going to anticipate an answer right away and they may find the introduction of your thriller unsatisfying with no answers in sight—only questions on top of more questions.
Some of the most valuable feedback you can provide as a beta reader is how engaging the manuscript is in its first ten percent. If the reader hasn’t seen anything by that point to get them to buy in, they’re not going to want to read the rest of the book. That’s a real make-or-break point in any novel: Far enough into the story to have a sense of whether it’s interesting, but not yet so far that most readers will feel they’ve committed themselves and must now forge ahead.
Someone who has vast experience with the type of story they’re beta reading will have an immediate sense of whether the manuscript’s first few pages hit the mark. Does it strike the right balance between asking intriguing questions and leaving the reader uncomfortably confused? This is perhaps the single most important tightrope to walk in all of storytelling. A reader who feels disoriented by too many questions all at once will stop reading. A reader who doesn’t feel intrigued will stop reading. A manuscript’s only mission in life is to keep people reading it. Anything else that a manuscript might go on to accomplish within its pages will be moot if it cannot get a reader invested.
Beyond letting the author know what may be going wrong with the manuscript, the beta reader can also give important feedback on what’s going right. What are the most exciting, compelling scenes? Which characters really jump off the page? What dialogue is most memorable? Sometimes grabbing a compelling snippet from mid-manuscript and finding a way to put it right out in front of your story.
For example, Gabriel Garcia Marquez doesn’t launch into One Hundred Years of Solitude by telling you about the cockfight that caused José Arcadio Buendía to leave town and start a new life. Instead, he starts with the day José’s son faces the firing squad—and then works backward and forward from there. The reader is willing to go three hundred pages deep just trying to figure out who this guy is, and why he’s being executed, and—most important!—how he and his father discovered ice. Why didn’t they already know about ice? How did they discover ice in the middle of nowhere in an equatorial country? The author took a really vivid part from later in the story and stuck it on page one. You can just do that. Nobody says you can’t.
There are no rules. Put semicolons anywhere you want. I’m not the boss of you.
The beta reader should focus on type of high-level feedback and look past spelling mistakes, grammatical errors, places where language use or paragraphing could be improved—anything like that. That’s all for later.
Everybody has more than one lens through which they read text. Most people, for example, can distinguish between reading for pleasure versus reading to absorb information and learn something. I read completely differently when I am reading to enjoy something than when I am proofreading to find errors or copyediting to improve a text. A beta reader should endeavor to be somewhere between reading for enjoyment and reading to improve the text.
Whenever I read an early version of someone else’s writing, I make notes as I go. My notes capture my thoughts on what I’m reading, but also my impressions and feelings as I read. There are a lot of valid emotions to evoke as a writer. Not all of your characters should be likable. Not every villain needs to be unlikable. It’s fine to make your reader angry; you want your reader to feel anger if you write about an injustice. You want your reader to feel disappointment if something important doesn’t go right for your protagonist.
A beta reader should pay careful attention to negative feelings while reading. Any sense of disappointment, frustration, or dissatisfaction as I’m reading an early text is a flag for me to look a little more closely. If the feeling is an intended consequence of the writing—a reaction to something that happens in the plot, for example—and is resolved later on, then it’s probably fine. If the negative reaction is an unintended consequence of poor plotting or a lack of clarity or detail, that is critical feedback for the author. Anything that causes a beta reader to feel confused (note a fine distinction between intrigued and confused), frustrated, or unsatisfied requires careful attention from the author during revision.
I know I said there were no rules, and there aren’t. Haruki Murakami has made a whole literary career out of confusing readers. Text that causes reader confusion doesn’t automatically need to be struck and redone, but it must be carefully considered. Those are the parts of the text that must be crafted most precisely so they don’t eject your reader from the text. Any time your writing causes the reader to step out of your text, there’s a chance they won’t come back. Handle with care.
Finally, when beta reading or requesting feedback from a beta reader, make sure to clarify the type of critique that will be generated. The only feedback that can help a manuscript improve is direct and honest. A beta reader who delivers their comments with kindness and grace is a gift, but the content of the commentary is more important than the delivery.
“The story was great, I loved it” is not a useful beta review. As far as I can tell, no matter how prepared a writer may be to receive actionable feedback, there is always some part of them that hopes to hear their work was genius, above any reproach, and needs no changes. It feels great to hear that kind of feedback. It’s completely effortless to give that kind of feedback. That’s the easy road you can’t afford to take in the beta process. Be ready to bruise an ego, or get yours bruised. Don’t bother doing the beta read at all if you’re not going to do it right.
March wanes and April looms large. Not Thursday but next Thursday is April Fool’s Day and I hope to have a fun and foolish article for you. In the meantime, I’ve been thinking a lot—for work and play—about precision language and prescriptive language and a bunch of other related stuff that nobody asked for and nobody wants. I hope you’ll come by to read it anyway. They can’t all be winners, right? All examples of any sample set can’t be winners. Except Shelf Life readers, you’re all winners. Come back Thursday. Eat at Joe’s.
If you have questions that you'd like to see answered in Shelf Life, ideas for topics that you'd like to explore, or feedback on the newsletter, please feel free to contact me. I would love to hear from you.
For more information about who I am, what I do, and, most important, what my dog looks like, please visit my website.
After you have read a few posts, if you find that you're enjoying Shelf Life, please recommend it to your word-oriented friends.
While you may not see yourself as a great teacher my writing has improved vastly from this blog alone. The insight you share and the way you cover things have saved me countless google searches. Was also an eye-opener when I share content with my "beta readers" because "what do you think of this?" is way too broad of question when I should be asking "does this flow?", "Is this too out there?", or my favorite "I want to show it off, but I am too nervous to share it, as it is not complete. Is it interesting or making sense at least?"
My favorite method of critiquing myself when asked to do so is to use the Oreo method. Start with a compliment/s about the piece including likes. Followed up by my criticism of if it's got flow issues, small typos that are still words, and other random stuff. Then I like to end it with what I enjoyed most about the pieces, and what really stood out and shined. That way I can be positive while critiquing, as it can easily build up or tear down the morale of a project depending on how you word it.
Now I want to know if beta readers came from software development or if they stole it from another field