Our post on beta readers offered a strategy for soliciting structured feedback before project release. But it didn’t discuss strategies for handling that feedback once it arrives in your inbox.
Reading criticism is hard. After all, writing requires time and self-expression. No matter how professionally oriented, criticism can sting.
But integrating criticism is even harder. It's never easy to judge which critical feedback is useful and which isn’t.
The simplest strategy? Look for repetition.
Repetition can be straightforward. If more than one beta reader (or more than one feedback form) specifies the same weakness, well, it’s a weakness.
But repetition can also be oblique. Consider the beta-reader responses to a question that asked about the translation of SME material into everyday language:
And repetition can be overwhelming. It's no fun to read about the many different problems with your project. Luckily, these can usually be condensed into just one or two actual issues. For example:
Criticism might not be fun, but it's so fruitful. And not just for you. Soliciting critical feedback and then actually (and visibly) using it sets in motion a positive feedback loop that strengthens your project, your team, and your business’s commitment to your organizational end game.
While a beta release refers to the rollout of an early, mostly untested version of software, the beta phase (and the iterative form of software development in general) is an excellent way to pretest communications projects, too.
Software development usually proceeds from a pre-alpha phase (where R&D is completed), to an alpha phase, (where core functionality is built), to a beta phase, and finally to release.
That beta phase is so crucial because it puts the software—usually ugly and incomplete—out into the world. Chosen users can then play with it and provide the targeted feedback so necessary to completing and releasing the work.
Communications projects (reports, technical manuals, strategic plans) follow a somewhat similar route. First, there is the research and development; then, the outlining, drafting, and collating; finally, execution and testing.
But a beta release is rarely figured into this execution—and it definitely should be.
While most of us pay close attention to after-the-fact metrics, a beta release tests whether content is functional in a way that meets readers’ needs before delivery. Communicators can use the release to gain on-the-ground feedback and integrate it into a project ahead of publication.
To make the most of this opportunity, make recruiting beta readers (using a generic application like Google Forms to help identify members of your target audience) a part of R&D. Later, when the project is almost complete (but still malleable!) push it to beta readers with another form soliciting the feedback required. Common questions include responses to SME material or to calls to action.
For any client-facing project with a long development phase, a beta release creates a space in which meaningful info can be gathering and used. It's a bit of a time investment, but the payoff makes it absolutely worthwhile.
The Publication Manual of the American Psychological Association—now in its sixth edition since its inception in 1929—is a constant companion to many of our academic writers (whether they like it or not!). We recently interviewed Mary Lynn Skutley, the editorial director of APA Books, who headed up the manual’s latest revision. From Skutley, we learned firsthand just what goes into the making of this slim volume, frenemy to so many.
English PhD, former arts administrator, obsessive cook, native East Coaster, and mom to two rabblerousers.
English PhD, former high school teacher, obsessive organizer, native Midwesterner, and mom to three troublemakers.