Presenting Design Work

This little book covers the following:

The story of a presentation that didn’t go well Why we present design work How to consider the audience and plan to work with them How to present the work How to prepare, rehearse, and manage the presentation How to get great feedback and use it

Chapter 1. When Presentions Go Wrong

WHEN PRESENTATIONS GO RIGHT

Presentations can be much better than this. Here’s what happens in a great presentation:

The audience understands what’s happening and what’s expected of them. Stakeholders listen, ask smart, relevant questions, and give feedback that’s related to their expertise (instead of opinion). You feel calm, confident, and in control. The entire team walks away able to create a much better product.

Status presentations focus mainly on the problems the design solves and not so much on the nitty-gritty details of each screen. When thinking about what you’re going to present, make sure it clearly demonstrates how it will meet the needs of the business and shows your understanding of the broader goals.

In these presentations, you’ll often have limited time, so you’ll want to establish a formal feedback mechanism. You might be able to collect and resolve some feedback in the meeting itself, but most will be received and addressed outside the meeting so you can consider it and take action later.

When consulting, and sometimes when you’re working in-house, there are two contexts in which you’ll present a “final” version of a project in a quite formal way: milestones and final presentations.

The goal of these presentations is quite different from those I mentioned above. Here, the goal is to get sign-off. For some milestones, and certainly for a final presentation, the goal is to get paid.

These presentations should be well prepared and well rehearsed.

Apart from actually creating the design, the main job of a designer is to help other people make good and informed decisions. Designers themselves don’t usually get to make final decisions about the product or service—they advise. And they do this via a lot of discussions, a lot of presentations, and a lot of listening.

Presenting your work is not about getting a pat on the back, validation of your skills, or congratulations for doing well. It’s about using the skills and experience of a large, diverse group of people to improve the product or service.

When designers don’t think they need to share their work, don’t want to ask for feedback, and don’t want to make changes as a result of feedback, it shows that there is a problem in the design process.

Make it clear upfront that any feedback at this point will inform a follow-up phase of work. Be very clear that you are asking for sign-off (and payment). Don’t beat around the bush or avoid the discussion—this is what you are here to do.

Then present a summary of everything you have presented before. Don’t add anything new. There should be nothing new to react to and no surprises for the client.

If the client attempts to give feedback, reverse a decision, or ask for additional work (and they will, no matter how well you’ve presented in the past and how well you’ve managed feedback), refer back to previous discussions and decisions. Which, of course, you have been documenting and sharing all along.

Some teams make the mistake of having only a few presentations, with the first being after work has been underway for some time. Don’t do this—people will feel like they aren’t being allowed to contribute, and their feedback can undo a lot of work.

Typical excuses for few presentations are they take too long and that clients and stakeholders change their minds every time they see new work. If you set up a presentation and feedback process early on and teach the client how to give good feedback, you’ll avoid these problems. Your client will get comfortable with you showing them small amounts of work more frequently, the presentations will be fast, and you won’t have to manage dramatic changes in direction.

Do everything you can ahead of time to find out who will be in the presentation. Find out who has been invited, who has said they can attend, and who has said they can’t. Find out what their roles are, how often they’ll be involved, and whether they influence or make decisions.

If you’re working as a consultant with an external client, don’t be afraid to talk to your contact to find out the answers to these questions. It is the professional, organized thing to do.

If you find yourself in a room with people you don’t know, ask for introductions. Yes, they might already know one another, but you can’t present effectively if you don’t know who is there and what matters to them.

Consider whether you can present to these people directly. That might mean you need to present more often to smaller groups, but it will also mean you get much better feedback and input. If I simply cannot present to people (which I find often happens in healthcare and customer support), I record a short video or give them a set of scenarios and a clickable prototype. It’s not the same as talking directly, but it’s better than secondhand feedback.

The key thing is to give everyone something specific to think about and to emphasize that you want their expertise.

Examples of what you might ask people to focus on include questions like these:

Will this design work for the core user group and core tasks? Will the design work for the content? Is there terminology that users won’t understand? Are there user tasks / edge cases the design won’t work for? Is there anything technically difficult we haven’t considered? Is there overlap with work being done by another team? Does the design adhere to brand guidelines or the style guide?

The most important time to get this right is during your first presentation to a group or the first time a new stakeholder is involved. This is the crucial moment to teach people that they have a specific role and that you want them to contribute their expertise, not their opinions.

