Articulating Design Decisions

I’m intentional about using the word support, rather than, say, approval or agreement. We will not get everyone to agree on a specific solution. Approval isn’t the point either because it implies a certain amount of consensus. That’s okay because that’s not what we’re looking for. We’re looking for their support—of us, our expertise, our solution, or our plan for moving forward.

Eureka! Our solution seems so obvious that there is very little need to waste time considering any other approach. (After all, we’re on a tight sprint and need to get something to the client by the end of the day.) Yet, this thinking almost always creates a conversation that we’re not prepared to deal with: when the client suggests an alternate idea that we haven’t considered.

The point is this: be consciously aware of why your design decisions are better than the alternatives. Just like the previous two questions, write down your answers. Make a list of the other ways that you could solve this problem. Create a bunch of alternative designs, don’t throw them away, and have them available if you need them. With those alternatives, make a short list of why you think they don’t solve the problem as well as your proposed design.

Sometimes, I create very simple wireframes of the alternatives in addition to my recommendation. When the client begins asking questions about my proposed solution, I can quickly show these to visually demonstrate the differences.

If we’re going to be successful at communicating with people about our designs, we must be able to answer these three questions about our work: What problem does it solve? How does it affect the user? Why is it better than the alternative?

When other people realize that you’ve put thought into it and are being intentional, they’re more willing to trust you, even if they disagree. That’s how you become a great designer: by describing and expressing your designs to other people in a way that makes sense to them.

“If your design requires an explanation, then it’s not very good.” As if you could expect to just hand your stakeholders some mockups and wait for them to give it a stamp of approval. Yet, it’s surprising how much a good relationship can affect another person’s view of our work. Having good relationships really does make our designs more acceptable to the people who matter.

One way to make our meetings easier for stakeholders is to set the context at the beginning. That is, to start the meeting with a reminder of the goal for this project or design, where we are in our process, and the kinds of feedback they can expect to provide. We should also make it clear that the purpose of the meeting is to get their support to move forward, not necessarily for them to riff on whatever they see.

The first thing you should remind them about is your previously agreed-upon goal for this project or design. This should ideally be an improved business metric or the outcome we expect, but it might also be framed as the feature or output of your work.

Second, briefly remind them of the discussion you had last time or the decisions you made together.

Next, create a visual that will help them understand where you are in the process of your design. Typically, you can express this as a horizontal line where the left side is the starting point (research, low-fidelity mockups) and the right side is the finished design (high fidelity, ready to ship). Highlight where you are

Also, tell them the kinds of feedback that are helpful at this stage in the project and what feedback is not needed yet.

If you go to two meetings and the same distraction comes up both times, you’re doing it wrong. Take the time to discover the distractions and remove them so that you can focus on the real issues regarding the effectiveness of your designs.

Bringing alternatives (especially those that aren’t the recommended solution) complicates the conversation because it forces us to have a well-articulated explanation for our choices. Many designers avoid this by not presenting alternatives that they don’t recommend. The fear is that the client will prefer the “wrong” concept and insist it be used. Even though this is always a risk, approaching our meetings with this fear actually undermines the purpose of articulating design decisions.

What we really need is for them to support our solution, even after considering all of the alternatives. We can’t protect them from all the ideas that might be suggested. Instead, we arm them with the knowledge and language for why our decisions are best.

You’ll want to have these alternative designs and mockups as evidence that you’ve tried these other approaches with an understanding of why they weren’t as effective as what you’re proposing.

More than simply addressing someone’s suggestion, bringing alternatives creates a common place to discuss the merits of each option—a place, by the way, that you created and you control. If you come to the meeting with no alternatives, your stakeholders are going to search the Internet from their phone and propose the first option they find.

I recommend being forthright with people about your need for support. It’s okay to ask people to support you in advance. The purpose is to build a case and demonstrate that other people agree with you. Be open with people about your need for support, ask them to help you, and tell them to speak up when the situation calls for it.

have two approaches to async design discussions. Approach #1: Don’t Seriously, just don’t do your design meetings like this. Avoid it as much as possible. It demeans your work by putting an undue focus on the visuals, while allowing anyone to have a knee-jerk reaction without you to help them understand your thinking. Making decisions this way with your own team can be useful when you all have a shared understanding and vocabulary, but too much gets lost with nondesigner stakeholders.

Approach #2: Use Video To get around the drawbacks of async communication while still valuing everyone’s time and attention, I recommend recording your design presentation and sharing that video rather than using static, pasted screenshots and direct messages. This means using screen recording software and walking through your designs as if you were in the room together.

I’ve found recording videos like this to be very effective. Not only that, but my stakeholders love them, share them, and ask me to keep doing them. It’s a win-win. Here are a few tips for making your videos effective: • Write a short script so you know what to say, but don’t sound like you’re reading. • Keep it short. 2 1⁄2 minutes is the perfect length, I’ve found. As much as 5 minutes might be necessary, but try to keep it as short as possible. • Include a picture-in-picture of your webcam so they can see your face. Not all software allows this, but if you can do it, it will add a human touch that is beneficial. • Share the video with a link; don’t send it as an attachment. You don’t want to clog someone’s inbox. Sometimes attachments in email or chat software get stuck. Using hosted or streaming video services (YouTube, Vimeo) are best.

We can help our stakeholders understand the real problem by asking questions and repeating it back to them. It’s okay to ask them directly, “What problem are you trying to solve by suggesting this?”

One last implicit listening technique is mastering the art of the pause—when you think your stakeholders are done talking, just wait. Don’t immediately jump in with your response. Instead, pause for several seconds (maybe two or three) and allow for silence, however uncomfortable that might seem. This can actually be a little awkward, especially on a conference call or video chat where there are frequent delays and it might be difficult to tell if you’ve dropped off. [..] it’s worth risking the awkwardness to be sure that your stakeholder is finished talking and that there is a small gap in the discussion. If the silence is too awkward, you can create a gap by saying, “Let me think about that for a second.” Anyone will appreciate that you want to take the time to consider what they’ve said.

Because you didn’t jump directly to a conclusion, you create a sense that what they just said was really valuable. People want to be heard (or at least to feel that they’ve been heard), and pausing shows them that you take their feedback seriously.

To summarize, taking notes is a critical part of listening to stakeholders. It’s important to write things down so that we have a history of what was decided, know why we decided it, and avoid having the same conversation twice.

What do you suggest? Often stakeholders will say something needs to change without any idea about how that will be done. Even though it’s our job to find the solution, giving stakeholders an opportunity to propose something helps us understand their needs and gives them some context to realize the difficulty of the problem.

