Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience

by Tom Greever

I realized that all my favorite designers were people who could intelligently explain why they did what they did.

The most important thing you could ask me...the very first thing you should always ask is, ‘What are we trying to communicate?’”

The difference is that the interface they used previously for solving these problems never mattered much. As long as you could teach someone how to use it, it was good enough. We didn’t need effective design, we needed documentation and training. The answer to a design problem was to educate the user. If we can help users understand the system, then they will know how to use it.

The problem is that because design is subjective and because we don’t always understand how our intuition connects to the problem at hand, we’re unable to adequately tell other people why we did what we did, and that’s one of our biggest failures.

when someone is good at what they do, they have a hard time telling people why they did what they did. They don’t think; they just do.

There are now a lot of people who may know little or nothing about design, yet who have the authority to oversee and dictate our design practice. They have a vested interest in participating in the conversation, but they aren’t trained designers and they don’t have the same depth of knowledge in design or technology that we do. What used to be a somewhat obscure conversation between graphic artists is now open and available to many other players in the business. What’s more, these people will often gladly admit that they aren’t the experts. They know that they don’t know, yet they still insist their ideas and opinions are right. This is one of the most bizarre parts of our relationship with stakeholders. People who have influence over our project readily admit they are not good at our jobs, yet insist on making changes that we believe will be detrimental to the user experience. They say that they trust us and yet frequently overrule us. It can be incredibly demeaning and confusing, but the problem may not lie entirely with them.

No passion in the world is equal to the passion to alter someone else’s draft.

In situations like this, meetings can easily turn into design-by-committee. Everyone has a suggestion for how to solve a problem. We hear different opinions on every side and are unable to defend our own choices against this barrage of feedback. One suggestion evolves into an idea for something else. That idea spurs a thought about something different. Unchecked, the conversation can spiral out of control into a hodgepodge of well-intentioned tweaks that collectively spell doom for the overall goals of the project. The thing we came together to accomplish has been muddied by group think and mob mentality. Remember, teamwork always ends with work.

It’s more than just communication; we have to turn those words into something that will enact change or compel people to agree with us. It’s not just about using words with a frequency or persistence; it’s about using them in a way that is compelling and convincing. It’s about being articulate. Being articulate can make you successful in any area of life. It can help you get almost anything you want: a job, a spouse, or a bargain. It is the ability to use your words, tone, and approach with people to communicate a specific message and elicit a specific response. The key to being articulate is to understand both the message you want to communicate and the response you want in return. If you can learn to craft your messages in such a way that they yield the desired response, you’ll find that you’re much more successful at getting the things that matter to you. You can apply the same ideas in your design practice.

way. Your design might be revolutionary, but an aggressive and well-spoken salesperson is more likely to get his way if he can convince your boss that he’s right and you’re not.

Imparts intelligence You’re smart, you know what you’re talking about, you have expertise in this area, and you can be trusted with the solution. Demonstrates intentionality You’ve thought about it, pursued it, and are logical in your approach. This isn’t just a random idea; there is purpose and focus. Expresses confidence You know what you want and how to get it done. Having a solid argument shows that you’re not wishy-washy and you mean what you say. Shows respect You value everyone’s opinions and time enough that you’re well prepared. You’re not wasting time or disregarding others.

Those two things together (solving a problem and making it easy for users) will help us create truly great experiences. This is what makes a good design good.

The difference between a good designer and a great designer is the ability to not only solve the problem, but also to articulate how the design solves it in a way that is compelling and fosters agreement.

So, I would say there are three things that every design needs to be successful: It solves a problem It’s easy for users

It’s supported by everyone

How will we know if we’ve done our job? By looking at the results before and after, tracking some specific metric, and watching it improve.

Find out what the most important factors are for your stakeholders—impressions, conversion, account sign-ups—and then pick one or two measurable issues that you’d like to improve and write them down.

“What problem am I trying to solve with this?” Chapter 8 will list some of the most common ways I describe my own solutions, but for now just consider that you need to practice making yourself aware of all the changes you’re making, all the new things you’re adding, and all the rearranging that goes into finding the right interface. Those unconscious choices hold the key to explaining your designs to other people and ensuring that your expert perspective remains at the center of the final decision process.

The best way I know to practice being conscious of your decisions is to write them down.

Research can take many forms, but the most common tools are either analytics or a usability study. We will talk more about this in Chapter 7, but let me say here that the challenge with analytics is that it can only tell us what the users did. It cannot tell us why they did it. The only way to actually know how your decisions affect users is to observe them.

