This is the first article in a series of articles where I am exploring presenting and communicating design in UX meetings. In this article, I explore the common mistakes we make when presenting design to audiences. I also attempt to lay a foundation for how we must think and approach UX design meetings.

So you spent the last month on that perfect design or feature, working in Axure or Sketch or your tool of choice and developing screen after screen of wireframes or “comps.” You know the design. You’ve iterated it with several users and developers to work out the bugs. You have hundreds of hours invested in the feature. Then comes the day to present the final version. In the space of one short hour, your design is essentially misunderstood, torn to shreds and you spend the better part of the hour discussing minute details such as button placement or branding issues that have little to do with the overall functionality or usability of the system. Sound familiar? If it doesn’t, you might be the exception as a UX/UI Designer.

Design meetings are often difficult to get through regardless of whether you are presenting a final design or just iterating on a design. I have had my share of good meetings and bad meetings. Sometimes a bad meeting just stems from a difficult feature or complex set of requirements. Other times, a bad meeting can stem from poorly communicated design (i.e. bad UX specifications, confusing wireframes or the inability to adequately communicate the design). The best meetings I have attended have shared some common traits and avoided some common pitfalls. In this article, I am going to outline the different types of design meetings and what to do (and what not do) based on the type of meeting you are in.

There are a few basic types of design meetings. There are the “kick-off” or initial meetings where you attempt gain alignment on what a feature will be and why it is needed. There are the “iterative meetings” where your primary goal is to iterate the design and/or gain approval to move the feature into development (or ready it for a final presentation to stakeholders). And, there are the “road show” meetings where you are presenting design to major stakeholders in an organization. In these latter meetings, you are sometimes seeking approval for a feature as well. But in my experience, these meetings are largely for PR purposes or to just get final sign-off and a nod of approval.

The type of meeting you are walking into will, atypically, dictate the approach you take or at least how much formal preparation you take. The road show or high- level meetings will, obviously, require more formality and preparation. The iterative meetings will allow you to take more of an agile approach where you may simply be presenting some low fidelity wireframes. And, the initial meetings will often not have you presenting design at all. They will be more exploratory in nature where you are kicking around ideas. Regardless of the type of design meeting you find yourself in, most of these tips apply (at some level) to all types of meetings.

Presenting design and navigating design meetings is a subject that lacks substantial coverage in the field of UX. But, design meetings are, often, crucial moments in the design process because they serve as “gateways” – gateways your design must pass through before it can go on to the next stage in the iterative or development process. I have sat through hundreds of hours in UX meetings – perhaps thousands or more – over the past 10 – 12 years. And, I’ve learned a few things about presentations in the process. Most of them have been due to the mistakes I have made.

Since there is so little written on this subject, I’d like to outline some of these mistakes I have made. In the first part of this article, I will primarily concentrate on a single theme – keeping on track and the mistakes that can derail a design meeting. The second part of the article, will concentrate more on those meetings where you are just trying to push the design forward from an initial state.

None of these tips are full-proof and even after more than a decade of doing this, someone still manages to “sink my battleship” on a routine basis. And, none of these tips will pull the rug over a poorly designed product or feature. But, if you aren’t doing any of these things and you are not seeing success in your presentations, these elements are worth considering or adding to your repertoire.

You’re a salesperson. So Sell.

You might think of the term “salesperson” differently than I. You might even have a negative perception of the term. But let me assure you, salesmen exist in all industries and professions. Dan Pink’s book, To Sell is Human, addresses this very topic. Whether you want to believe it or not, you’re a salesperson and you are selling your design when you walk into a room full of stakeholders. They are probably people who will not appreciate your “genius” or “brilliant design.” In fact, they most likely will not understand the process that went into it or the complexities surrounding the design. They likely will not understand exactly how it works and will spend the first part of the meeting simply sense-making. Your job is the same as any salesperson’s job – you need to show and tell them why this design is an improvement, how it works, how it addresses a pain point for the user and why the user cannot live without it. Does your presentation include that? Have you thought this through prior to walking into the meeting room?

