Project Description

Project Description

PRESENTING DESIGNS

The single most critical skill a designer must master is being able to clearly and concisely present designs to non-designers and technical partners.

What it is

Design presentations are the foundation of every designer’s job. It is how you explain your solution to a problem. If you can’t explain the solution, you won’t get buy-in and sign-off from your clients, business partners and stakeholders.

How its used

Design reviews, presentations and other discussions about solutions to problems happen at every stage of product development, from pitching to investors and stakeholders when you might be presenting concepts, to walking engineers and PMs through wireframes and prototypes, to presenting designs to your colleagues or company VPs.

Each presentation requires a different approach. But all depend on the designer’s ability to clearly state the problem she’s solving and explain the reasoning behind each of her design decisions.

“How to present a new idea is, perhaps, one of the designer’s most difficult tasks.”

Paul Rand

Discussion

The goal in any design conversation is to explain the problem you were tasked with solving or the goal you’re attempting to achieve, and then present your solution. Along with the reasoning behind it.

This isn’t hard if you have a reason for every decision in your designs. It’s impossible if you don’t.

Start with why

The primary reason you make any design decision is to get people to do something.

At least, I hope that’s why you’re making a decision.

If the PM asks you to include a notifications permission request in the onboarding flow, but you know (from usability testing) that everyone skips that screen and definitely do not give their permission for notifications, then you have to come up with another solution. Your goal is to get users to grant permission. When you present that other, different solution, you start with why you made the decision you did.

All our testing showed that users are skipping the permission requests in onboarding. So I designed this user flow to ask for permission at a place where users are most likely to see the value in giving it.

Even if the audience is different and your approach is different — for instance, you will have to get very technical when talking to engineers, and much less technical when talking to the VP of marketing — you still start with Why.

For engineers: We designed a soft ask as a slideup screen in the app so that if the user say’s no, we don’t have to serve the system permissions modal. That way we preserve our opportunity to ask for permission later in the user journey.

For the VP of Marketing: We’re asking permission to serve notifications in multiple places throughout the app so that we can maximize our chances that users will say yes. Once we have permission to serve notifications, we have a better chance of bringing users back to the app daily, which increases their stickiness likelihood.

Don’t present too much at once

UX your presentation. You must be savvy about how you tell the story of your solution.

  • Don’t overwhelm your audience with too much at once.
  • Give everyone plenty of time to absorb what you’re showing and what you’re saying before you move on to the next idea.
  • Keep your slides simple. Don’t put text on the slide, only the work should be on the slide. The more you write, the longer it takes them to read it. That means they’re reading instead of listening to you or looking at the design.

Instead,

  • Talk through the work.
  • Explain the rational.
  • Ask for questions.

Try to keep control of the narrative

Everyone has been at a meeting where the leader lost control. Instead of walking attendees through a clear narrative, attendees hi-jack it with a series of questions. Often out of order. Sometimes off topic. Remember how chaotic that felt?

Avoid this at all costs.

Design is about logic, goals and solutions. It requires careful discussion and everyone in the meeting needs to understand the rationale behind each decision (or else they come to your desk later, confused and peevish).

Questions are good. You want questions. But you want them at the right time and in the right order.

So take pauses and ask for questions. If people ask about designs you haven’t presented yet, or that you haven’t completed yet, politely put a lid on that.

“I’ll walk everyone through that user flow on the next slide. For now, let’s focus on how this UI meets our needs.”

Get the focus back to the point you’re making right now, the slide that’s on the screen, the design under discussion.

Never ask anyone if they like your work

Design isn’t subjective, no matter what some might say. Good design is a solution to a problem. Some solutions are better than others, and some come with more trade-offs (time, cost, effort) than others. All of that should be discussed in a design review.

Whether stakeholders, engineers or the PM “like” what you designed is immaterial. Try not to introduce that subjective POV into the discussion. Keep it data-focused.

More than that, you’ve been hired because you’re the expert. If you start asking your stakeholders what their opionions are, they’ll lose confidence that you know what you’re doing.

“Why are you asking for my opinion about the UX, don’t you know the best solution?”

If you’re not the expert, then you’re an order taker and you don’t deserve the (hopefully) big chunk of cash they’re paying you for your expertise.

But what do you do if they tell you they don’t like something?

Sometimes clients or stakeholders will volunteer that they don’t like something. What then?

These are critical moments in any presentation. You can’t dismiss comments coming from people who may be paying your salary or making the final decision on what designs will be implemented. But you also can’t fall into the trap of allowing subjective opinions, even if they come from high-status stakeholders–even if they come from the VP of marketing or the CEO himself–to derail a good user experience.

So you must bring the conversation back to the problem that’s being solved, the data you’ve got around that problem, and how this solution addresses those issues. Hopefully, this makes it clear that no one’s personal opinion is the determining factor in whether a design will be implemented.

And if they point out an error, or have a suggestion for an improvement you’ll win big points if you’re quick to acknowledge it. Ego is the enemy of good design, so leave yours at the door.

Objectives

  • Understand why we present designs

  • Learn principles of presentations

Tips & Tricks

Design is solving a problem. So always start by reviewing the problem you’re solving. Then provide the solution, and include any learnings from research and usability testing, either in the past or as part of this design job.

Resources

Your Assignment

Practice good design presentation skills

This will work best if you can buddy up with another designer and take turns presenting to each other:

  • Create a deck with designs you’re presenting. Think about who you’re presenting too, and what point of view to take (e.g. technical, non-technical, pitch work)
  • Explain the problem, solution and rationale for every decision.
  • Ask your audience for questions and practice answering the hard ones!
  • Stay on topic. Ask your audience to try and derail the conversation with out-of-order questions so you can get used to pulling everyone back to the topic.

Deliverables

Write up your experience, including areas you need to practice and post them in the comments and/or on Dribbble and Twitter #100daysdesign.