Anyone who is a technical communicator gets involved in reviews, either doing them or getting them. There is an enormous difference in the appropriate level of feedback to give depending on whether you are being asked to look at an initial version (first eyes) or the almost ready for prime time version (last eyes).
Quick example, if I am doing a first eyes review and the document contains the word "utilize" I recommend that the writer say "use." If I am in a last eyes review and the document contains the word "utilize" I make sure it is spelled correctly, or appropriately for British vs US audience.
That example is a bit simplistic, but you get the point. First eyes reviews should look at larger issues and should invite new perspectives, as in "Have you considered taking this other approach?" Last eyes don't add a lot of value with suggestions that essentially would change the scope or direction of a document or user interface right before launch.
In a similar vein, when I submit academic research articles for peer review, I'm always amused by the peer reviewer who suggests that I use a different sampling method or change my interview protocol. Thanks, I'll just hop in my time machine and redo the study. Reviews that suggest different ways to analyze or interpret the data are much more useful. The ones I love most are the ones who help me articulate my points more clearly. Now if I were in a conference room with these folks planning my research, I would have entirely different expectations.
I'm currently wrapping up a project at work where I have been taking a manual written by a partner and basically rebranding and modifying content to reflect how we have implemented their product in our solution. This is very close to a last eyes review (given project time and resource constraints) and I have to be careful not to get out of scope and start rewriting one author's (and company's) style to match mine. It's not always easy. I can make small changes, such as changing "wish" to "want" (translates a LOT differently in certain languages) but I have to ignore some annoying rhetorical differences in how they treat procedures and how we do. (Can you say "doubles the scope?")
Some technical writers balk at this and say it's a question of quality: "I just can't lower my standards." I don't think these writers understand the business of writing, nor are they particularly skilled at critical thinking. By critical thinking I mean being able to discriminate between what is important and what isn't. Running to the high ground of quality sometimes just puts our heads in the clouds.
When asked to review a document or a user interface, we should ask ourselves are we in a first eyes review or a last eyes review. If first eyes, then our review should be critical and ask questions that challenge what could be wrong assumptions ingrained in the entire approach, a la "Is this really the optimal workflow for adding a new user?" Last eyes should assume for better or worse the work represents what the author or designer is trying to do and just make sure that distracting glitches are caught and removed, a la "Password is misspelled."
BTW, the more you treat last eyes reviews like first eyes reviews, the less likely it becomes that you will be invited to do first eyes reviews. Ironic but true.
3 comments:
Those of us who have been in technical communication since before it was all done on a PC, like me, remember and understand the whole production/review cycle, and the appropriate edit levels for the different stages in the process.
If a single writer and their PC is responsible for the entire production process from first draft to final PDF or web posting, they should understand that they should be revising for different things as a document progresses from initial draft to release.
Is this concept incorporated in most current collegiate techcom curricula? Would it be an appropriate topic for an STC meeting topic or webinar presentation? I know it periodically pops up in the TE SIG online discussion list.
Thanks for getting me thinking about this, Mike. I probably tend to be like the guy with the hammer to whom all documents look like a nail. Even for someone who carries a document through the entire process, it's good to have some structure to that process and focus on specific issues with each editing pass.
Mike, I like how you look at the world through reality-colored glasses. Those of us who were working in the 1980s had our brains filled with a lot of junk about quality and "zero defects." Of course we want to do the very best work we can. But real-life business isn't about zero defects. It's about maximizing ROI. We need to stop striving for perfection (which is impossible anyway) and get to where "good enough" is good enough. Your insights are very helpful.
Post a Comment