How Not to Ruin your Design Review

You might be sabotaging the process from the get-go

Take care of your valuables!

Remember to Begin Before You Start

Prep is everything in a meeting like this. If you don’t have time to prep, you don’t have time to have the meeting — you’re just wasting N peoples’ time.

Don’t Just Throw Wireframes up there

Set the scene. Even if “everybody” knows the situation, quickly summarize who the user is and what their goal is. This can be a single sentence! If you’ve got established personas, use those: “Ricky, our romance reader, is trying to find a new book to read by one of his favorite authors. Recall that Ricky uses the site weekly, and has hundreds of titles in their to-read pile.”

Trim What You Don’t Want To Talk About

You cut and paste that thing from the old mockup, but it’s okay, people will just ignore it, right? Also, you show the drop-down menu both closed and open so the developers can see what it looks like; pile ’em all together in a heap!

2. Craft Your Presentation

Hey, look, it’s more work! This time, the work is crafting the content of the presentation to shine a light on the part you are discussing, and help people avoid being tripped up by inconsistencies, irrelevancies, or trivialities.

Show Your Design How Users Will Use it

It’s tempting to show every possible state. Developers often ask for it. And it saves time — just throw that extra state onto the same slide! But it’s harmful to getting feedback on the design. Instead, do a little extra work so you can get the best feedback from your reviewers.

An example of a style sheet for Google’s Material controls. This is not the sort of thing to include in your workflow review. (source)

Use Realistic Content

Content? We don’t need no steeenking content! Just stick lorem ipsum everywhere! Even in fields that generally have one small number.

Think how much better that presentation would be if all the people had Goblin names.

Avoid presenting in a format wildly different than your target

Okay, I get it, you can’t hand out cell phones to everybody in the room and ask them to use the app. (I mean, you can, and sometimes that’s a great method, but this post is about design presentations.)

3. Transition To Action

The end of your presentation is likewise key. You can have done everything right, and have it fall apart here.

Be clear about desired feedback

There’s some sort of taboo against asking for what you want. But it’s crucial to help focus: the same way you craft your presentation to give the most screen time to the parts you want to review, you should craft your review process to get the kind of feedback that will improve your product.

Be Visible In Your Action-Taking

Your job in the design presentation is two-fold: presenter, and receiver of feedback. Sometimes these jobs are sufficiently arduous that they get split into multiple people, e.g., a presenter and a note-taker, or two presenters who swap roles halfway through.

  1. You actually take notes on the feedback received.
  2. You take them in a visible way — everyone should know you are paying attention to what they say.
  3. The notes are intelligible two weeks later when you can’t remember the meeting.
  4. The notes are shared with the right people. Some companies like the reviewers to get a copy, so they can clarify. Some teams want the notes to “belong” only to the UXer (I dislike this pattern); some like the notes to be part of the Dev team.

Be Flexible

Finally, sometimes you get it wrong. You thought you were coming into the meeting to review search workflow, but you didn’t know they’d just bought a new Search Engine 9000 and really what they want to talk about is how to integrate its UI into yours.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alex Feinman

Obligate infovore. All posts made with 100% recycled electrons, sustainably crafted by artisanal artisans. He/him/his.