Back to Basics: Peer Reviews

Originally published on The Pastry Box August 16, 2014.

I’ve attended roughly one peer or executive review a week for the last six years. I average one presentation every five weeks. I’m nowhere near the best in the field, but I’ve noticed some trends among new folks (and tenured folks out of practice) that are basic, yet easily missed, steps. And while there seem to be lots of guidelines for managers and team leads and those in the audience for how to make a space safe and how to give good feedback, I am having a lot of trouble finding guides for how to take good feedback.

Nobody likes getting criticism. If you’re nervous or insecure about your work, it’s that much harder not to hear every “did you consider…?” as “you suck.” The easy way out is to avoid presenting. I’m here to tell you that if you want to be a good designer, you can’t avoid design reviews forever.

At some point someone’s going to ask you to stick your neck out and present your work to someone so that it can be reviewed by people who have the authority to correct the course of your project. Depending on your setting, this might be called a critique, a peer review, an executive review (*gulp*), a pitch, a sprint review…. The name doesn’t matter.

Conducting yourself professionally matters. Understanding that you are not your work matters. Learning how to disposition the feedback you get matters. Getting the rightresults for your clients matters. Getting the right results for your client matters more than your skills, your ego, and your talent all rolled into one.

You don’t suck. But you could get better. Every one of us could get better.

Here’s how to give a presentation of your work:

Introduce yourself

Assume there’s at least one person who doesn’t know you. Introduce yourself, your role, and where you work, for their sake. You’d be shocked how many presenters assume that everyone in the room knows them.

Give a short summary of your project and why you’re presenting it. Who do you work for? What’s the goal of the project? What is the goal of the process or section you’re presenting today? How long is the project, and how far through are you?

Finally, set expectations for what kind of information you’re looking for. Do you want advice on strategy or detailed design? Visual design or structure? Is a section locked down? Is there an area you haven’t thought about at all yet? Give your reviewers some guidelines.

Introduce your primary persona and their goal.

In one to two sentences, describes the user you’re going to role-play and why they’re using your webpages.

For this first scenario, I’m Caroline, a defense contractor who was just moved across the country, and I need to update my office address before my neural probes ship in three days.

If you and your project team can’t summarize a scenario in one sentence, that’s a red flag for the project.

Start with a screen everyone recognizes.

Start with a page you’re sure your audience is familiar with, even if it means taking them out to the corporate homepage and walking them all the way into step 4 of your process.

Yes, your critique members will suddenly notice all kinds of totally unrelated links, images, and features on the home page that have absolutely nothing to do with your project. Politely but firmly keep them pointed toward the goals you set out in your introduction.

Since I’m Caroline, I’m going to come to the defense contractor homepage, then click Accounts and log in… yes? I’m not sure why the log-in button is disabled until the password is entered. That’s Team Hound’s work, but I’ll make a note of it and have them get back to you. We’re going to stay with Team Terrier’s work here, getting logged in, and then clicking Account Profile, and here’s where our new screens begin.

Review your pages

Walk through the scenario. Explain how Caroline’s decisions are consistent with her persona. Point out structural elements, organization, and design decisions your team made. Be prepared to answer questions with the data you gathered during user research. (You did do both quantitative and qualitative user research, right?)

Just as you don’t describe the woods and then mention how Red Riding Hood, Snow White, and Cinderella traipsed through them tree-by-tree, don’t tell your users’ stories by reviewing each page and how your four personas will use it. Connect cause and effect. It’s better to show the same page four times from four perspectives in context of the user’s actual behavior than to make it stand on its own.

Listen and take notes

Be polite. Even if the person speaking is being impolite, or stubborn, or dense as petrified wood, don’t interrupt, and don’t be snappy or impatient in your response. A bad attitude on your part can discourage your reviewers from asking a critical question or pointing out a flaw for fear that they’ll get the same rude treatment.

It can be difficult not to respond to every piece of feedback defensively. Let your work speak for itself. If it can’t, then you do legitimately have work to do to improve it. Decide if this is the right time or place to address the feedback. Is this a hill to die on? Read up on handling criticism. Take classes on it if you can. Stay professional. You choose how to respond, and no one else can choose for you.

Remember that everyone’s listening to everyone else. You can’t fix the problem Joe brought up. Emily wasn’t aware of the problem before, but she can fix it. By allowing Joe to (succinctly) say his piece, you’ve solved a problem for your client that you didn’t even know about.

Take notes or have someone else take them. Make it obvious that you care enough to follow up. Don’t show up at a peer review with no paper and spend the whole time inspecting your fingernails or leaning your chin on the desk. Be an active listener. Respect your reviewers’ time and energy.

The people giving you feedback are doing so to help you improve your work for your client. Make them feel like you’re listening. If you discourage feedback, you’re actively suppressing your own ability to improve.

Thank your audience

Close the meeting as cleanly as possible. Try to be on time or a little early. Thank your audience for their time. If you’ll be following up with them outside the meeting, give honest estimates about when.

Review your feedback

For each of your projects, keep a spreadsheet with columns for date, meeting name, feedback comments, result, and whether the item is open, closed, deferred, or in progress. Review it with your business contacts (to make sure they heard the same things) and assign out work as needed.

Reflect on your own performance, the schedule, and the pace. Did you deliver quality? What could you improve? Is the project still on track or do you need to chat with your boss or your business to update time estimates based on the feedback?

Reflect on your presentation. Did you set the context, as described in the first four tips, in a way your audience could understand? Did you tell a good story?

The last three tips are about accepting other peoples’ stories and feedback. Were you patient with them? Were you able to listen, while still moving the meeting forward? Did you hit your goals? Did you get the kinds of feedback you can act on? How can you make it better next time?

Finally, if you come out of the meeting with more problems than praise, don’t take it personally. Design is iterative, it can constantly be better, and the goal posts are always moving. Remember that “this page is awful” doesn’t mean you are awful. You are not defined by your work. You do, however, define your work, so you may need to iterate and improve on it.

Every one of us does, every time.