The most important way we can do this is to help our clients move from talking about what they like and don’t like (which are their preferences) to what works and what doesn’t work (which is the effectiveness of the design). It’s too easy for someone to say they simply don’t like something. A subjective response like that gives us no way to address our stakeholders’ concerns because it’s not possible to tell them their opinion is incorrect.

For example, “I understand that you want us to move that UI control over there, but why doesn’t it work to have it over here?” When people hear their concerns rephrased inside a frame of effectiveness, they often recognize that they’re only expressing a personal preference.

Another way to help our stakeholders communicate more clearly is by repeating back to them what they said using words that are more relevant to a discussion of design and UX. Because we don’t expect that they’ll know all the “right words” to describe our designs, we have to listen to what they’re saying and translate that into a vocabulary that will become our common ground. Leading with the phrase “What I hear you saying...” is the best approach to accomplishing this because it emphasizes that we are listening to them, understand what they said, and will now confirm it by expressing it in our own words.

example: Stakeholder: I don’t like how the disabled buttons look. I have no idea why they don’t work! We should add some help text or a tooltip or something. Designer: What I hear you saying is that you don’t think a segmented control is the best choice in this context, because the user won’t understand why the disabled options aren’t available to them. Is that right?

It’s nothing more than taking on the attitude that your work is not your own. It’s making the simple recognition that you can’t control everything. It’s admitting that you need help from other people to create the best experience. It’s a mental practice of taking two steps back, getting out of your bubble, and walking around to the other side of the table to sit with your stakeholder. Armed with empathy for their perspective, it becomes much more natural to allow their feedback to exist separately from your own personal interests. If you can convince yourself of those things, you’ll be in a healthier place to talk about your designs with others.

The red flag is when you find yourself thinking that your solution is so much better that you don’t see value in the other person’s suggestion. In normal, healthy discussions, you can see the value of another person’s idea, even if you disagree. When your ego is getting in the way, that value is lost. Any time you think that you’re right and they’re wrong, you should be cautious.

Leading with a yes means that you always begin every response with a positive affirmation of the other person’s idea or request using the word “yes.” It is a mindset that this person isn’t wrong. They have just as much potential for good ideas as you, and they’re a valued part of the process. Dave calls this the “yes reflex”: Most of us have a “no reflex” to new and creative ideas that seem impossible. But you can change this... the next time someone brings up a new opportunity, make sure the first word that comes out of your mouth is yes.... The yes mindset gives outrageous, seemingly impossible ideas a chance to live and breathe and sometimes be implemented in whole or in part.

However, it’s not always easy to say yes when you disagree. If you understand the problem your stakeholder is trying to solve, but you disagree with the solution they propose, leading with a yes might sound like, “Yes, I completely agree with you that we need to reconsider the placement of this UI control.” We’re not saying that their precise solution is correct and that we will implement it in that way. We’re only agreeing on the problem because it might still be possible that another approach will solve it.

Often, our stakeholders just want to know that we value their time and feedback. Leading with a yes can have the effect of disarming the person just enough to demonstrate you’re listening and open up the possibility that you can be trusted with the solution.

I was in a meeting with several people, including the president of the company. He began nitpicking one specific part of the design. It was an important part of the experience, but his feedback involved very specific suggestions about the placement, copy, color, and interaction. Although I was happy to address his concerns, his feedback seemed misplaced. Why would an executive care so much about these little details? Rather than get into a discussion about it, I said “Yes, I agree with you that we need to reconsider the implementation of this menu.” Abruptly, he stopped, and said, “Great, I know you guys will find the right solution.”

Instead, leading with a yes is about reminding people of the areas where we agree, before we get to the parts where we don’t. It’s about demonstrating that we’re all on the same team, headed in the same direction, even if we have different ideas about how to get there.

There are dozens of ways that you can lead with a yes without actually committing yourself to anything. Here are a few: • Yes, that’s a very good point. • Yes, thank you for sharing your perspective. • Yes, I agree that we need to solve this. • Yes, there are definitely some ways we can improve this. • Yes, we should decide the best path forward. • Yes, I understand where you’re coming from.

One caveat is to avoid following the word “yes” with the word “but”—it turns out that “Yes, but...” is just another way of saying no, and most people will hear it that way. Even “Yes, however...” communicates a similar feeling. I’ve found that you can often just leave out the “but” or “however” and the sentence still works. Instead of, “Yes, but our team looked into that,” you can simply say, “Yes, our team looked into that.”

People without confidence don’t smile; they look concerned, worried, upset, or distant. If we want to convey confidence, we should smile as much as possible. When you’re meeting with stakeholders, make a conscious effort to smile even if it feels a little awkward.

Don’t say “you’re wrong”—no one likes to be told they’re wrong (even if they are), and you’ll only make them defensive. Remember, your goal is to stay positive and always lead with a yes. Even directly telling them you disagree can be a flash point for the conversation. If you need to disagree, find ways to communicate that disagreement as an alternate idea or a different perspective.

Don’t start any sentence with “From a design perspective...” because that’s usually just another way of saying “from my perspective.” Remember, we don’t care about your perspective; we care about the user’s perspective. Plus, this sounds like you’re trying to one-up them with your expertise in design. Although your expertise and perspective is indeed valuable, it’s not usually necessary to point it out.

Don’t talk about what you like or don’t like; instead, focus on what works and what doesn’t work. Remember, our interest is in the usability and effectiveness of the application, not our own personal preferences. In fact, remove the word “like” from your vocabulary altogether.

This is more difficult if you’re discussing the visual design of an application, rather than specific flows or general usability. If the express purpose of the meeting is to review the visual design, you still need to find ways to communicate why you think the visuals work or don’t work rather than why you like or don’t like them.

The first thing you should do is thank your stakeholders. It’s the most polite way to get from what they said to what you want to say, and it recognizes that their time is both valuable and appreciated. We always want our stakeholders to know how much we appreciate their time and attention.

Next, briefly summarize what the stakeholders just said if you haven’t already. I don’t mean that you should go over each point line by line from your notes. Instead, make a statement that describes what they’ve just done

Lastly, tell your stakeholders that you’re about to respond to their feedback. Perhaps it seems obvious (and it is), but the transition is meant to provide a segue for everyone.

It’s not enough to just tell stakeholders that you’re going to respond. You need to give them some insight about the content of your response; you’re foreshadowing what’s to come. You should tell them not only that you’re going to respond, but how and what you plan to say. This is an opportunity to let the cat out of the bag, to clue them in as to what your feedback will be to ensure that there are no surprises.

“Thanks for sharing your thoughts with us about this project. Your insights are really valuable, and I appreciate you going through all that with us. I’m going to go back through all of your points so that we can discuss them, but I’d like you to understand how we came to these conclusions first...”

Interestingly, people will often believe what you tell them, so tell them that they will agree with you! Even if they don’t, you’ve at least set the stage in a positive way.

