Whether it’s a document edit, a design critique, or a performance review, receiving feedback in a vacuum can be a shock.
By “in a vacuum,” I mean without having discussed the objectives and success criteria. What are the metrics? How will the results be used?
Without this information, receiving feedback can be like going to a meeting without an agenda. Painful.
If you have requested feedback, be clear about what is helpful.
UX architect Mike Hughes has written about “first eyes” and “last eyes” when it comes to critique. Is the piece a first draft, or is it due tomorrow? Have you ever asked for input at an early stage and gotten feedback that focused on low-level details? It can also be overwhelming to ask for a proofreading and receive copious suggestions on content and organization. I tend to be a high-level thinker, and so have been guilty of the latter. Save everyone’s time and aggravation by asking what kind of comments would be helpful.
Sometimes we’re asked to solicit opinions and it’s not clear why. I’ve been asked to have surprise stakeholders weigh in at late stages in the development process. If you’re in the habit of clarifying expectations for reviews, it can help you manage expectations about what you’ll do with the input. If I explain up front that I’ll schedule all non-emergency edits for the next release, everyone understands why they don’t see their edits incorporated immediately.
Explain known issues, architecture, and choices made.
If you haven’t done the final proofread or formatting, and you’re sending something for, say, a technical review, you may want to mention there may be issues. If there were tradeoffs made in the design, you can mention those and other design decisions.

Marta Presents Her Final Project by Peter Alfred Hess, on Flickr
How do you communicate design decisions for a review and still be brief enough to make the information palatable? How do you avoid the feeling of being in a tennis or boxing match; responding with your rationale, blow by blow, to the volley of things the reviewer doesn’t love?
One way is by breaking review into smaller chunks. Another way is by meeting prior to the review to explain the overall architecture and priorities of the design. I also like to meet after I’ve incorporated the reviewer’s edits to demo the changes inspired by his or her input. That’s a good time to discuss the edits I chose to defer or decline.
Know who has the final say.
Who are the stakeholders? Who needs to review, and when? Who owns which decisions? Talk to each of them (together, if possible) and agree on a review schedule.
To document this, you may be able to send out this agreement in an email, or put up a quick flow chart in the war room (hello, Agile folk). But if you have a team of writers or designers who move from project to project, dealing with some product owners infrequently, it can be useful to be able to point back to some more formal guidelines. For example, if your team uses templates or structured authoring, you may want to explain the process and consequences for deviating from those structures (or that you don’t). These guidelines can live in your SOPs or style guides.
At the very least, it’s good to confirm with your boss that you know which stakeholders decide about what.
If the review was not your idea, clarify expectations.
When someone announced they are going to review your work, it can be stressful. Performance reviews come to mind. It’s reasonable for you to ask for more information. Your questions can be helpful for the reviewer, too, and improve the quality of the review.
What questions will be asked? What criteria are used? What is the effect of the results? What response will be required by you if something is found to be lacking? What are the consequences? What is the timeline? How much preparation will you have?
I’ve got a new resolution to practice.
I don’t go to meetings without agendas, and I don’t go to critiques without agendas, either.





