Solve the problem

<aside> 💡

It could be useful to describe your designs using only words.

• Example </aside>

Design the meeting

<aside> 💡

Set the context

• State the goal
• Summarize the last meeting
• Show a timeline
• Specify the feedback you need
• State the goal, again </aside>

Listen to understand

<aside> 💡

Implicit Listening Implicit listening is applying skill in understanding what people are saying without outwardly doing anything specific to demonstrate that we hear them. An implicit listener is one who can quickly organize what’s being said and derive meaning without any other external clues or further information.

• Let them talk: they will make themselves clearer, it gives them confidence that they were understood, it demonstrate that you value what they’re saying.
• Hear what’s not being said: example, when someone uses the word “interesting”, it might be a clue they disagree.
• Uncover the real problem: focus on the underlying problem they’re trying to solve by suggesting a solution.
• The art of the pause: don’t immediately jump in with your response. Instead, pause for several seconds, to make sure they’re done, to let the air settle, and to communicate consideration to the other person. </aside>

<aside> 💡

Explicit listening

• Write it all down
• Include the “why”
• Ask questions
• Rephrase & repeat:
  • Convert “likes” to “works” to help our clients move from preferences to design effectiveness.
  • “What I hear you saying…” to translate what they’re saying into a vocabulary that will become our common ground. </aside>

Form a response

<aside> 💡

Tactics

• Show a comparison: take the proposed design and the suggested changes and show them side by side so that the differences between the two are clear.
• Propose an alternative: offer an alternative solution that meets the need in a different way.
• Give them a choice: give stakeholders a choice between something they need 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.
• Ask others to weigh in: “what are your thoughts on this?”
• Postpone the decision: that could take a few hours or days, to take a step back, wrap your mind around the problem, and come back with a better solution. </aside>

Choose a message

<aside> 💡

Business angle

• “Helps achieve a goal”: stakeholders always appreciate connecting your solution to the goals of the business.
• “Facilitates a use case”: pointing out which use cases benefit from the decision is a good way of demonstrating your thought process and will get you talking through the decision in a way that makes sense to them.
• “Communicates Branding” </aside>

<aside> 💡

Design angle

• “Uses a common pattern”: design patterns are meant to provide consistency and set a user’s expectation about what interactions will take place.
• “Draws the user’s attention”: to explain that the combination of elements stakeholders see is meant to move the user from point A to point B. It’s important we help our stakeholders understand the relationship between design elements and user action so that they can see the rationale behind our decisions.
• “Preserves the user flow”: 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. </aside>

<aside> 💡

Research angle

• “Validated by data”: the most scientific way of demonstrating that your designs are having the intended effect. There is existing data (data we already have) and reflective data (data we collected after changing our design and comparing the before/after).
• “Revealed in testing”: 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.
• “Supported by other research”: cite other (external) research from books, blogs or podcasts. </aside>

<aside> 💡

Limitations angle

• “Not enough resources”: lack of support (infrastructure, internal processes), people, money or time.
• “Technical limitations”: size of the screen, server limitations, technical aspects that aren’t cheap or easily available.
• “Complies with a standard”: we want our app to work in all browsers, on different devices, and for all people (accessibility). </aside>

Lock in agreement

<aside> 💡

The IDEAL response

• Identify the problem
• Describe your solution: make a clear connection between what you did and how it adresses the issue.
• Empathize with the user: 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: all our decisions must be motivated in part by a need to grow the business (metrics, KPIs etc.). Bring it up, tie them together, demonstrate the value.
• Lock in agreement: directly ask for agreement from your stakeholders. </aside>

Follow-up afterward

• The meeting after the meeting: the time immediately after the meeting is a great opportunity to hear what people really think.
• Follow up fast: the faster you follow up, the more you communicate urgency, value and decisiveness.