Here are some other examples that might deal with more specific feedback: • “Thanks for pointing out the differences between the existing app and our new designs. You’re right that there are some important things we should consider, and I want you to know we put a lot of thought into how we designed it, so I’d like to explain to you why we did what we did with the grid views.”

“Thanks for being up front that you’re concerned about our implementation of the cart and checkout flow. I’m going to address each of your points because we had some very specific reasons for doing it this way that I want you to be aware of. I think you’ll agree that this is going to increase conversion once you understand our thought process.”

“Thanks for your viewpoint on the home page. You’ve definitely given a lot of great feedback and I’d like to go through it all, if that’s okay. Our thinking about the layout had more to do with our long-term vision and some other initiatives that we expect to see down the road, so it’s important for you to know why we approached it in this way.”

The point is this: it’s not enough to just launch right into a defense of your work. You must take the time to get in the right frame of mind, stay positive, and make a graceful transition to what’s next.

What problem does it solve? • How does it affect the user? • Why is it better than the alternative? The answers to these three questions form the basis for every response you provide to stakeholders. If we can communicate these three things, we’ll set ourselves up for success.

You want to find the thing that you know your stakeholders care the most about and connect it to the proposed user experience.

Beyond the design, questions came up about other metrics: “What about cart abandonment? Overall conversion? Didn’t those matter too?” In these conversations, I could point back at our goal for the phase (increasing add-to-cart) to remind them of that focus and why we believed these decisions would improve that KPI. Without this previously agreed-upon metric, we could have easily allowed the project to morph into a monster of addressing each concern that came up, and the result would have been a mess. Instead, we kept our designs laser-focused on the problem that we were asked to solve.

In one app like this, we had a set of filters that the users could check and uncheck. The page was updated instantaneously, without even the need for a loading indicator, but some of the users we observed didn’t realize the search results had been updated, so I added a Done button that closed the filter panel and gave them a sense of completion.

When I presented this change to our stakeholders, I had to justify the addition of a button that seemed unnecessary and did almost nothing, yet took up space in the UI.

In our usability study, people didn’t realize that the search results were being updated automatically, so we added the Done button to give them a way to explicitly indicate that they were finished. What would be better is to present the same idea as a story (or use case) that describes a real situation for users. People are distracted while they shop with the app, and they need to indicate that they’ve finished filtering. The Done button allows them to do that and gives them a sense of control over the filters. What would be best, though, would be to tell a story of one user who makes a good spokesperson for others, using human details that encourage a connection to their needs. We had a parent using the app in-store with their kids. They didn’t notice the results updating and tapped multiple times, becoming frustrated. Giving them this Done button will make it clearer and show them products more quickly.

Even though we probably do a pretty good job of solving problems and making things easy for users, we are less adept at helping people understand why and how our designs are the best approach. Being intentional about demonstrating this is important to communicating that value.

Every response should focus specifically on the differences between each design and express why your own solution is best. More than that, you must show your stakeholders precisely why that is the case. Being able to identify and express these differences is an important skill in articulating design decisions.

Rather than argue about sticky pieces of paper on a wall, I instead jumped into prototyping mode and built a simple frame-by-frame demo of how it should work. The result was immediate support, like light bulbs going off in everyone’s head as they saw the difference. The original flow felt confusing and error prone as soon as we held it in our hands. The newer flow was simpler and obvious.

When talking about design, I suggest five tactics to shape our response: Show a comparison Propose an alternative Give them a choice Ask others to weigh in Postpone the decision

There is not one way to apply these tactics. You might choose to use one or all of them, depending on the situation. Your job is to decide which of these methods will create the best case for your designs

The first tactic is to show a comparison. You want to take your proposed design and the suggested changes and show them side by side so that the differences between the two are clear. The purpose is to provide a visual reference that leaves no question about which approach is the best. Too often, we talk about design in meetings using words that cannot adequately demonstrate the effect it will have on the user experience.

No matter how you do it, show both options in the same view so that you can discuss them without having to switch tabs or windows.

When clients or stakeholders make suggestions about how to change your design, it’s unlikely that you’ll get away without at least trying it out and showing it to them. You have to first address their concerns and then show them a better way. If you only show them their idea by itself, they’re likely to believe it’s the right choice because there is no reference to your original proposal.

Even if their suggestions are really great, be sure to think critically about the implications and add value to the process to make it even better. That doesn’t mean we should discount the stakeholders’ input as irrelevant or value our ideas over theirs. Our job is to take these suggestions into serious consideration and then apply our own expertise to take it one step further. As the experts on design, this is where we add value the most.

It’s been my experience that when people use generic terms to describe a solution, it’s a sign that they really don’t know what the best solution is and that our alternatives are welcome. A common expression of this is with the use of the word “button,” and yet a button is rarely the right solution to a complex design problem.

Stakeholder: Just put a big button in the header. Designer: Yes, I see what you mean. I’d recommend using a text link instead and adding an icon to emphasize it, rather than a full-size button, which will compete with the other options in the menu. This is also consistent with the other utility links we use elsewhere.

A third tactic is to give stakeholders a choice between something you know they want and the new thing they’re suggesting. You want to present their suggestion alongside what they’ll lose if we go down that path. They have to make a sacrifice. This is very effective if the thing they will lose is more important than what they propose.

In consumer behavior, the fear of loss is more powerful than the promise of gain.

I have often likened this to solving a Rubik’s Cube because someone is going to come to our meetings and say, “I want that side to be red. If you turn that here, my side will be red.” Our job is to be so aware of these connections that we can respond, “Yes, I love red! I want that side to be red too, but when I turn that side, it affects the other sides too and I have to solve the whole cube.”

“If we add that new call to action, it’s going to move the login form further down the page.” You know that they’ve explicitly asked that the login form be higher up, and moving it could adversely affect conversions.

“Adding that will require some time, so if we do that, we won’t be able to launch with the dashboard graphs.” You know that the dashboard graphs are a priority for this phase and that by comparison the stakeholder’s suggestion isn’t as important.

“If we put that new option in the menu, there will not be enough space for the existing items. We’ll need to remove either Preferences or History.” You know that those options are part of the core feature set, whereas the new options add less value or even distract from the experience.

“Changing this text link to a button will compete with the other buttons on the page. If we do that, we’ll need to remove or change the other buttons to accommodate it.” You know that the other buttons are purposely designed to attract the most attention, and adding another will create too much visual weight.

Call on people by name and ask them directly what they think. If you ask the entire group for feedback, few people will speak out in disagreement with the other person. You want to ask an individual person for an opinion. For example, “David, what are your thoughts on this?” or “David had an interesting take on this issue earlier. David, do you mind sharing?”

