In Articulating Design Decisions, Tom Greever discusses the fact that despite the ability to speak to the form and function of how designs can solve problems (things that designers understand), many designers have yet to master the art of explaining these things to non-designers.
Design communication isn’t a skill that comes easy or quickly. But by taking into consideration stakeholders’ concerns beforehand, designers will be in a better position to defend their work. In this article I’ll go over a few of the challenges designers have when communicating with stakeholders, and what can be done.
UX designers have different ways of preparing for meetings—and many of those ways center around designs, wireframes, and workflows. That makes sense. It’s part of the craft, and craft is important.
“Think about the way you’ll communicate, not what you’ll present.”
But during all that preparation, many designers aren’t thinking about the way they’ll communicate their design to stakeholders, or how they might respond to comments or questions. It’s mostly focused on what they’ll present.
UX designers often present their work through a user experience lens without consideration to the very different lenses of others. Thinking about these different lenses and how they’ll affect the conversations you have with your teammates and stakeholders will help your design presentations go much more smoothly.
In the hot seat
Each stakeholder has a unique lens in which they’re viewing your work. This affects the way that they understand, process, and respond to your work.
Several things could affect this point of view, and it’s good to be aware of them so you can tailor presentations and responses to these factors. It can also help more user-centered design get into the product. Consider:
- Roles. What is each person’s role in the project? What authority, expertise, or objective does their job entail?
- Mood. Are they having a bad day? A good day? Is it 3pm on a Friday?
- Relationship. What is the work relationship between the designer and each member at the table? Long-time colleagues? Maybe they just met?
Presenting the way that stakeholders understand
Anticipate the response of stakeholders in regards to their role or responsibility—it’ll give you a better chance at getting what you want (which should be what’s best for the user).
Business executives have different concerns than customer service managers. Development teams have different concerns than user experience designers. And so on and so on. While some may have crossover concerns, few are the exact same.
Why not address those in the project, or the project’s presentation, so that you can make a better connection with different stakeholders? There are several benefits to this:
- It helps the stakeholder or customer know that you’ve taken their concerns into consideration
- It reduces questions or comments around what you already addressed with your proactive work in preparing for them
You don’t need to turn your whole process upside-down and dedicate your work to making stakeholders happy. It just means that you should think about the things stakeholders are thinking about. Then either communicate responses later or be prepared to speak to their concerns during your presentation.
For example, let’s say a designer is pitching a large redesign of a homepage. A sales or marketing stakeholder would probably be interested in that change. It would benefit their case for the redesign to take that point of view into consideration, and address how the redesign would increase conversions or sales in your presentation. Regardless of whether you put it in your presentation, that’s information they’ll want to know.
Deliverables and artifacts
Make sure your documentation reflects data in a way that stakeholders understand.
In Communicating Design, author Dan Brown warns of “self-indulgent deliverables.”
Self-indulgent deliverables are deliverables done for you by you—either for your own understanding or as part of your process.
“Design is a negotiation.”
If you’re showing someone an artifact that was part of your process, be sure that the deliverable is somehow providing a value—a value that the final deliverable doesn’t convey. Otherwise you may be wasting your meeting and your stakeholder’s time.
Keep that artifact in your back pocket, and show it to them if there’s any questioning of how you got to that decision.
In addition to thinking about the stakeholders, make sure that your deliverables are in a format that the people building the product understand. If they’re not, you risk the UX guidance being either misinterpreted or ignored completely. This applies to every level of guidance you provide—from workflows to polished mockups, and everything in between.
Similarly, if you’re confident in your knowledge of users, you should only present a single option as a deliverable. But if there are things you aren’t sure about, showing more than one option is fine.
Your company or client hired you to make design decisions, not present options. If given the opportunity, businesses will almost always choose the faster and cheaper option. This can often be the path with a lower user value or experience.
“You were hired to make design decisions, not present options.”
Designers already have this listening to users thing down. If not, there’s a plethora of other user research articles out there.
It takes a whole different set of skills to be able to listen to your colleagues and stakeholders while they challenge your design decisions.
It can be painful to listen to someone wax on about how they think the product should go in a different direction—whatever the reason may be. I encourage designers to hold their tongue for a minute here. While this hurts in the short term, hear the person speaking out.
In fact, go further than hearing them out and make sure that you understand exactly what and why they’re saying that.
Doing this will allow you to respond more appropriately to their concerns or suggestions. It will also gain their respect and ensure that they’ve made their point.
First, pause for a moment and make sure the person speaking is done. As stated above, make sure that you understand their question or comment. You could even go further and reaffirm you heard and understand their request.
Second, lead with a YES. As Tom Greever stated, “There is no better way to foster an atmosphere of collaboration than to always lead with a YES.” That doesn’t mean “Yes we will do that,” it means, “Yes we will look into or consider that.” Leading with a yes can build trust in ways you never thought possible.
On the other side of the coin, there’s leading with a no, which often builds a perception of superiority and disrespect for others’ opinions—not what designers want. Remember the benefits of leading with a yes and that they don’t always mean saying YES.
Next, always craft your response in a third-party way, from the user’s perspective. How is the proposal that has been made solve the user’s problem or affect the user? You can either respond with why a certain path does or does not do that, or you can turn it around on them.
Finally, you can also table your response or a decision until later on. You can use this as a catch all if you can’t formulate an appropriate response.
“When responding to feedback, always lead with a yes.”
Sometimes the user just doesn’t win—and by the user I mean the user’s advocate, the designer.
Unfortunately, what UX designers propose is often not the cheapest solution possible (as expected). Sometimes, cheaper and easier UX gems present themselves, but that’s rare.
Product design is a compromise, and you aren’t going to win or succeed in every design that you pitch. Know when to fold and move on to the next game. Realize that design is a negotiation, and even though it solves the problem, there are many other things that go into the execution and business other than design.
Side note: in a recent Shopify blog article, Paul Boag asks the question if UX designers are focusing too much on beautiful UIs. It’s worth a read.
I’m far from an expert at communicating design, but I’ve gotten significantly better at it over the years. It takes practice.
Communication is just another skill in a designer’s tool box for getting design pushed from concept to execution. This tool will likely go further than most would think at getting things into a product.
Looking for one of the easiest ways to improve communication with your team? Try out Freehand.