People usually only interrupt because they’re worried they won’t get an opportunity to contribute. I’ve noticed that if they know there’s time for questions at the end, they pay more attention to the presentation, since they aren’t wasting mental energy trying to figure out how to insert themselves.

Every presentation has an audience, and you have more control over how they react and behave than you think, as long as you’re deliberate about it.

If you know someone new to the project will be attending a presentation, arrange to meet with them beforehand, and show them everything you’ve covered in previous presentations. That way, they won’t disrupt the presentation by asking questions or giving feedback on features that have been finalized.

There are a number of reasons why people can’t attend a presentation. If you know someone can’t make it (and they are a key subject-matter expert or decision-maker), arrange to catch up with them outside the presentation. Give them the opportunity to hear the same presentation as everyone else and to deliver feedback in the same way.

People tend to revisit decisions either when they are made too quickly, without enough reflection and discussion, or when they feel like they haven’t been heard. They will derail your presentations until their feedback is considered. If this happens to you a lot, look at how you are collecting feedback, and ask yourself whether you are giving people enough time to reflect and contribute

When you show a design and ask for feedback, people will give feedback. Their feedback may or may not be related to any expertise they have—could be an opinion, or could be a random thought. Very few people have the confidence to say, “I don’t think I can offer anything here” or “Looks good to me.” Almost everyone will feel they need to contribute. And the more senior they are, the more they will feel this pressure.

This is why a lot of feedback is not useful or usable. It’s why people will comment on the color or the font or suggest that the corners on the button should be rounder. They just feel the need to say something.

Prepare for this by giving people clear instructions on what their role in the presentation is and what you do and don’t want to know about. When you give people a job to do, they’ll focus on that.

Let people know how the presentation will be structured—ideally, that you’ll run through the whole thing and then discuss it at the end.

Let people know what is in and out of scope—what you’ll be discussing, what you won’t be discussing, and why you will or won’t be discussing those things. When context and scope aren’t clear, people don’t know where they are meant to focus. They go back over things that have already been discussed or jump ahead to things that aren’t yet relevant.

The single biggest improvement is to flip that around and just show the final result.

I understand why designers present their process. They’ve done a lot of hard work, solved difficult design issues, tried out different approaches, failed, and thrown away ideas. It has been hard—it took ages to come up with something that they now know is good and simple and elegant. All of that is top of mind.

But the people hearing the presentation don’t care. All they are hearing is: “I thought this thing, then I changed my mind, and this was hard.”

The first thing you should show in your presentation is the result you came up with.

I suggest starting with two core tasks that are quite similar. If some steps are repeated in both scenarios, just repeat them. Show the whole experience both times. This might feel repetitive to you, but it won’t feel that way to the audience. The first time will be too quick to take it in. The second time, they can look for the things they are wondering about.

When you’ve covered the core user tasks, show how the experience might be similar or different for people with different needs or skills. This is a great opportunity to remind people that users are not one-size-fits-all, but have different skills and use different technologies. Demonstrate how the experience sounds to a screen reader. Show what it looks like for someone with their screen zoomed all the way in. Show what it looks like in high-contrast mode. Show how it changes when people use it on different devices or screen sizes.

One reason demonstrating from a user’s perspective works well is that it forms a narrative. People love listening to stories, and stories stick in their memory.

When I’ve seen designers ask for sign-off for this type of work without something visual to support it, they always end up frustrated when the client changes their mind after seeing the ideas represented in a more tangible form.

I suggest you never present things like this as standalone design work—only present how they affect a person doing a thing. Only then will you be able to have a productive conversation about them.

Think about what your audience know and understand. If you use terms they don’t understand or find relevant, they’ll switch off, feel stupid, or contribute their uninformed opinion—none of which will give you the feedback you need.

Just use plain, simple language. Explain clearly. Help your audience understand what they don’t know.

Before you dive into the design, describe the problem you are trying to solve. This does two things: it reinforces the scope and context for the design work and helps the audience focus on what the problem is.

Describe both sides of the problem: the business and user problem, using the same sequence your client uses.

“But I need to show my value,” designers often tell me, “and talking through my process and what I explored is how I do that.” To that I say: The end result is your value. It really shouldn’t matter whether the design you have created took a day or two weeks—if the solution is good, you are providing value. If you can explain why it’s good in the context of the problem it is solving, you are providing value.