Ask for people’s thoughts or reactions in a general way. For instance, say “David, I’d be interested in hearing your perspective on this,” rather than pitting him against another person, “David, do you agree with Susan?”

Asking other people to weigh in is a great way to make sure you get support for the best user experience.

You can postpone the decision by leading with a yes by saying something like, “Yes, I see your point, and we really need to find the right solution. How about I take the next few hours to work on it and then we can touch base again before the end of the day?”

To be an effective communicator, you need to learn to respond to people very quickly, in the moment of a meeting. The only way to get good at it is to practice, memorize your strategy (the answers to the Big Three), and apply these tactics on the fly.

The goal for this chapter is to give you a list of common ways of describing design decisions that you can use and reuse at each meeting. I’ve organized them into four categories (in no particular order): Business, Design, Research, and Limitations.

One of the best ways to make a case for your designs is to directly connect it to the needs of the business. Here are three of the most common responses for appealing to the business: • “Helps achieve a goal” • “Facilitates a use case” • “Communicates branding”

A pattern for expressing this is: “[ design] will affect [goal] because [reason].” Here are some examples: • “Moving ‘Related Items’ above the product description will increase product engagement because users will have more opportunities to see more products.” • “Putting ‘Recent Projects’ at the top of the home screen will improve data quality because users will have easier access to keeping their data current.” • “Removing the login requirement will reduce abandonment because users can bypass registration and still see promotions even if they aren’t logged in.”

For example, although any user is encouraged to maintain their account profile information, it is not the main purpose of the application. This informs our decision to put account management functions in a drop-down menu rather than a large call to action. Noting these justifications can help you keep people focused on ensuring that the primary use case is always optimized even in the face of other needs and features.

Even though designing for a use case may seem obvious, it’s surprising how often teams can make decisions in a group setting that completely ignore the main use of the application.

Often, we have design reasons for why we did what we did. I find there are three common ways of describing my decision for design reasons: • “Uses a common pattern” • “Draws the user’s attention” • “Creates a flow for the user”

Your stakeholders may not be aware of the concept of “patterns” in UI design, so you want to be careful not to make them feel like an outsider. Help your stakeholders understand that because this consistency in the experience is so important, changing an expected pattern in one context will have the ripple effect of needing to use the same pattern in other places throughout the app.

Using a pattern is helpful to our users, and it’s also usually cheaper and easier to develop for the business.

There’s a lot of psychology that goes into the thinking about where users look, how they scan (not read), and what makes them move from one place to another. Much of that knowledge is distilled into design practice through techniques such as the use of color, negative space, balance, or type size. These ideas can be incredibly subjective and difficult to justify to the average person, but often it is simple enough to explain that the combination of elements they see on the screen is meant to move the user from point A to point B.

Here are some examples: • “The headline and call to action are arranged so that the user reads the headline first and taps on the call to action next.” • “The containers overlap to give the user a sense that they are connected as they scroll through the page.” • “The elements are arranged left to right and top to bottom, because our audience tends to scan the page in that way.” • “We used green because green means go or success, and the contrast will draw the user’s eyes to that element.”

You need to pay careful attention to how your decisions will affect the flow you’ve created. Don’t let your stakeholders break that without their first understanding why you did it that way. • “Our checkout flow was designed so that each successive control for the next step is in exactly the same place and the user moves forward in a linear fashion. If we make the change you’re proposing, it will break that flow on step 3 and cause the user to have to stop and go back, rather than quickly completing the step by moving forward.” • “Our signup flow requires only the email address to be submitted first, because we can reduce abandonment by not exposing all the fields at once and allowing the user to progressively add information to their profile later. If we add the additional fields to this step, it will complicate the process with validation rules and break the user flow if a mistake has to be corrected first.”

I’ve found three common responses useful when research is used to inform our choices: • “Validated by data” • “Revealed in testing” • “Supported by other research”

What I mean is that data often tells us what the user did, but not why. We try to infer the why by looking at the what, and this naturally involves making assumptions. If we make changes based on a wrong assumption, we end up with a design that is likely to cause more problems than it solves.

I quickly picked up on this and discovered that every time I gathered data to support my proposal, she would agree. It was a strange power because it became tempting to augment the numbers to support my case even if there weren’t truly direct connections. This is the problem with data: nearly everyone is convinced by it, yet it can be easily manipulated. The thing to remember here is that our goal is not simply to get agreement and have our way with the designs. Our goal is to create the best user experience and help our stakeholders to achieve their goals.

To get the attention of your stakeholders, it’s important to begin your response with a phrase that emphasizes your use of data, such as: • “According to our analytics...” • “We have data that suggests...” • “We are tracking this metric and...”

It’s usually enough to simply state with confidence what the data shows without the need for further discussion: • “According to our analytics, 64 percent of users drop off at this point in the user flow.” • “We have data that suggests the phone number requirement is our biggest barrier to conversion.” • “We are tracking this metric and have seen a steep drop in engagement since making this change.”

However, you should always be prepared to provide the data that you cite even if you don’t have it on hand. I usually have the data in a separate file or report that I saw earlier, and I know I can share it with stakeholders when asked. It’s usually enough to tell them you can send the report afterward, as long as you follow up. But it’s a best practice to visually show the data in a simple way, right there and then,

Demonstrating good design through a connection with a usability study is a very effective way of making a case for your designs because it shows that your ideas are working with real people. It has a human element to it that creates a story for our stakeholders, rather than the mechanical feeling that raw data provides. Depending on your stakeholders, using real stories of users might be even more effective than numbers and charts.

The best way to communicate our insights from user testing sessions is to assemble a set of slides with quotes from a few select users and maybe even a video clip showing the problem areas. Edit the video from the session down to a few seconds or create a highlight reel of the most relevant parts from the study. This demonstrates that you value everyone’s time by only showing them the important parts while also giving them the opportunity to participate in a real user session.

It’s common for me to cite other (often external) research that I’ve seen when discussing design. I spend a lot of time consuming blogs, books, and podcasts. Additionally, I sometimes have access to third-party data sources or even internal data analysts.

I discover new best practices all the time and begin incorporating them into my work without even realizing it. I often don’t even know this has happened until I am talking to stakeholders and parsing through my decision process on the spot. I find myself saying things like, “I read recently that...” and then have to backtrack to find those original sources.

As a result, I’ve developed the habit of saving useful research in a project folder or keeping a list in a shared document so that I can easily provide it to other people. As I casually browse other research, I copy links, quotes, and data over to a separate file that I can sort through later, if needed. Usually, my notes include the title, author, URL, and a description of the part that’s relevant to my project or a short summary of the findings. This makes it much easier for me to make claims about other research because I can quickly send the reference to my client if asked.