Think of yourself as a salesperson who is selling an idea. One tidbit of a tip here: Spend a little time watching a show like Shark Tank. Watch how the participants pitch their products or designs. You don’t have to take the same commercial approach the participants do (or at least you don’t have to take it to the level they often do). But, watching how they manage and anticipate pushback as well as their techniques in communicating their ideas will give you some leverage in meetings where you find your design under fire or struggle to communicate a concept.

Why should a UX presentation be any different from any other presentation?

If this is a high-level meeting, prepare and rehearse your presentation. Would you walk into any other presentation without putting together your main points, a set of slides or other types of presentation materials? If so, then you should study up on the fundamentals of public speaking and presenting. If not, then ask yourself why a UX presentation should be any different from any other presentation. How you present and put together the material will shape the audience response. An unorganized mess with you flipping through wireframe after wireframe will leave the stakeholders confused and asking the questions that are impertinent and will fail to push the design forward.

Methods of presenting design vary based on how high-level your meeting is. You can choose to put together a set of slides for the “top brass” meetings. But, most meetings will likely not require this level of fidelity. However, you choose to organize your presentation, you should organize it into a coherent set of messages or points you would like to cover. And while not every meeting will require you to rehearse your presentation ad nauseam, you should outline an introduction, the basic points you want to cover and identify any areas where there may be disagreement.

Use the rule of threes.

For the more formal meetings, I would recommend using the Rule of Threes. In Carmine Gallo’s book, Presentation Secrets of Steve Jobs, she devotes an entire chapter to this rule. Presidents have used this method, CEOs use it, the United States Marine Corps has researched it and it serves as a foundation for great presentations. What it essentially means is to break your presentation into three primary points or messages and ensure all of your content supports one of those three points. It is essentially the three-act scenario famous plays. Stories work off of this method, as well, and it has been proven we handle three points better than two or four. So take your presentation and break it down into three points. What are those points? What are the three things you would like to highlight in your presentation? Use those as a foundation for the entire presentation. See Gallo’s book for more on this. It’s a great resource.

Develop a tagline and introduction.

You should prepare or open with a summary to develop context. Make it a summary free of jargon or buzzwords so that someone can actually understand what you are conveying or attempting to convey. Consider this summary or “tagline:”

“We have developed a dynamic design that seamlessly integrates key business knowledge and information giving you the ability to leverage key assets for greater organizational efficiency and improved workflow.”

What does that even mean? I have heard plenty of lines like this. They mean nothing to anyone and the person who wrote it usually doesn’t even know what it means.

Let’s try again:

“We have designed a system that helps you easily track your customers’ personal preferences and information. It has a beautiful interface and an integrated mobile app that will sync to the cloud so your sales staff always has the right information with them.”

Not perfect, but a little better. (And it follows the rule of threes.) I doubt a person would argue the latter statement is less comprehensible or salable that the first. It is simple, says what it means and aptly summarizes the design. The summary gives you a starting point, allows you to integrate the rule of threes in addition to setting up the selling points and enabling you to have better recall of your own presentation despite rehearsing it (if you have rehearsed it). However, keep in mind this tagline does not replace your primary introduction. You need to ensure you adequately set the context in this part of your presentation. You also need an introduction.

Your introduction should give context as you will likely be presenting a feature that is part of a larger design ecosystem. Why does this feature exist in the first place? Is it a redesign? If so, what was wrong with the previous version? How does this address the user’s goals and pain points? You may even want to consider adding the business case for the feature, depending on your audience.

You should have the tagline and introduction prepared for use in the beginning of your presentation. If there is any crucial aspect of a presentation you should rehearse, it is this part. Why? I have had CEOs and major stakeholders leave presentations so they could attend another meeting. Get your introductory content nailed down, present it up front and then hit on your major three points. Treat your presentation like a news article where all of the content is in the first paragraph (this is best practice in journalism in case the story has to be cut down in size because they chop the last part s of a news story). If the CEO leaves 10 minutes into your presentation and you have prepared your statement and content, he or she will leave with the basics.

