How Not to Ruin your Design Review
You might be sabotaging the process from the get-go
We’ve all been there. The Dev team has worked really hard to nail down a search results page they think will really help users. You pull up your slide deck and start walking the stakeholders through it.
“Okay, here’s what the user sees after they log in,” you say to the assembled throng. It’s good to start with the familiar, you’ve heard.
“Wait, that’s not the right time zone,” the VP of marketing points out.
“This is just fake data,” you say, hoping to get back on track quickly.
“Nobody has that many books on their shelf. Why are you showing so many books?”
“Lots of our users have really large shelves,” you stammer. “But we’re not reviewing the book shelf design right now.”
“I don’t like that font. Why is it so blocky?”
And on, and on.
What happened?
(A side note: I have committed EVERY ONE of these mistakes. And I hope you can learn from my errors!)
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.
Some specific prep things to think about:
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.”
We’re all so busy. It’s impossible to prep people in meetings, you say. I had 6 design reviews today alone!
Well, that sucks. And it might say something about your workplace. But 3 super-productive design reviews, with a few minutes for audience prep ahead of time, and a solid half-hour afterwards, are better than 6 abbreviated ones. There’ll be less rework and deeper insights.
So budget your time appropriately, and help people understand context before they jump into your design review.
If you don’t build up context and give some user background, reviewers often simply overlay their own experience on whatever you’re presenting. You’ll get their knee-jerk reaction, or end up bike-shedding, instead of getting valuable design input.
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!
Except — no. We’re all human, and design reviewers are already at a disadvantage, because they haven’t lived with the design while you’ve been working on it.
At best, they’re coming in largely blank — at worst, they have the old version, or a dozen old versions, floating around in their head fighting for dominance. So help those squishy human brains to focus on the relevant piece. Take the extra time to trim out things you don’t want to talk about.
If you’re exploring search that day, aggressively blur out the rest of the page. Or put a big gray X, labeled “USER’S SHELF”, over that section. A big gray box, with the right voice-over, is totally fine if you want your audience to focus elsewhere.
A big grey X, you say? That’ll ruin the aesthetic! Well, yes. And make it abundantly clear you are not talking about aesthetics right now. Make it unmistakably ugly, and as clearly labeled as the devices in the Bat Cave circa 1967. Bat-Login-Page. Bat-Bookshelf. Bat-not-what-we’re-reviewing-today.
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.
Most of us are familiar with style sheets, and it’s tempting to do something like that with mockups. These have a different audience and purpose.
Designers are often tempted to reuse the same format for both design documents (which are used to coordinate with developers) and design presentations (which are used to get high-level feedback from user proxies). While these can look similar, their constraints and goals are very different, and often in conflict.
For a design review, you’re attempting to elicit responses similar to what a user will have while using the design.
Note: there ARE many exceptions to this! For example, if you’re showing off search results that change depending on the type of result, it’s helpful to have a “style sheet” like the above during your presentation showing all 12 variants at once. There are just too many instances to make up a design case for each one. But first set the scene, and if possible, keep available the context for the style-sheet focus. In an ideal world, you could even switch between the items in context — think about a color picker that shows you the color used in a variety of situations, letting you see the contextualized result as you vary the color — but that’s a bit of a pain to set up.
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.
Sure, yeah, just put “test test test” (or just “lorem”) in the text area which is going to show a page-long blog post. It can’t possibly affect the layout…
There’s a famous study from the dawn of UX regarding cockpit design. The designers worked hard to establish a new layout of gauges based on best principles of human factors and the needs of pilots, then presented it to pilots to get their input.
The response from pilots? “That’s impossible! That could never happen!”
It turned out the gauges were eminently readable — but the data they were showing was conflicting nonsense. Since the entire goal of the interface was to understand those gauges, designers should have paid attention to sourcing high-quality data for them.
This requires you to identify the key info in your interface. Can you gather real data, potentially anonymized? If you absolutely cannot, can you create data that is the same shape (word length, number of words, size of pictures, length of numbers)? It makes everything work so much better. There are a variety of code libraries and websites for generating “random but real-seeming” data — use ‘em!
And yes, sometimes throw in the “hard” content. The person with the display name that is more than 32 characters long (I’m married to one). The exceedingly long load-time number. (“Your call is important to us. Your call will be answered in approximately 4294967295 seconds.” — well, okay, maybe that one calls for a rethink of the interface.) Translate the interface to German, if that’s a target market, because text labels tend to be longer in German. Whatever makes sense for your scenario.
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.)
But you can set yourself up for success by approximating the target platform(s). Are you targeting desktop users with 24" monitors? Then make your mockups in 48pt type, because that’s what slides require. Designing for mobile? Ditto!
But, you say, but! Designs that work well might not present well. It’s impossible for people viewing a slide deck over a crummy network connection to read all the details of an interface. And that’s a good point.
So it’s up to you, the presenter, to ameliorate this. One way is to give an overview and then zoom in on specific areas of interest, either with an inset image or by having successive slides focus on different areas. Another is to provide context some other way, for example, via printouts or a static document (PDF) shared, and then say “we’re looking at this section”. For smaller designs, as for a phone interface, avoid the temptation to blow the phone up to full-screen, and instead make it a size such that design elements have proper importance.
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.
I sort of understand the taboo. Heaven forefend people know what kinds of feedback they should give. You’re “leading the audience” when you say “we’re focusing on the overall workflow, not on details like color or precise wording”!
Nope.
People are busy. Especially in high-tech, we have a hundred little details fighting for brain-space, and we context-swap all day. It’s well-known that a bit of constraint helps with creativity, and the same seems to be true of critique. Are you reviewing icon types today? Say that. Are you reviewing the user’s flow as they search their bookshelves? Say that, and possibly mark some things as off-topic.
This is something that should ideally be done at the start AND at the end of the presentation. Again, it doesn’t take long. “We’re looking at the search work flow today, so how each step flows into the next, and whether the user can figure out what to do at each point in the process. We’re not focusing on visual design — color, fonts, and so on — and we’re presuming the user has already been through on-boarding.”
At the end of the presentation, that exact paragraph, but starting with the words “As a reminder, …”
If (when!) reviewers invariably give out-of-band feedback, that’s fine; that’s what parking lots are for. The act of visibly noting something down, in the “useful but off-topic” category, helps everyone stay focused.
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.
That’s fine, but whatever solution you settle on, make sure that:
- You actually take notes on the feedback received.
- You take them in a visible way — everyone should know you are paying attention to what they say.
- The notes are intelligible two weeks later when you can’t remember the meeting.
- 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.
Whatever you do, the notes are now a gold mine, and if you sit on it, you’re a greedy dragon hoarding wealth. The feedback is very valuable, but inherently useless unless shared. (What do dragons DO with all that gold? It’s not an especially comfy bed, and it’s not like most ravaging dragons participate in a functioning economy…)
I’ve found in the past that it is best to call a meeting for the whole Dev team to talk through the notes; possibly multiple meetings, if there are a lot of notes. This ensures that everyone blocks out time to pay attention, and distributes the gold to many minds, where it can be exchanged for future improvements.
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.
These things happen. Ideally more nemawashi would have headed this off, but they happen.
In this case, you have two choices to be productive: pivot the meeting, or adjourn. The latter is a rarely-taken option — it’s hard to schedule people! — but if things are this far off, it’s probably the better option. You’ve got the wrong set of people, the wrong set of materials, and the wrong set of research and ideas in the room. So call it, and schedule another review for later, when you can address the change of environment.
If you do choose to pivot the meeting, it’s necessary to redraw the ground rules. We were talking about search flow, but now we’re talking about the visual design of two systems and how they work together to feel unified. Fonts, colors, spacing, and so on are back on the table, and we’re going to focus on two screenshots, side-by-side, showing their UI and our UI. You have to do the entire above list in 3 minutes or less, before you lose their attention — that’s why adjourning is usually a better choice.
Hi folks, Alex here. I write on Medium because I like writing and sharing knowledge.
If you enjoy what you read, it’s nice to know that all you have to do is literally move your mouse a few inches and push a button to let me know that. I don’t earn any money for this, and I don’t get anything out of it other than the knowledge that, perhaps, this bit of hard-won knowledge helped someone else.
Medium doesn’t have a “thumbs-down” or “unclap” button, but if you’ve got thoughts on that line, a comment usually works. And thanks for reading.
