How to Present Designs
No matter how utterly innovative, how pristine and beautiful a design idea is, rarely does it speak for itself when you are still in the middle of the creative process. (How can it? Short of being a complete work, it’s a fragment, a paragraph on its way to a full story.) If you are a designer or PM or architect or writer or anyone who spends most of their time living in a creative whirlwind, talking about design is an essential skill. Do it well, and you might be Don Draper, with the power to leave the room breathless, unified behind a vision that stirs an emotion deep inside your gut. Do it poorly, and you might sentence a promising young idea to an untimely death or fail to gather useful feedback.
I have sat through enough critiques, product reviews, and designer interviews to experience very tangibly the importance of a good design presentation. And good in this case isn’t about smoke and mirrors. It’s not “gee, this person is a slick, wheel-em-and-deal-em salesman who can sell rotting limbs to zombies.” You do not have to be a seasoned public speaker, and I’m not going to tell you to make eye contact or smile (though really, those things never hurt.) No, good in this case is about letting the content shine, clearly and without distraction. A good presentation ensures you’ve addressed expectations while successfully transferring the state of what’s in your head to the rest of the room. That’s it, plain and simple. That way, you can focus the bulk of the group’s time and attention on the work itself.
Let's break it down into a few concrete concrete steps. Pretend that we're still living in the post-apocalytpic, zombie-tastic world of my last design article. You’re designing and building an app called ShareVival because investing in the sharing economy is the hot new tech trend, and because it just seems useful for all the remaining humans to be able to pool their scant tools together and use them with maximum efficiency. You’re about to walk into a design review with ShareVival's CEO. What do you do?
1) Recap the feedback from last time.
This doesn’t have to be long. A few short sentences will suffice to set the context and reel people back into the mindset of the project.
“So last week, we walked through mocks for how you'll list survival items like a ZOMBIELIMINATOR™ on the app. The feedback was that the landing screen of the app was too focused on listing items and not focused enough on finding things you might want to rent. There was also feedback that listing items felt too complicated, with too many steps.”
2) Address expectations up front for what you’re going to present.
This helps set the pace. For instance, things should be moving along quicker if you’re planning to cover 7 different flows and you have a limited amount of time. Additionally, if the person you’re presenting to has other ideas for what's going to be discussed, it’s best to clear them up ahead of time.
“Today, we’re going to look at how you’re going to discover and rent items from others on ShareVival. We’re not going to talk about a simplified listing flow today. We’ve been iterating on the feedback from last week but aren’t quite ready to get feedback on it yet. We’ll review that next week.”
3) Describe the design work in the context of user goals.
Don’t just throw a mock on the screen and say “this is the landing screen” or “this is the search tab.” Users don’t talk that way, and design isn’t about filling in missing screens with some nice visuals while checking off a functionality box. Design is about problem-solving, and therefore talking about design should reflect that. Tell the story about how this particular design solves a problem. Put yourself in the user's shoes, starting with the most common goals.
“Now, we think the most common reason you’ll open ShareVival is because you're looking for something particular to rent, like a ZOMBIELIMINATOR™ or a zombie halloween mask for an infiltration mission. So when you open the app on your phone, you’re going to want to be able to search for specific items easily. That’s why we designed the landing screen to so search-centric. [Here is when you should pull up the mock for the landing screen.] So when you tap into the search field and start typing ZombiEliminator…" [proceed to complete the rest of the user story, all the way to the user finding and successfully renting a Zombieliminator.]
4) If you have multiple takes on a particular UI, it can be useful to walk through alternatives.
I say can because showing multiple versions isn’t always the right strategy. One useful rule of thumb here is that if you are really, really ridiculously confident that one particular direction is the best and you also have confidence that everyone else will agree (i.e., it won’t be controversial), you should probably just present and talk about that one direction. No need to waste time by showing a bunch of other stuff you think is clearly subpar.
But if you aren’t confident in one specific UI, or you get the sense that the room might have questions (as generally happens in design critique) showing how you arrived at your conclusion can invite better discussion. Seeing the entire history of your process and all the old ideas you tried anticipates questions like “did you try X?” or “I wonder what it looks like if we put Z in front of Y.” Similarly, showing your top two or three directions can lead to helpful feedback about how to weigh the tradeoffs or how the strengths of two different approaches can be combined.
“So with search, at first I thought that people might want to narrow their search to a particular category so they can be sure they're getting the right thing. “Zombieliminator” is both the name of a weapon and a deodorant. So if users picked ammunitions or personal hygiene first and then searched for the specific thing they were looking for…”
“But then I showed the flow to a few people and got feedback that the categories piece seemed like an unnecessary and complicated first step. The problem of differentiating which Zombieliminator you’re looking for can be done after you run the search query. We'll just show both results prominently and let you filter categories on the results page…”
“But that also wasn’t ideal because you have to do work to filter the results page. So then I came up with the idea of suggesting category filters as you type. This is a cool solution, but would require us to invest in building the infrastructure for typeahead, which is a nontrivial amount of work…”
5) Recap the feedback before you leave.
You or someone else in the room should be taking notes on the discussion and feedback. Before you walk out, end with a overview of what was discussed and what the next steps are.
“So the main pieces of feedback I’m going to iterate on for next time are to make the search input feel more editable, to continue fleshing out the typeahead idea, and to figure out a solution for what happens when a user searches for something and doesn’t get any results. Next week, we’ll also go over a simpler flow for listing items for rent.”
A bad design presentation is like going on a first date with no voice (because you're recovering from a cold) while wearing a sheet thrown over your head (because you know, you’re trying to look like a ghost or something so the zombies can’t see you.) A good design presentation is like going on a first date when you’re healthy, recently showered, and wearing a nice outfit that you rented on ShareVival (because nice outfits are rare in this era). Now, it’s no guarantee the date will be a success in the latter. But it’s a hell of a lot easier to convey who you are when you remove all the distractions. And isn’t that what dates (and design presentations) should really be about? Getting to know each other (or getting to understand the work) at a deep level?
Be clear. Learn how to talk about design. Save the world from zombies with your ingeniously designed tool-sharing app. And for goodness sakes, don’t go around wearing sheets on first dates.