Have an agenda or know what you want to get out of the meeting.

I’m really bad about this and have conducted my share of design reviews flying by the seat of my pants. That’s okay when you are in a design meeting, throwing ideas against the wall to see what sticks. But, it’s not okay when you are approaching a deadline or the final countdown and need to get sign-off.

Having an agenda or at least an idea of what the purpose of the meeting is, will help immensely in pushing the design forward. (And I should note here: Pushing the design forward should always be on your agenda.) You don’t have to write out an agenda for every meeting and send it out. But before you walk into the meeting, at the very least, you should know internally what it is you need to cover in the meeting and what feedback you need to get in order to move forward. You will likely get more out of most meetings than you imagined when walking into them. But, having 3-5 talking points in your head or on paper will help you stay on track (see the next point for more on this).

Establish the problem the design solves (the purpose) and keep your eye on the ball.

This point couples with the point above concerning the introduction and this most applies to features or products that are new. But, you will want to underscore the primary purpose for the design based on the requirements you and your team have outlined. This isn’t because the people you are presenting to do not know this. In most instances they do. The reason to establish the purpose is because design meetings and presentations often go astray. One discussion will lead to another and that discussion will lead to suggestions and before you know it, you are discussing changes never proposed that do not solve the initial problem you were attempting to solve. If you are in a brainstorming meeting, those discussions are perfectly warranted. If you are presenting a design that has been iterated on, you just entered the Scope Creep Zone.

Establishing the purpose of the design up front allows you to refer back to your initial point if the meeting goes astray. It also enables you to keep your (or perhaps I should say ‘their’) eye on the ball.

Designing in the meeting.

Inevitably – and in nearly every meeting I attend – there will be a number of sidetracked discussions suggesting design improvements. This is fine when it is a meeting with fellow UX colleagues. But when the meeting is with developers and stakeholders, design suggestions are problematic. Sometimes they are good ideas, but most times they are not well thought through. These suggestions are rarely rejected for a number of reasons. The primary reason is political structure. Often, the suggestion will come from a member of the meeting who has high standing in the organization. This forces consensus because who is going to disagree with the CIO, the boss, the head of development or a VP? But in a general sense, we don’t like to critique ideas in open forums. So, even if the suggestion is from someone who does not hold a higher position or have any power, we still don’t always feel comfortable saying, “That’s not a good idea.” This is one of the ways bad design ideas get built into systems.

Design is a creative endeavor that takes time and requires editing, amending and iterating…and deep thought. Save design ideas and comments for brainstorming meetings. Meetings to approve a design should merely point out problems the UX team will have to address in the next meeting. Trying to solve these problems in the meeting ignores the expertise inherent in the UX team and, instead, places it in the hands of people who may understand the business rules better than they understand the users or your design principles.

The primary thing I am stressing here in Part 1 of this article is focus. Different audiences will require different levels of focus. High-level meetings will, more often, require you to lean on your presentation skills more than your ability to wade through the finer details and granular aspects of design. Presenting at a high level requires more of an external focus where you are transparent in guiding the discussion through the points in your presentation. Iterative and initial meetings allow you to be a bit more internally focused in the sense that you may not need to be as externally focused with a formal presentation. All meetings will require some level of focus and it will be up to you to determine just how you should approach each meeting type.

Ultimately, organizations are made up of humans who form the culture. Humans are variable as are organizations. In short, every organization will be a bit different. It is quite possible you will need to consider all of the above points in every meeting you attend (especially if you are in an agency environment, for example). But in all of the design meetings I have seen derailed, it was usually because I allowed the discussion and the group I was working with to lose focus on the goals of the design.

In part 2 of this article, I will still continue to discuss some items involving focus, but will also consider some of the initial meetings you will have in the design process (where focus is not as much of a concern) and the mistakes I have made in those meetings.

Feature photo courtesy of Headway at Unsplash Photo