Most of the time stakeholders take these kinds of statements at face value and trust you with the rest. Much like using analytics, this can be a dangerous power because if you’re prone to overstate or misremember the data, you will still make bad decisions. For that reason, I don’t recommend quoting another study without having the reference available. Sometimes, what you remember about a study and what the actual learning was is heavily influenced by your own perspective.

When the stakes are higher, it might be the only way to convince people that your design is the best choice. What can be unfair, however, is if your stakeholders aren’t prepared to defend their own opinions against your prepared list of research. If you’re not careful, it could feel like an attack. In that case, give them the opportunity to think about it and respond another time, send them your research in advance so they have a chance to review it, or bring research with you that presents both sides of the problem for discussion. You don’t want them to feel like they were ambushed.

My recommendation was based on research indicating that the icon is not as effective as the word “Menu,” but simply telling the client this was not convincing enough. For one meeting, I collected as many articles as I could on the subject (a few of which disagreed with my perspective) and opened them in separate browser tabs to make my case. When we reached that agenda item, I presented my proposed design (again) and then carefully clicked through the tabs to give a quick summary of each post. When I was done, the client was impressed with my preparedness, they admitted that they did not have a similar amount of evidence to support their opinion, and we restarted the discussion about changing the icon.

When using other external research to support your decisions, remember to: • Make a habit of saving research to a separate document as you find it • Note the title, author, URL/ source, and date • Write a short summary of the post or a sentence about how it relates to your project • Provide the list of references to your stakeholders when they ask • Find research to support other viewpoints for a balanced understanding • Give your stakeholders the chance to consider it or respond with their own

I’ve found three common responses for dealing with limitations: • “Not enough resources” • “Limited by technology” • “Complies with a standard”

Every stakeholder wants to build the biggest, best app as soon as possible, which is why so many teams begin with a minimum viable product and iterate over time. In theory, we should never be forced to tell a stakeholder that there isn’t enough time because our process is such that we always create appropriate levels of work during each cycle. In reality, we are always scaling back ideas to fit the current calendar.

Sometimes, these limitations are straightforward and there’s simply no way to accommodate their request. A common example in mobile app design is the size of the device screen: we simply don’t have the space to do everything.

Another common example is with standard HTML control types. Maybe the stakeholder wants a custom date picker, but the prospect of building and maintaining your own is out of scope. It’s not always the right decision to “roll your own,” so it’s better to explain why using a standard control is better for both the user and the bottom line. Sometimes highly interactive page elements require programming hacks to pull off. In that case, you might need to move away from something too complicated if the goal is to build an application that’s meant to work on different devices or browsers.

Every response to design feedback needs to hit on a number of areas if it’s going to have the kind of weight it needs to be compelling and convincing. For UX discussions, I have a useful formula to help make our case to stakeholders. This is the IDEAL Response:

Describe your solution This is where your specific design can be connected to the problem that you’re trying to solve. Make a clear connection between what you did and how it addresses the issue. Without a clear solution, the design is useless and ineffective.

Empathize with the user Stakeholders can forget about the people at the other end of our products. Our job is to represent them, to feel so burdened for them that we’re driven to action. State how your solution solves the problem for a specific user by calling to mind the people at the center of your design process.

Appeal to the business It’s not enough to just fix stuff. All our decisions must be motivated in part by a need to grow the business or organization. This is where you describe how your decisions are meant to affect goals, metrics, or key performance indicators (KPIs).

Lock in agreement After clearly making your case, directly ask for agreement from your stakeholders. You don’t want to leave this conversation open ended, without resolution. Ask them directly, “Do you agree?” Put them in a position of needing to respond to you, and keep the project moving forward.

You can deliver a great presentation, communicate your position, and walk away feeling confident, but without the support of everyone on your team, your project will not be successful. This is why locking in agreement is so critical, because it allows you to move from having something that’s just an idea to something that is truly IDEAL.

You will never get agreement from everyone on a specific solution, but you can get support from everyone by getting their agreement to move forward with the solution you propose. Whether you agree on the details doesn’t matter as much as agreeing to move forward.

To get agreement, you need to directly ask your stakeholders for their buy-in. The simplest way is to ask, “Do you agree?” Put them in a position of needing to respond to you before you move on. Further, it should be clear that you’re asking them for a specific response (agreement) and that you expect an answer.

It’s easy for a design discussion to casually devolve into a handful of random ideas until eventually the conversation feels like it should move on. However, if you don’t have agreement yet, do not let the team move to the next item on the agenda.

You need to be the one who pauses the chatter long enough to say, “Before we move on, are we all in agreement to move forward with this?”

make it clear what you believe the right choice is by the way you ask so that they’re compelled to answer with agreement. You can do this by highlighting either the negative effect of disagreement or the positive benefits of agreeing. For example, “Do you agree that we should improve conversion by removing these fields?” In this case, you’re emphasizing and reminding them that your solution intends to improve conversion.

Let’s quickly review some of the things you’ll need to do immediately after the meeting: • Stick around to chat with people. • Follow up quickly with your notes. • Apply filters and remove the fluff. • Seek out individuals who can help you. • Make decisions when there is ambiguity.

A quick follow-up demonstrates that the meeting was a priority to you, so much so that you’re not going to do anything else until it’s settled. Second, it values the participants because it shows that you’re doing the legwork, keeping them informed, and making the best use of their time. Next, it shows that you’re listening. You’re not just going to throw away all of their feedback: you wrote it down, are taking it seriously, and are concretely communicating it to the entire team. And lastly, it gets everyone on the same page about what was decided so there is no confusion going forward. You’re creating a record for everyone to see and giving them the opportunity to reply if they have any additional insights.

The follow-up should include a few things: • First, thank the meeting attendees for their time and participation. People have other things going on, and we need to appreciate that they’re taking the time for us. • Second, recap everything that was discussed. This can just be a simple bulleted list with the decision noted. Having a simple list makes it easy to share with other people. • Last, focus on actions, next steps, or expectations. You want to always (as much as possible) communicate what’s going to happen next. This helps people see that the meeting was a good use of their time because it’s moving things forward. It also offloads the burden from you and allows the entire team to participate in the next steps.

Here’s an example of what a follow-up might look like: Thanks, everyone, for your time today! It was a very productive meeting, and I appreciate you all being available. Here is what we decided: • The transition on the homepage moves too fast. Jon is going to change it to 100 ms. • The price for items in Best Sellers seems too small. I will check to make sure it’s consistent with the others and adjust as necessary. • The category tree appears to be using the wrong data. We have an email out to Abdul to address this. • Stan is concerned the CTA for membership is too large and uses the wrong copy. Jennifer is checking with content for the correct copy. I will forward the usability study that informed this. • The release date has been approved, pending QA. Jon is going to email us tomorrow with a status update. The important thing here is to keep your update as short and specific as possible without leaving out any important information.