Start with the most common user scenario for the design. Work through an end-to-end story, starting with the user’s goal and ending with them completing the task (or getting as far as they can with what you’ve designed). Describe it from the perspective of an actual person. Give them a name and a back story; don’t just talk about “the user.”

Present the scenario in one go without interruption. If you stop and point things out along the way, people will start to focus on specific features instead of the overall story.

When you’ve covered the core user tasks, show how the experience might be similar or different for people with different needs or skills. This is a great opportunity to remind people that users are not one-size-fits-all, but have different skills and use different technologies. Demonstrate how the experience sounds to a screen reader. Show what it looks like for someone with their screen zoomed all the way in. Show what it looks like in high-contrast mode. Show how it changes when people use it on different devices or screen sizes.

A user-focused story doesn’t talk about features or screen elements, and discourages the audience from focusing on those, too.

The thing you absolutely, positively must not do is a real-estate tour—that is, a screen-by-screen walk-through of a page while pointing out its features. Alex did this during her first presentation. A walk-through doesn’t put the screens in the context of a person doing a thing. It draws attention to the features instead of the tasks or benefits and will earn you detailed questions and feedback about the elements on the screen instead of the overall task.

Occasionally your design work will consist of something more abstract (like a sitemap) or more detailed (like copy). These two examples don’t really fit the “person doing a thing” idea. So how do you present them?

A presentation in your favorite presentation tool:

is good if you like to be organized and plan ahead; helps you stick to the flow of your planned presentation; is easier to rehearse; takes time to prepare; isn’t as flexible: you can’t show something else if someone asks a question; can include additional supporting materials such as research results and project progress; and is a good record of what was presented and easier to share with people for later review. A wireframe or prototype demonstration:

is good if you prefer to be flexible; must be set up with care and attention to detail, so you can smoothly navigate through it—if you provide the audience with a prototype link, all screens must be linked together, so people will be able to click through them easily; takes time to prepare—you’ll want to create a version separate from your working file; requires rehearsal, so you know the scenarios work well; and may need an additional deck or document to support it with research results or project information.

The first job you might consider delegating is to have someone else manage the technology—not just setting it up, but also clicking through the presentation or navigating screens in the prototype as you take on the role of narrator. It’s easier to tell a convincing, clear story if you can focus on the people you’re talking to.

Note-taking is another area where a helper can be valuable since the process is likely to otherwise interrupt the flow of your presentation and your question-and-answer session. Notes are crucial for remembering what happened in the presentation and ensure you don’t later forget to address issues that came up.

Using your body is one way to own a room. Using your voice is another. Use intonation, volume, and expressiveness to tell your stories and emphasize your points.

If this isn’t your natural presentation style, rehearse. You’ll feel a bit silly doing it, but projecting your voice will really help you keep the audience’s attention.

Present in the lowest fidelity that will achieve the presentation’s goals. People will give feedback on what they see (even when you prepare well by giving people jobs and describing scope). If people see a beautiful, full-color, high-fidelity design with great images, that’s what they’ll give feedback on, and you’ll lose valuable time talking about visuals when you really wanted to talk about the user flow

If you want feedback on flow and content, show the design without imagery and color. This is a perfect time to show a rough sketch or a black-and-white wireframe. People who have never seen a wireframe before might wonder what they are looking at. You can reassure them that they aren’t looking at a terrible final design by showing before-and-after images from a different project that also had a wireframing phase; people usually only need a small example to understand what wireframing is.

If you want feedback on layout, use some version of fake content, so people don’t get caught up in the details of what the in-progress copy says. For years I’ve been using text from classic fiction (like Alice in Wonderland)—it’s less confusing than lorem ipsum, and people usually smile at it and understand it.

What you definitely shouldn’t present is an already-built design. Not only is it harder to make changes to something that has been built, but it also communicates to your audience that you are not listening to feedback.

Start preparing the next presentation as soon as you finish this one. Consider what you want to get out of the next presentation, then arrange the design work in between to meet those goals

If you can’t arrange for any note-taking support, consider recording the meeting. I’ve found that people usually don’t mind as long as I tell them ahead of time and explain that I’m recording, so I don’t miss anything important. This may even be your default for remote presentations, where you may not need someone to take notes at all. Instead, you can record the presentation and watch it later to make note of the questions people asked.

