This is the third article in a series of articles I have written exploring the management of UX design meetings. The first article in the series explored the common mistakes we make in design meetings and how to avoid them. The second article explored 9 methods to improve your design meetings. In this article, we’ll concentrate on methods you can use to defend your design.

The attack came at 10 a.m. on a Tuesday morning. The enemy wore business suits and were fueled by steaming mugs of coffee and bagels with cream cheese – bagels, ironically, you had supplied. The target: Your latest design. You were prepared for the meeting, had rehearsed and spent the past 3 weeks iterating and pushing the design forward. There was only on problem: Your defense was weak and sometimes non-existent.

You weren’t prepared when an alternative to your design was suggested. You weren’t prepared when the icons you were using came under attack or when the navigation structure was questioned. You had no alternative designs to illustrate why your proposed design was better. And, you most certainly were not prepared when one executive pulled out their smartphone to suggest you use a pattern they liked in one of their favorite apps. You had just been outflanked and overrun.

Scenarios like this have happened to me many times. I still have meetings where I walk out of what felt like a slaughter. Most of the time, it’s my fault. And almost all of the time, I could have avoided the “slaughter” with a little more preparation.

How do we adequately prepare for the defense of a design? This is exactly what we will explore in this article.

Who is the designer?

Before we delve into methods of defending and communicating your design, there is a point to be made concerning the scenario above. The stakeholders and executives are not “the enemy” as I describe them. Viewing them in this light will always have you playing defense. They are your partners in the design process and you need to form relationships with some or all of them to be successful in design.

Additionally, everyone who has any influence over the design is, in part, a designer. I realized this can be construed as a controversial statement. But, think about it for a moment. You likely rub shoulders daily with stakeholders who have the power to shape and influence a design. While they may not draw up the interface or understand the user the same way you do, they do make decisions that impact the user.

An example: eBay has a default setting when you sell an item and prepare to ship it. If you are shipping USPS Priority Mail, you can receive free insurance of up to $50. But, there is another method of insuring an item that will cost you. The dropdown menu always defaults to the method that will cost you (probably because eBay makes more money this way). That decision surely could not have been made by a UX designer (if it was, it was a bad decision). It would be very simple to write a script that would default you to USPS insurance when the item you sold is $50 or less and you choose USPS Priority for shipping. This decision was probably made by someone in finance or business to increase revenue – someone who never drew even so much as a box on a screen or talks with users on a regular basis. That person, in part, designed (badly) that single aspect of the system – one that is frustrating to the user.

You have to shift your mindset as a designer to understand the holistic nature of design. The design can be influenced by those who have no idea how to push the pixels or how to conduct user research. But, they still design – just in a different way.

Developers and business analysts often come to me with diagrams or their version of a wireframe to explain some idea they have. I used to bristle at these encounters thinking they were encroaching upon my territory. I’ve gotten over this and now welcome such encounters because they start the conversation. They are also ways business analysts and developers use to translate the requirements as they read or understand them. I actively attempt to involve these people in the design process because I consider them part of it. And, as I will explain below, I need people on my side with buy-in when I sell the idea in a high-stakes meeting.

In short: If you are going to successfully sell or defend your design, you have to involve those who do not push pixels and make them feel as though they are part of the process. You have to get over yourself and your profession. And, you have to understand the design process from a holistic perspective recognizing the design is influenced beyond just the UX team. I think we have spent so much time advocating for our profession over the past decade that it is sometimes hard for us to see things in this light.

Use guiding principles and foundational elements for design.

Guiding principles and style guides will often be your best friend in defending a design. Perhaps you call it a playbook (a cliche and overused term, in my opinion). Whatever you call these principles, they often serve as a foundation in how you approach a design. They can also serve as an aid when a style is suggested that does not align with these principles.

For example, I work in healthcare UX and patient safety is often a top principle. Thus, if a design change is suggested in a meeting that would impede patient safety or induce an error, I always win that battle because I can site the principle. This gets a little tougher when your principles are more vague (such as “simplicity in design”), but usually still works as a selling point if you set the argument up correctly.