Yet, it’s important to point out that I did two things to make him feel good about it in the moment: I asked questions and I wrote things down. He had no idea what I was writing down; it didn’t really matter. What mattered was that I respected him enough to listen and take notes. I made him feel valued. Even if he had noticed that I left the idea off the follow-up, he knew that I had at least considered it.

Overall, you must learn to filter out all the cruft that can cloud your decision making. It’s too easy to think that everyone’s opinions and ideas need to be incorporated into our designs, but that’s not true. It’s actually a dangerous path. Use your skills in listening and relational discernment to remove the stuff you don’t need, keep the most important things, and follow up quickly with what’s being done.

The sentiment is that sometimes it’s not clear what we should do, but it’s almost always better to do something rather than nothing. I wouldn’t suggest applying this logic to too many of life’s important decisions, but it’s often the case that meetings end without any clear resolution to some of the most important questions for our designs.

What’s common is for no obvious solution to appear to be the right course of action. No one is really sure what to do, and so no one does anything at all. In these cases, I recommend simply making a decision yourself and communicating it to the rest of the team in your follow-up. It’s better to do something (even if it’s wrong) and give your team the opportunity to speak out for or against your choice rather than deal with stale decisions and a stagnant design process.

There’s a similar idea called the McDonald’s theory, proposed by Jon Bell. If you’ve ever had the experience of standing around with friends trying to decide where to go eat, then you know this feeling. Everyone is trying to be polite, and no one seems to really care which restaurant you go to. As a result, you all continue to stand around and not go anywhere. According to Jon’s theory, you should suggest eating at McDonald’s—make the decision for the group—and suddenly everyone will have an opinion about where to go. Jon Bell says, “Anne Lamott advocates ‘shitty first drafts,’ Nike tells us to ‘Just Do It,’ and I recommend McDonald’s just to get people so grossed out they come up with a better idea.” 1

A developer friend of mine, Mark, does the same thing with styling CSS in his projects. Because he’s not a designer (and not very good at CSS), he wants to be sure the designers will make it better. However, he’s had too many experiences when his CSS was seen as “good enough” and never polished to the degree he knows it should be. Rather than have to explain to everyone what needs to be done, he simply applies appalling colors to every element: bright red, hot pink, or putrid brown to be sure that anyone who sees it will insist that it be restyled appropriately. Often, the best way to get people’s attention is to make an obviously bad decision.

Keep these tips in mind for when the meeting is adjourned: • The time immediately after the meeting is a great opportunity to hear what people really think. • The faster you follow up, the more you communicate urgency, value, and decisiveness. Do it now. • Filter out any clutter or unnecessary recommendations from your notes that you know do not need further action. • Stick around to chat, follow people back to their desks, and get the last-minute buy-in you need to move forward. • If there’s ambiguity, make a decision and communicate it to everyone else. That might be the only way to move things forward.

Painting a duck This problem has also opened opportunities for designers to find creative ways around these situations, like painting a duck. According to Jeff Atwood, a duck is “a feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.” 2 The concept comes from a story out of Interplay Entertainment. One of the designers on an animated chess game was tired of all the changes his stakeholder asked for. It seemed as if no matter what he did, they always had one more change. To avoid having to make more changes, he created the queen character and animations exactly as he wanted them to be, but also gave the queen a pet duck. The duck was obnoxious and overdone, flapping around on the screen. According to Coding Horror, “Eventually, it came time for the producer to review the animation set for the queen.... When the animations were done, he turned to the artist and said, “That looks great. Just one thing: get rid of the duck.’”

Yet, being asked to make changes that we disagree with is the very thing we’re trying to avoid. We’ve gone to great lengths to listen to and understand our stakeholders so that we can appeal to their needs with our response. If they still disagree or insist that we make a change, there are a few reasons why.

If you’re confused about your stakeholder’s insistence on changing something that you’ve recommended against, it’s possible that you’re simply not on the same page. There could have been a miscommunication: your stakeholder didn’t understand what a carousel was, wasn’t listening close enough, or misunderstood the context. Clearing up the miscommunication is usually sufficient. Other times, the stated goal of the project has changed and morphed over time, and we’re now solving different problems than the ones we originally set out to solve. This is quite common, and a stakeholder’s suggestion for changes is often a reflection of these moving objectives. Getting to the root cause and clearly redefining the goals will help guide you back to a healthy place.

Some people—especially executives—simply want to know that the thing that’s important to them is there.

I worked with one person who loved to look at all the social media chatter about the app and insisted that we add it to the home page. In reality, he just needed quick access to it. Helping him to bookmark it with a vanity URL that he could remember addressed his needs.

I know it’s hard to swallow, but it’s possible that your design is actually not the best choice. In fact, you could be totally wrong. We will look at understanding when you’re wrong later in this chapter, but it’s important to realize that our stakeholders and leaders have been placed in authority for a reason, and they are usually ultimately responsible for our successes and failures. They have expert knowledge in different areas and insights into the business that we don’t have. In the same way that our stakeholders extend trust to us for recommending the best solutions, we also must learn to extend that same trust to them when it comes to the final decision. It may not be easy, but it’s our reality. ... Are they just unreasonable? Maybe, but probably not. Yes, some people are unreasonable, and no matter what we say, they will insist that we do it their way. Some people will act in their own best interests, even unintentionally. It’s been guessed that 4% of the population are clinical sociopaths. 7 That means that 4% of all people use dishonesty and manipulation to control the people around them.

What’s more is that sociopathic personalities are four times more likely to occupy corporate executive roles. 8 I’m not saying your CEO could be a mass murderer, because sociopathic tendencies don’t always manifest themselves in violent ways. Think about it. These are people who are task and success driven, maybe at the expense of others. It’s difficult to make important business choices if you have the empathy to carefully consider how your decisions affect everyone else, right? Sure, some people might be on the extreme, manipulative and lying, but a lot of people in executive roles got to where they are because they were able to successfully remove the emotion of relationships from the equation. The side effect is that their decision making doesn’t always seem rational to us. Knowing this means we might need to use some caution when working with them.

think. It’s unlikely that your stakeholder is totally unreasonable. Usually when we think that our stakeholders are being unreasonable, it’s actually that we just don’t see things from their perspective, and it’s possible (even likely) that we would make the same decision if we were in their shoes.

Believe it or not, this may be one of the most common (and unspoken) reasons why people insist on making changes. Our stakeholders simply want to know that their ideas and suggestions are being heard and taken seriously. Many people who appear unreasonable actually just don’t have the confidence that we heard what they said and so they don’t see any other solution than to push their own agenda or play the boss card.