Rehearse out loud, even if it feels ridiculous. It’s an important presenting trick for your brain: when you’ve already heard yourself say something, it’s easier to do it again later on and sound more confident.

When you can, present on your feet. Own the room and take up space. Move your arms and gesture. Don’t huddle behind the computer—without your physical presence, it’s easy for people to get distracted.

Remotely, it may be harder to stand up since you need to remain in view of the camera (though if you can swing it, standing will improve your presence). Make a conscious effort to sit up tall, with good posture—you’ll get almost the same benefits as if you were standing up and presenting in person. Sitting up tall makes it easier to get into a pose that makes you feel confident. Breathing is easier if you have your chest open. You can gesture more easily.

Good feedback isn’t the same thing as praise. Good feedback is feedback you can use to move the product or service forward. It is:

concrete, actionable, specific (with examples), detailed and clear, and based on the person’s expertise.

Once you’ve presented the design, you’ll transition to the “time for questions” that you likely already promised would come at the end. Now that we’re here, don’t forget that you’re still in charge of the presentation. Guide the feedback portion with a few key steps:

Remind your audience what the scope is (and isn’t). “Remember, today we’re focusing on how people will get to the product page. We’ll go through the product page itself in detail next time.” Remind them of the jobs you gave them and what they should focus on. “Priya and Grant, do you think this will give local businesses enough exposure that they will be likely to sign up?” Add some general questions, like these: “What are you most looking forward to?” This prompts specifically for positive feedback, which you may not get unless you ask for it. “Is there anything that could become a problem?” “Was there anything that you expected to see today that I didn’t cover?” Ask people to provide examples to support their comments. “I’m glad to hear you find this more straightforward! Which elements, in particular, do you think are making this a better experience for businesses?” Note that none[…]

COLLECTING FEEDBACK

You have two options for when to collect feedback—you can either take it at the time of the presentation or get people to give it to you later. There are significant pros and cons to both approaches

Feedback during the presentation

It’s great to be able to give a presentation, get feedback while everyone is still present, and collectively discuss and resolve what to do about it. It’s collaborative and fast, allowing you to keep the project moving at a good pace

You will need to plan a note-taking method and explain to people what they should do before you present your work. An easy method is to ask people to use sticky notes to record their comments. Then at the end, the group puts the sticky notes on a wall, groups them thematically, and discusses them. This is often called affinity diagramming.

Another approach is to have a discussion after the presentation and record the discussion on a whiteboard while you talk about it. This helps people understand that you are listening, that their ideas have been noted, and they can see what decisions the group makes.

Don’t ever just have a chat with no visibility about decisions

If you don’t give people enough time to contribute, they will derail your presentations until their feedback is addressed.

My preference for anything of reasonable complexity is to allow people time to think and provide good feedback. It’s slower, but the feedback is infinitely better, more useful, and will lead to a much better product or service.

Let people give you feedback in a way that is easiest for them, not easiest for you. If you put the burden on them, they either won’t do it or will do it poorly. You can offer:

email, a questionnaire, a phone call or chat, or leaving comments electronically on the prototype. Then, use whatever organizational system works well for you to track responses. A spreadsheet, document, or database might be all you need. Or you can use bug-tracking or project-tracking software. Just don’t lose any feedback

Always ask for feedback

Should you ever show a design and not ask for feedback? For example, just to show that you have made progress?

I’d suggest not doing that. It’s unsatisfying for stakeholders to see work in progress without being able to react to it. It makes them feel like you aren’t listening and that they can’t contribute. Either make sure you have something to get feedback on or wait until you do.

If you feel like you need to show progress to prove that you are working, consider how you structure your work—why is there nothing you can get feedback on?

MAKING DECISIONS

Whether you collect feedback during the presentation or later, you need to decide what to do with all of it.

I find that feedback falls into five categories

Agree and now

Much of the feedback will be simple changes that the team understands, agrees with, and can be done relatively soon. They go into your to-do list to implement quickly.

Agree and later

Some of the feedback will relate to issues that the team does need to incorporate, but they can’t be acted on immediately. These will go into a backlog or added as a feature for later. This category tells people that you are listening and acknowledging that you are going to do something about their requests.

Needs research