Style guides are fairly black and white (or binary). So when a suggestion is made concerning a new navigation pattern or an icon is questioned, style guides are usually a good defense. If you are working with Atomic Design and a component library, you are in an even better position.

The key is to ensure your principles and style guides are communicated throughout your teams. Primarily, this involves ensuring they are agreed upon. This agreement may not include your stakeholders, but it will include your business analysts, product managers and developers. These people will be key allies for you when defending design decisions.

Bring your numbers to the meeting.

If you have user research, either quantitative or qualitative, around your design, ensure you have that data with you. Additionally, if you have data and analytics, those numbers will surely help. There is virtually nothing more powerful than numbers or the voice of the user in supporting your design decisions. If you have analytics suggesting users abandon the shopping cart on your website 40% of the time and qualitative data from the users explaining why this occurs and your decision provides a solution, then you have a very strong argument.

When you don’t have data and analytics or user research behind your design, you have little more than a hypothesis and a very weak point in your defenses. I am often in meeting where that is exactly the case. I have to explain that we have user research scheduled and right now we are using the designs being presented to test our hypothesis. But, you can still use articles or foundational books from our profession to help support your decisions and I have used this technique on a number of occasions. After all, whatever decision you have made in the design has probably been made before and can be supported with secondary research.

Minimize and control the options you present.

There are a lot of designers who will advocate for only showing a single design in a proposal. The guiding philosophy behind this is that if you have done your due diligence in designing a feature, you should not have alternates because you will land on the best design solution. I think this is a valid philosophy in certain ways, but ignores the defense of a design and primary sales tactics. (Remember: Proposing a design is essentially selling a design.)

What the above philosophy ignores is the comparative factor that is inherent in selling almost anything. Let’s suppose I were a car salesman and pitching the benefits of a vehicle to you. I would probably attempt to find out what other vehicles you were considering and then compare the benefits of the vehicle I want to sell you against the benefits of the cars you have been considering. I might even compare models within my own brand or other cars on the lot. This comparative factor allows me to highlight the benefits and features of the product I am trying to sell you. This is why comparison pricing tables are so popular on websites (especially automobile websites where you can compare different models and features).

You can conduct a similar comparison with your designs. Perhaps, you iterated through a number of solutions – many of them you rejected because they would not work as well as the current solution. Keep those wireframes and have them handy in your meeting with stakeholders. It’s likely one of the solutions you already rejected will be proposed by a stakeholder. You can then pull up that feature and explain why it did not work and how your team landed on the current design.

Also, you may be in an exploratory phase with the design where you are seeking feedback on varying options of a design. In this case, it is quite appropriate to present alternate designs as long as you do not have a clear reason based on design principles as to why they will not work.

Generally speaking, you should minimize the number of design options you present. Ideally, you have a single proposed design and alternates to illustrate why the proposed design is the best design.

Uncover the real reason behind an argument against a design decision.

It will often happen in a presentation – a stakeholder will suggest a different pattern or you should move something from one area of the screen to the another area. Sometimes these are good suggestions – things you didn’t think about in iterating the design. Other times, they are whimsical suggestions derived from baseless preferences the stakeholder has.

First, you need to know your stakeholders. What makes them tick? What are there stakes in the design? This is more difficult in an agency setting and easier if you work in an organization where you regularly rub shoulders with them. You will have to do the best you can with the situation you find yourself in. But regardless, you will need to probe and determine the real reason behind their argument for a change or their argument against a design decision your team made.

If you have a good relationship with the stakeholder, it’s as simple as asking why they feel a change is needed or why they don’t like a certain aspect of the design. You need to determine if there is a good reason behind their suggestion. Your stakeholders have a different purview of the business than you and I have had many meetings where discoveries occurred during these interactions changing my team’s approach to the design or feature (hopefully your research uncovers this in most instances).

If the suggestion is just personal preference and baseless, you will either have to quickly formulate an argument or use my favorite: The delay tactic (see below). Whimsical requests can be difficult to manage depending on the situation you find yourself in. But, they can be managed in many instances and the design should not be steered in the wrong direction on a whim. I have often found simply asking the user to articulate their argument or their rhetoric concerning a requested change will suffice. Once they begin to fumble over their words and realize their request has little or no merit, the wind is quickly taken out of their sails.