people in authority expect to have authority! 9 They expect that their opinions are just as valid as yours, so when you shrug off their ideas with an explanation for your own choices—it sounds like excuses. It sounds like you’re invalidating their perspective. If you refuse to make changes, even indirectly, then you’re not listening to them. It’s no surprise they appear unreasonable and insist on making changes you disagree with.

I don’t mean to suggest that our stakeholders would be so arrogant that they’d purposefully push their own agenda. I think this can happen unconsciously when they don’t feel valued in the process. If this is happening, we need to communicate to them how much we value their input and feedback. They might have felt like we shrugged off their suggestion without taking it seriously. But more importantly, we did not help them understand why our solution was preferred. You’ll need to go back and ask them to explain their perspective again.

It’s not always the case that one person’s “bad idea” will turn out poorly and ruin everything. Usually, it’s our poor execution of that idea that causes these changes to create chaos. Rather than try to fight it or do the difficult work of making it better, we often just give in, shrug our shoulders, and add the thing that person wants exactly as it was proposed. However, when we do that, we’re missing a huge opportunity to improve the design in a way that we had never thought of before.

All design has constraints and limitations. Our challenge has always been to build websites or apps that are easy to use, yet are required to support a certain feature set, user story, or major constraint such as the limited viewport size of mobile devices. We relish these challenges. This is what gets us out of bed each day: making great stuff with constraints.

And so, when directed to implement a design decision that we don’t support, it’s important that we don’t give up and just paste it on top of the interface—tempting as that may be. Making these changes is an opportunity to find the best possible way to implement that idea. It’s a new constraint that you are tasked with incorporating into the project. Our stakeholders expect that we’ll “figure out the best way to do it” because that’s what we’re being paid to do. In fact, our goal should be to take this constraint and actually use it to improve the experience rather than muddle through and hope we don’t break it. We need to flip this attitude on its side and see the opportunity in the mess.

In my experience, one person’s suggestion is a gold mine of other ideas waiting to be excavated. The changes your stakeholder proposes should spark a conversation that leads to an even better solution. Your job, as a communicator, is to lead that conversation to a place that will yield the best results for your application. You can do that by asking questions, understanding their perspective, and listening: all the skills we’ve covered in these pages. Involve other people. Ask them how they would solve the same problem. Propose an alternative; even a bad alternative should start a conversation about solutions.

Occasionally, having a stakeholder insist on a change can lead you down a path to improving the app in a way that you never expected, solving problems you might not have uncovered otherwise.

Purely from an economic standpoint, your job as a designer is already established as a give-and-take relationship. You receive money in exchange for providing designs. Beyond that, for the relationship to not only function but to thrive, you also need to keep your stakeholders happy. That’s more than just a purely economic transaction. This happens by building trust, demonstrating your expertise, managing their expectations, communicating effectively, and (of course) delivering what they expect. In those areas, there is also give and take. Think of it like a bank account: every positive experience working with you is a deposit and every negative one a withdrawal.

For every time you agree with your stakeholder, you make a deposit. When the metrics improve as you promised: deposit. When you show them an incredibly beautiful design they love: deposit. But when we disagree, we begin to see withdrawals. When you miss a deadline or fail to follow up on feedback? Withdrawal. You refuse to make a change because you believe it’s in the best interest of the user? You might end up being right, but at least temporarily, it’s a withdrawal of trust. At the end of the day, your relationship with stakeholders can be measured by the balance you have in this bank account of trust. Their willingness to trust you when it matters most is dependent on having a positive balance.

As a designer, that means that sometimes you have to relent and allow your stakeholders to make changes even when you’re opposed to them, maybe only because you need to make a deposit. The important thing is that you’re learning which battles are worth fighting.

You’re focused on your goals, the problem, the users, and seeing to it that the areas where you disagree can still allow you to deliver on your promise of building the best possible interface. It’s a balancing act, for sure, but one that you will always be learning to manage. You must constantly be balancing the needs of the user with the needs and requirements of your stakeholders. When those two things collide, you have to make difficult decisions about where to draw the line.

The outcome of the project is dependent, in large part, on your ability to effectively manage these conversations and find the best solutions, given the constraints of working with real humans.

My clients know that I have opinions and can express my perspective. Over time, they learn to trust me and shift from a position of assuming that my choices are questionable to assuming they have purpose. On a phone call recently, one of the stakeholders questioned a design element but then deferred to me: “I know Tom usually has good reasons for his choices. Tom, what’s the reason you did it this way?” When you can get your stakeholders to approach your work with this perspective, you set yourself up for long-term success in building great user experiences you can be proud of.

Hopefully your decisions won’t cause critical damage to your product, but in any case when your designs are shown to not be the right solution, it creates a tension that can be awkward to handle. You have a choice: own up to your decisions, or ignore, deny, and absolve yourself of any responsibility.

Although being wrong might seem like it would tear down trust, it’s actually an opportunity to build more trust by admitting you made a mistake. It seems counterintuitive: we’ve let them down, and now we’re supposed to admit it. How does that build trust?

People appreciate honesty more than smoke and mirrors. They prefer transparency over a cover-up. The way they know they can trust you is when they see that you’ll own up to your mistakes. Honesty is truly the best policy. It may be tricky at first: it will create difficult conversations. But in the end, you’ll almost always come out on top when people realize you’re a trustworthy person—that even when you screw up, you’re there to admit it, fix it, and move on.

You need to clearly state, “I was wrong” or “I made a mistake,” but also be quick to get to the solution and focus on action instead of excuses. Tell your stakeholders what needs to be done to correct the problem and outline a clear plan for doing so. Most stakeholders are results oriented, so quickly admit your mistake but jump directly to the solution. When you make yourself part of the solution, you’re also making yourself indispensable: they need you to help correct this problem.

The reasons why something went wrong are not nearly as important as fixing the problem. Don’t obsess over rehashing history. This usually sounds like excuse making. Instead, gloss over why it happened and get straight to the fix. If people want or need to know the history, they’ll ask and you’ll have the opportunity.

The most difficult part of admitting when you’re wrong is even being aware that you’re wrong in the first place. It can be easy for our own arrogance to get in the way of seeing the problem. As designers, we see our designs as our creation—this perfect thing that we made and are sending out into the world. It’s really difficult to see the flaws with it, even when people point them out to us. We are often in denial about the fact that our work doesn’t work. How, then, do we know when we’re wrong? There are three red flags, and they all conveniently line up with the three things you need to be a successful designer. How to know when you’re wrong:

The problem still exists While we try to solve problems, it’s not a given that our designs will always work as expected. If we find that the problem still exists, we’re wrong and we need to change something.

Users don’t get it Because we want our designs to be easy to use, we need to see that they’re actually making it easier for people. If not, we’re wrong! I’ve worked with designers who were so convinced that their interface was easy to use that no amount of failed user testing would have convinced them otherwise.