Ironically, we are usually cognitively aware of some of the other alternatives. We probably tried them, moved stuff around, and eventually landed on the solution we believe is best. But it’s all those little movements that we failed to make ourselves consciously aware of, and so we’re less prepared to help other people understand our thought process.

The point is this: be consciously aware of why your design decisions are better than the alternatives.

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?

Your ability to be thoughtful about a problem and articulate any solution is more important than your ability to design the perfect solution every time.

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 way that makes sense to them.

So, it’s important to get to know how people think in our work-context, as well. Ask things like: • What did you think of the meeting last week?

How’s your work going on the other project? • Do you have a lot going on this week?

I suggest being as direct as possible when trying to uncover people’s viewpoints and perspectives in situations where they can be difficult to read. For example: • What’s your opinion on this project? • How does this project affect your job? • What is your priority for this project?

the point of asking questions is to get the other person to talk to you about what’s important to them. You just want to understand more about their perspective so that you have a better sense for how to respond to them, when needed. That’s how you create an awareness of the other person’s viewpoint and set yourself up for a better relationship, better communication, and better success in creating the best user experience.

Walking into your meeting might even be disorienting if they can’t remember where you last left off. Your job is to bring them up to speed as quickly as possible, present your solutions, and solicit their feedback. They want to know that you’ve thought about it and have made smart decisions that align with their vision for the organization.

We’re not robots churning out stuff just to get a paycheck; we’re smart people with great ideas working together to create great products.

In addition, you can never be fully prepared for these meetings without first rehearsing them, either in your head or out loud. The time you spend preparing for the meeting makes you that much more likely to be successful at making a case for your design decisions, because you can focus more on being articulate and less on the agenda.

The point here is that as you get to know people, you should be able to identify what is distracting to them and remove those things from the conversation.

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.

Likewise, prepare data (analytics, usability reports) to support any part of your proposal. It’s one thing to make a suggestion, but it’s another thing altogether to show the data that supports your ideas. Most of the time, it’s enough to simply let everyone know that your decisions are based on data, but you must also be prepared to show that data, if it’s in question. Actually, I don’t recommend pulling out the data unless it’s necessary to make your case.

One of the best things you can do to ensure that your stakeholders agree with your recommendations is to get other people to support you in your decisions. That is, you want to be sure there are other people in the room who will back you up, help you make your case, and tip the scales when it comes to the final decision.

The purpose of getting people to back you up is to build a case to 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.

The more you practice going through the content, the less your brain will have to think about the agenda and the more mental capacity you’ll have to be focused on being articulate and responding. You commit it to memory. We want to reduce our own cognitive load to the point that holding the meeting is a breeze. But also, design decisions can be particularly difficult to understand and there may be underlying reasons for your choices that you haven’t even uncovered yet.

You have to decide how much practice is necessary to ensure you have the mental capacity to be articulate in the moment.

Remember that the main purpose of taking so much care to prepare for discussing design decisions is to reduce the cognitive load both for your stakeholders and for you. Just as we would approach the usability of a design, our meetings have the same opportunity for refining what people see, optimizing the flow of the conversation, and testing our assumptions before it all begins. When

One last implicit listening skill 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 frequently delays and it might be difficult to tell if you’ve dropped off. (My own clients commonly ask if I’m still on the line, unsure if I was disconnected.) But whether you’re on a call or face-to-face, 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 there’s a better way for them to give you their feedback, you will want to hear it, because people don’t always express it correctly the first time.

If you don’t have notes, you don’t have a paper trail to understand what logic went into the original decisions.

For the same reasons discussed in Chapter 4, writing things down reduces your cognitive load and frees your mind to focus on being articulate in your response. When it’s written, you no longer need to think about it.

Another benefit to taking notes is that just the act of writing things down will make you look attentive, smart, and, as a result, more articulate. Taking notes makes you look like a good communicator. It makes the other person feel valued because you care enough about what they said to write it down. This gives them confidence that you heard what they said and you’re planning to follow through.

Because you’re taking notes, you can suggest delaying the discussion of the login form if that’s not the purpose of the meeting. “Yeah, I noticed the login form this morning, too. Let me make a note of that and I will follow up right after this meeting, but for now let’s stay focused on the category menu.”

If you don’t have the authority to tell someone else to take notes for you, find a note buddy who is willing to help.

What problem are you trying to solve?

What are the advantages of doing it this way?

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 is to find the solution, giving stakeholders an opportunity to propose something