Use the delay tactic.

You will undoubtedly find yourself in situations where you do not have a ready answer or argument for a design direction your team has chosen. I tend to be a thinker. I do a lot of thinking about a design upfront before it even sees a boardroom projection screen. But, there are always curve balls. There is always something I did not think through with enough detail. I then find myself “put on the spot.” It’s my own fault.

When something like this happens, I am usually able to think more deeply about it after the meeting when I discuss it with my team. So, I will delay such conversations in the meeting and choose to “fight another day” after having put some thought into the issue.

The key here is to ensure your stakeholders understand you will take their suggestion or argument as an action item and give it due consideration. After all, this is one of the purposes of a design presentation – to refine and iterate to a better design so you can close the sale. Nothing will irritate stakeholders more than designers with prima donna attitudes who will not listen or consider the stakeholders’ opinions of value in the design process. Have someone delegated as a notetaker and make a verbal request to them in the meeting that the issue be logged so the team can work through it after the meeting.

The delay tactic will allow you to think and consider the suggestion. As I note above, the stakeholder may have a good suggestion you adopt. If not, you will be better equipped in the next meeting to argue for an alternative or the original design.

Form a posse and bring it.

Who doesn’t want a posse? You need people on your side in meetings where you present and defend a design. And, you don’t just want your design “cronies” in the meeting as part of your posse. You need your supporters to be from different disciplines. Ideally, you have some business analysts, a product manager and a developer or two in the room who will support you.

People atypically don’t like to go against the crowd. It’s in our DNA. So the more supporters you have on your side in a meeting, the stronger your defense will be. This isn’t to say you should use those supporters to beat down any suggestions or arguments. You should still give arguments and suggestions due diligence and consideration. But, having a team of supporters who understand the design and the concepts behind it will better enable you to handle the dominant stakeholder in the room who simply wishes to get their way and shape the design based on their own personal preferences.

There is one other aspect of bringing supporters you may want to consider – “The Ringer.” This term comes from television where they will have prearranged calls with questions to prompt discussion or generate audience interest. Tom Greever mentions this concept in his book, Articulating Design Decisions. And, it is particularly ingenious at how he presents it. Greever writes:

“Whether it’s a news broadcast, talk show, or reality TV, there are always people whose answer or reaction the show’s producers have prearranged. They might need help building energy and momentum to make the show feel more interesting. The ringer might be the anchor who asks a good question of a reporter that he didn’t cover in the initial story. Or the ringer could be an audience member asking a question to communicate something that’s more effective coming from an average person than the expert host. Whatever the case, a ringer’s purpose is to bolster support for an idea.”

There’s absolutely no reason you cannot employ this technique in a design review. Have your supporters ask questions that are not asked or point out something you would normally point out. It is much more powerful when you are not the only one talking in a group. This, of course, requires you to have supporters (the subject of another article) and those who are onboard with your design decisions. But if you have been iterating the design with their involvement, this should not be a problem.

Sometimes defending design can be the wild, wild west. And that’s why you need a posse. (I couldn’t resist working this metaphor in.)

Maybe you are just, well…wrong.

You can’t be right all of the time and will inevitably run into a situation where someone points out something you hadn’t caught in your internal design reviews. Sometimes we are just wrong about a direction, a design choice or some other decision we made. You are a designer and should get used to being wrong. We create new shit on a daily basis and not every design or idea is going to be a home run. Accept it, admit defeat and move forward with a better design.

If you work with good stakeholders (and I have been lucky to work with some good business analysts and product owners over the past 5-6 years), they will be sharp and will be quick to point out a flaw in the design. This article isn’t about being right. It isn’t about pushing bad designs through to production. It is about defending solid design choices and pushing out the best product you can with the resources you have for your end users.

Always keep in mind: You might just be wrong and the stakeholders might be right. We must always question ourselves as designers and creatives.

Defending design takes experience and the techniques listed herein will give you an edge. I would strongly suggest employing multiple techniques from this article and using these principles in tandem. Synergistically, they will create a stronger defense for you and help you through even the toughest of meetings.

Feature photo by Anna Ogiienko on Unsplash