Some feedback will be for issues where you don’t have enough information to make a decision. They may need some other kind of input, such as:

additional research with users, additional discussion with stakeholders or subject matter experts (beyond clarifications), content analysis, or analysis of analytics. Add the research aspect of these into your backlog, and again, let people know that you have listened and will be acting on their feedback.

Clarify

People will often give you feedback that you just don’t understand, especially when you take feedback after the presentation. Clarify such feedback quickly and add the clarification into one of the other categories

No

This is the hardest and most important category.

I think most designers (and product teams) do this particularly poorly, and it can be the main reason stakeholders stop engaging or give the same feedback endlessly.

You must be able to explain why you have decided not to do something about feedback people have given you.

It’s relatively easy when they have given you poor-quality feedback: there are usually good reasons why you won’t change the color palette or the roundness of the corners on a button.

It’s much harder when people have given you high-quality feedback. You have to listen, understand, reflect, and have clear reasons why you aren’t going to do something about it. It adds another level of rigor to your decision-making. This is a good thing, but it takes experience and confidence to be able to do it. And it’s even harder when you’re face-to-face with someone (another advantage of collecting feedback and dealing with it later)

COMMUNICATE IT BACK

After all this good work deciding what feedback you’ll act on and what you won’t (and why), make sure you communicate this back to stakeholders

In her last presentation, Alex tried to make some notes and answer questions on the spot.

This time, she plans the feedback process in advance. She takes a few questions in the meeting, answering the simple ones. Josh makes a note of those that need to be followed up on. She lets everyone know she’ll send them the slides, so they can go through them in more detail. Then, she asks them to get feedback to her by Friday. Later that day, she emails everyone a follow-up as promised

But when I say you will be collecting feedback during the presentation, I mean at the end of your part of the presentation. I strongly suggest you don’t take feedback while you’re presenting. It breaks the flow of your narrative, and you lose some control of the story. Let people know that you’ll take feedback at the end

After the presentation, always send people a message with clear instructions around what you want them to do and how they should do it. Don’t rely on people to remember what they’ve agreed to. Give them a deadline and follow up a few days before the deadline.

I suggest you don’t address feedback and present new information in the same meeting. Discussing feedback can be difficult. Keep feedback and new work separate. It will also feel like you haven’t listened if you are presenting something new before addressing previous issues

When the feedback comes in, she arranges a meeting with the team to go through it and decide what to do about it. They make decisions about changes that are straightforward, and they add some jobs to the backlog for other tasks. One item is out of scope for the project, so they agree not to act on it. Alex prepares a summary of their decisions and sends it to the client, showing them that everything has been considered and letting them know when they can expect to see it incorporated into the designs.

The clients are much happier overall. They know that they contributed and that their contributions were considered, and they’re able to understand the reasons behind the project team’s decisions, which gives them confidence in the team.

CONCLUSION

IF I HAD TO SUMMARIZE my key points in a single presentation slide—well, I wouldn’t. I’d make five slides, each containing one strong point:

If you plan for your audience and give everyone a job, they’ll contribute their expertise, not their opinion. If you show the end result, not your progress or process, your audience will understand what you are showing them and won’t get distracted by process details. If you present a person doing a thing and tell a compelling story, your audience will give feedback on the story, not the features. If you set up a clear feedback process and teach your clients how to give great feedback, they will give you relevant and useful feedback. If you make clear decisions about the feedback and communicate those decisions back to the client, they’ll trust that you are listening to them. With practice, these principles will become second nature. Not only will you feel a lot better about your presentation, but your team will collectively make a much better product

Communicating Design, 2nd ed., Dan Brown. When I was learning to be a designer, I almost wore out Dan’s first edition of this book. The second edition is, of course, just as good. It focuses on the different kinds of diagrams and reports we often present, so it will help a lot if you are still wondering what to present

Design Is a Job and You’re My Favorite Client, Mike Monteiro. I group these two books not just because they are by Mike, but because you should read both of them. Together, they will help you work well with clients. It was at a workshop with Mike that I first heard anyone talk about teaching clients how to give feedback, and my presentations became better immediately after

Designing for the Digital Age, Kim Goodwin. Kim’s book covers just about everything you’ll need to know to design digital products. It’s packed with practical details on the design process, interface design, and so much more. I mention it here, not only because it is great, but also because it’s one of the few books I own that actually covers presenting design work