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.