You don’t have support We can be really arrogant about how elegant our solutions are, especially if we’re the only designer on the project. We feel justified that “no one else knows good design,” and so even in the face of opposition, we insist we’re right. But when a majority of people disagree with your decisions, it’s a sure sign that you’re doing it wrong.

I don’t know for sure, but I suspect that Jim (like many other designers) believed that his designs would speak for themselves. That interpersonal communication, as a skill for designers, was wholly unnecessary because our designs are, in and of themselves, a communication medium. He was the expert, but his arrogance clouded his ability to value the stakeholders on the project. He was good at solving problems and he was very user-centric in his thinking, but he failed to realize that without the support of everyone else on the team, he was not going to be able to succeed.

As you work with the designers in your life, realize that they have expertise in design and that their job is more than just making your project look pretty. They are equipped to find design solutions to business problems. You hired them and have them on your team for a reason: because they’re experts in design and are better at it than you are. They have expertise in understanding what makes things easy for users. They’re trained in usability techniques and best practices. They know the right patterns and design elements. You need to trust them to do their jobs without telling them how to do it.

Also, because design can be complex and many elements are interrelated, realize that any changes you suggest will affect the rest of the project. There’s a ripple effect that may require us to rework the other parts. It’s not isolated. Many stakeholders make well-intentioned suggestions, expecting the changes to be simple or only take a few minutes. It’s not unusual to hear, “All you have to do is move this over there, right?” But the process of updating one part of the design requires that we step back and evaluate our decisions. Moving one thing requires that we also move another. Sometimes, changing elements can break the flow of the application. Not always, but often.

One resource that we often need but don’t get is permission and budget for doing usability testing. We need to check your project with other people to verify that it will work as expected. This isn’t a focus group; we’re not asking users what they want. This is taking the time to observe people using our website or app, and then taking notes about ways we can improve the experience. It’s task based and mostly observational. We don’t do this enough because we often don’t have permission to spend our time on it. It’s not expensive, and the result will more than pay for itself in uncovering problems earlier or optimizing tasks for a better app. Give us permission and the budget for usability testing, and even encourage us to do more of it.

It might seem like waiting a few days for the next meeting is completely appropriate, but in those few days we could be already working on the next thing or finding the flaws with our current thinking. The best projects I’ve worked on were those where we met with stakeholders daily. That’s right, every day. I would spend the day designing, show my work to the client in the afternoon, get immediate feedback, and then do it all over again. That sort of rhythm is empowering and exciting. Sometimes, I propose daily design reviews with larger clients and they groan. Why? Because they already have too many meetings and can’t seem to wrap their minds around a process that iterates and moves so quickly. Yet, it is these projects that always take longer and yield inferior results.

The better you are at making good, fast decisions, the better off we’ll be. Not just more productive, but also happier and more satisfied with our work. We feel good about what we do when we know things are moving forward. It would be better to do something (even if it’s wrong) and keep the project moving rather than do nothing and flounder in ambiguity. Indecision and changing decisions are the killers of an effective design process, so authorize your designers and your entire team to move as quickly as possible.

My challenge to you would be to purposefully allow your designers the freedom to make design decisions. Start with some low-risk decisions at first but quickly work your way toward the larger overall product vision. Begin by agreeing with them as frequently as possible, until you feel you can let them decide on their own. Find the level at which you start to be uncomfortable giving over control, and then push past it just a little. I believe that the sweet spot of good leadership empowerment in decision making is just past your point of comfort. Leaders should always be just a little uncomfortable giving over decisions to their team.

Ten Tips for Working with Designers To briefly summarize, here are 10 short tips to help you work with designers more effectively: Focus on what works. Remove the word “like” from your vocabulary and always talk about what works or doesn’t work. Your personal preferences are less important than the needs of the user or business. Don’t provide solutions. Tell us about the problem you see and describe the issue that needs to be addressed, but don’t tell us what to change first. Let us find the solution. Ask lots of questions. This is the key to seeing from our perspective and understanding our motivations. Ask questions to uncover our thought process. Don’t claim to be the user. The truth is that every user is different, and you don’t represent the target market any more than the designer. Claiming to be the user of your app or website does not add value to the conversation. Let us explain our decisions. Don’t offer your own perspective and walk away. Allow us the time and space to form an adequate response. Empower us to make decisions. Even if you disagree with our choice, learn to trust us in areas where we have expertise and then hold us accountable for the results. Use helpful language. It can be difficult to receive feedback without becoming a little defensive. Avoid harsh or extreme language and focus your feedback on the designs, not the designer. Ask if there is data. We should all use data to support our decisions, but just because the designer doesn’t have data doesn’t mean he’s wrong. Be prepared. Review our work in advance and have a list of questions or concerns ready. Don’t wait and provide knee-jerk reactions in the moment. Your feedback should be purposeful and thoughtfully considered. Give us what we need to be successful. Whether it’s logins, access to analytics, or permission to do usability testing, we need things from you to work effectively. Make it a priority.

The way that businesses approach design has changed dramatically. Design used to be something that only made the company look professional or projected an image for the product or brand. Today, design is being used to solve real business problems, and more and more companies are seeing that value. Entire organizations are pivoting to make design the center of their process because they recognize it’s good for the bottom line. The most famous and popular products now are those that are well designed and provide a superior user experience.

Companies that struggle to incorporate design thinking into their organization have one problem: they don’t have designers at an executive level. The problem of delivering poorly designed products isn’t one of talent, but of design leadership. These companies lack a vision that’s inclusive of the user experience. They have talented designers, but not design-thinking decision makers. Companies that consistently fail to deliver the products that they believe they should offer need a new seat at the table: a designer.

Think about the most popular products, websites, or apps with which you’re familiar. Who started the company? Who is its CEO? In most cases, the people leading the organizations that create great products are people with a design-centric mindset, even if they aren’t technically qualified as a designer. They are designers in their own right, but they surround themselves with other talented designer-types, too.

If you’re serious about wanting your company, product, or service to be known for great UX, put a designer at an executive level. It’s no longer adequate to hire a contracted freelancer through a sales manager to create your website. You can’t just invite the designers to a meeting, inspire them with your vision, and then wait for them to bring back the best product ever. You are going to fail if the only designer you have sits at a desk with the marketing people down the hall. Designers need to be involved at the highest levels of the organization if you expect to succeed in a marketplace driven by design. They need to be empowered to make difficult decisions, they need the autonomy to create the best product, and they need the trust and support of the other executives.

One of the best (and simplest) models I’ve seen was a former employer who moved the creative director to a desk with the other executives in an open-office environment. Just sitting next to one another greatly improved their thinking, made a political statement about their values, and firmly established the organization’s vision. The designers weren’t off in another room; they were integrated into the senior leadership team.