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

Changes Are the Purpose, Right?

(...) there is something about design that seems to elicit subjective opinions from everyone. Everyone is a designer!

(...) As a result, they show up with an expectation that telling us something to change is the entire purpose of the meeting! If they have no changes, there'd be no point in meeting. Right?

This phenomenon has given rise to a few very interesting ideas:

Parkinson's Law of Triviality

(...) which states that people in a meeting will spend a disproportionate amount of time on issues that are not central to the project. (...)

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.

Hairy arms

(...) In the 1940s, Disney animators came up with a similar solution. Their art directors liked to suggest changes, and it was a painstaking process to draw and redraw each character. So to avoid having to make changes they disagreed with, they began adding hair to the arms of the characters that they did not want to be approved while leaving their own recommended designs clean.

Follow Up Afterward

WHEN THE MEETING IS OVER, you still have plenty of work to do. The time immediately after a meeting is nearly as important as the meeting itself, so don't rush off and leave everyone behind. Wait and talk to people afterward to debrief and gain insights that weren't apparent at the time. (...)

(...) It is amazing how many decisions are made immediately after a meeting is dismissed. This is a great opportunity to wrap up any unfinished business and work with the influencers to get the support you need (...)

Follow Up Fast

As soon as possible (preferably within an hour or at least within a day) send a follow-up to the entire team. It doesn't need to be written perfectly; the purpose is more functional than poetic. (...)

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.

(...)

Apply Filters

Another post-meeting strategy is to use your best judgment to filter out all the unnecessary information that isn't worth repeating to the entire team. This can be difficult to assess, but it's necessary if we expect to communicate without too much clutter. (...)

Seek Out Individuals

Just like the meeting after the meeting, there might be some people you'll want to talk with afterward. (...)

Do Something, Even If It's Wrong

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. (...)

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. (...)

Putting It All Together

Now we begin to apply everything we've covered so far into one coherent response, which:

Provides a natural transition using Thank, Repeat, Prepare

Considers our answers to the Big Three questions

Applies any number of the tactics necessary to make our case

Takes advantage of common responses to design considerations

Encapsulates all of them in the IDEAL Response so that we can get agreement and support to move forward

(...)

Download a blank worksheet to write your own IDEAL response from my website: http://tomgreever.com/resources

Lock In Agreement

(...) 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 (...)

(...) 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. (...)

(...) 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. (...)

(...) Sometimes, stakeholders are not forthright in their reaction, and we need them to tell us exactly what they think in order to accomplish our goal. If they disagree, we need to know and there should be no question about it. (...)

Choose a Message

(...) Although every project is different and every client has unique needs, I've found that there are some ways of explaining design decisions that I seem to use over and over again. (...)

(...) I've organized them into four categories (in no particular order): Business, Design, Research, and Limitations.

Business

Here are three of the most common responses for appealing to the business:

"Helps achieve a goal"

• "Facilitates a use case"

"Communicates branding"

(...)

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"

Research

(...) perhaps the most compelling justification for our design decisions. 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"

(...) Product owners and project managers are usually the ones who will help you with this effort, but it's entirely likely that you will need to do the work of combing through the chaos (...)

Limitations

(...) The unfortunate reality of design is that companies frequently do not have everything they need to realize their dreams

When talking about design, I suggest five tactics to shape our response:

1. Show a comparison

2. Propose an alternative

3. Give them a choice

4. Ask others to weigh in

5. Postpone the decision

(...)

1. SHOW A COMPARISON

(...) 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. The idea here is to find a way to make quick design changes and put both options next to each other. (...)

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. (...)

2. PROPOSE AN ALTERNATIVE

(...) Whatever the case, proposing an alternative is a necessity in almost every situation (...)

(...) Even if they overrule you, you're demonstrating that you're intentional about your thought process and creating an awareness that these decisions aren't to be taken without consideration. A track record of being able to gracefully propose alternatives will win you the respect of your stakeholders (...)

3. GIVE THEM A CHOICE

A third tactic is to give stakeholders a choice between something you know they want and the new thing they're suggesting. (...)

(...) it's an honest attempt to make stakeholders aware of the implications of their proposed choice. We need them to know that every decision affects everything else. (...)

(...) In each case, we are emphasizing the tradeoff. Not only does this allow stakeholders to see their feedback in light of all the other priorities on the project, but it also involves them in the decision process and empowers them with the right information. (...)

4. ASK OTHERS TO WEIGH IN

The fourth tactic is to solicit help from other people and ask them to weigh in on the decision. (...)

(...) When you ask others to weigh in on the conversation, it's important to remember to always ask directly and remain neutral: (...)

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. (...)

(...) Don't ask for feedback in a way that reveals your true feelings about the stakeholder's suggestion. Instead, ask open-ended (not yes/no) questions (...)

5. POSTPONE THE DECISION

(...) 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?" (...)

Form a Response

(...) At a high level, crafting a good response requires that we:

• Define our strategy for responding. What will we say to make a compelling case?

• Employ tactics that will help us get there. How will we deliver the strategy?

• Identify common, relevant responses.

• What key messages are important in our context?

• Apply a common framework and ask for agreement. What do we want our stakeholders to do next?

(...)

Dale Carnegie calls "Appealing to a nobler motive" in his 1936 classic How to Win Friends and Influence People

I find that this is especially effective in design discussions and is often the missing ingredient from a designer's portfolio of communication techniques. You want to find the thing that you know your stakeholders care the most about and connect it to the proposed user experience.

(...) If you don't have any goals or metrics, write them yourself and present them to the stakeholder. You both need them if you're going to succeed.

(...) You can't represent someone you've never met or observed. So, do whatever is necessary to make yourself get up and go watch people use your project. (...) You can then apply this understanding in your meetings with stakeholders to represent the user (...)

Make a Transition

(...) This is the response before the response (...)

(...) I recommend a simple approach called "Thank, Repeat, Prepare." (...)

THANK

(...)

REPEAT

Next, briefly summarize what the stakeholders just said if you haven't already. (...)

PREPARE

Lastly, tell your stakeholders that you're about to respond to their feedback. (...) create the right kind of vibe and prepare them to listen. (...)

Here are some examples:

"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 l'd like you to understand how we came to these conclusions first..."

(...) 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.

All this prep work will pay off. It might seem like there's a lot to consider, remember, and do to just have a simple conversation with a stakeholder about design, but the process moves very quickly in real life.

Change Your Vocabulary

(...) 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. (...)

(...) Don't start any sentence with "From a design perspective.." because that's usually just another way of saying "from my perspective." (...)

(...) Sometimes we use this phrase to mean "the reason we did it this way..." If that's the case, say that. You do not want to create a separation between your expertise and that of the stakeholders. We're all on the same team. (...)

(...) Don't talk about what you like or don't like; instead, focus on what works and what doesn't work. (...)

(...) Finally, avoid using industry-specific jargon as much as possible. Instead, find words that the average person can understand so that we're all on the same page. (...)

Establish a Positive Persona

(...) we need to work on establishing a positive persona so that our stakeholders are interested and attentive when meeting with us.

HAVE CONFIDENCE, NOT ARROGANCE

(...) 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. Smiling will show your confidence and build theirs in the process.

JUST BE YOURSELF

(...) Being yourself helps everyone else relax, too.

They can relate to you more easily when they see you for who you really are. (...)

DON'T TAKE YOURSELF SO SERIOUSLY

(...) When we get in this "getting things done" mode, it can be really easy to have tunnel vision and become too focused on the tasks. That can be fine (and really effective) when we're heads down creating awesome stuff, but it's much less effective with a group of people whose support we need. Learn to relax: not everyone thinks as seriously about your work as you do. (...)

We can ensure that our stakeholders are working with us to create the best user experience when we smile with confidence, are authentic, don't take ourselves too seriously, and orient ourselves toward their needs and expectations.

The main difference between a scrappy startup and a bureaucratic behemoth is how quickly they make decisions and move forward. It has little to do with talent, resources, or ideas, and every- thing to do with the team's momentum. Projects fail or languish when the leaders don't make decisions or don't stick with the decisions they take.

Think of it like a bank account: every positive experience working with you is a deposit and every negative one a withdrawal. Your goal is to maintain a positive balance with [stakeholders] at all times.

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".

“Well, do something! Even if it's wrong!" This was actually a common phrase of my dad's. 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.

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.

I canceled the meeting right there and sent everyone back to their desks, only 15 minutes into an hour-long meeting. Meanwhile, I stayed behind in the conference room and cranked out several alternatives that would be more useful in leading the discussion, without five people looking over my shoulder and touching my screen. Before the hour was up, I called everyone back together to review the options I had just created.

… It's important to remember that our role in the design process is not just about building things that take the user into consideration; it is actually to advocate on their behalf to our stakeholders. We are the representatives of our users at this meeting.

To be certain, having confidence is not about being arrogant, cocky, or asserting that you're always right. It is allowing the knowledge that your skills are valuable to overflow into your tone, body language, and attitude when you talk about your work.

Innovation happens in places where "No" is seldom heard…

When he was first starting out as a leader, people would come to him with great ideas that he knew weren't possible. Rather than turn them away, he chose to say yes. He found that people were more motivated, empowered, and passionate when their ideas were givern permission to succeed. Even if they didn't fully accomplish their goal, it was far better to empower people to do great things than to shut them down.

Be on the lookout for these kinds of subtle reactions in your own mind and find a better way to position yourself so that you can form the best response. If the only logic for disagreeing with someone else's suggestion is "They don't understand my job," you're not going to be able to build your case on this kind of generic (and egotistical) assumption.

You need to put on an attitude that will help you be articulate. It requires you to understand your role, check your ego at the door, and always lead with a "yes." In addition, you need to develop a positive persona that opens people up to trusting you with the solution.

This means that you, too, must work hard to strike the word "like" from your vocabulary and always place an emphasis on the utility and function of the design.

An articulate response requires that we use implicit skills such as listening without interrupting, hearing what they're not saying, uncovering the actual problem they're trying to solve, and then pausing before moving on.

We also must use more explicit techniques like taking notes, asking questions, and repeating or rephrasing what was said.