If your team thinks they know exactly what to design, say it back to them
How to deal with stakeholders that have a strong vision of what needs to be built
“I’m not quite sure what the Product Manager really wants.” a former colleague once told me, which wasn’t uncommon.
You don't always have context when you work in complex web design. However, the lack of context here wasn’t about not understanding acronyms. The problem was around a product's vision.
Sometimes, you’ll find yourself working with a Subject Matter Expert who knows what you should build based on 20 years of experience. Or a CEO with a strong vision of what they want to create.
If that’s the case, one of the best ways to clarify what they truly want is to loop for understanding.
That can be the difference between designing the wrong thing and understanding what your team needs.
Supercommunicators and emotional connection
If your team has a clear idea of what they want (or think they do), there’s often an additional element to conversations that you might not realize.
This is because their problem isn’t about the right idea. It’s about explaining it to others.
They might have trouble condensing their product vision into a list of requirements or be unable to use the right words to describe what they want.
Or, they’re trying to describe things based on their knowledge, not realizing that you’d need 20 years of experience to understand their explanation.
As a result, delivering designs that aren’t what they’re looking for tends to be extra frustrating. Why? Because the conversation isn’t entirely logical.
Yes, there is a logical layer to discussing product requirements with your product manager. But the root of all frustration around this process comes from the emotional level of “You’re not listening to me.”
When the Product Manager or Subject Matter Expert sees designs completely different from what they envisioned, what’s the first thought in their mind?
“I explained exactly how to build this thing, and you didn’t listen to me.”
It might not come to mind that they explained things poorly. Or that their requirements misled you. They might not realize you’re also frustrated because you designed precisely what they laid out, and now they’re rejecting it.
This emotional frustration short-circuits logic and can damage long-term relationships.
If the PM thinks, “Oh, design is slow and never listens to me anyways, which causes them to waste time building the wrong thing”, guess who may want to consider (poor) alternatives like AI-generated designs?
This is part of why designers tend to ask many questions, but that may not be enough to break through.
However, you can often use a simple communication trick to fix these emotional issues: looping for understanding.
Looping for understanding or showing that you are listening
After someone tells you what they’re looking for, ask enough questions to say, “So what I’m hearing is…” and summarize what you heard in your own words.
It sounds basic, but I can’t tell you how often I hear designers skip this step and run into issues.
This is effective for several reasons. First, it is undeniable proof that you are listening. Other cues like body language, nodding your head, and saying words like “Yes” might seem like you’re listening, but it’s ineffective in the age of Zoom meetings.
This helps you avoid those issues where Product Managers feel like “you ignored what I was saying and wasted everyone’s time.”
Secondly, this summary also allows the team to interject and correct your understanding before you design anything.
For example, you might say, “So what I’m hearing is that you want to add users and their working hours, so I know who’s online and can handle an issue.”
Then, your PM (or another team member might say), “Oh, wait. If we do that, we have to think about time zones and how to display them.”
Lastly, it’s a great way to get more context around jargon.
If your Subject Matter Expert is talking about “Managed Entities” as a descriptor, and you have no idea what that means, summarizing it as “a Database” (i.e., your best guess) may prompt a discussion about what that term means.
By having a chance to converse about a summary (in your words), you build a way to clarify understandings, show that you’re listening, and get to the heart of what matters.
Looping also allows you to interject with another technique that can help keep your product user-centric: problem framing.
Problem framing, or avoiding features that aren’t solving problems
When you summarize what your team is saying by looping, this allows you a unique opportunity to do something else: frame problems around users.
After all, you want to design solutions to problems users (and the business) encounter rather than features no one needs.
So, when you interject with your summaries, you can use connecting words like:
“So users can…”
“Because users are running into this problem.”
“Currently, users are …”
etc.
Taking our previous example, we might say something like this:
“So what I’m hearing is we want the ability to add users and their working hours because, currently users are getting pinged with notifications at 1 AM. We want the ability to know who’s online and can handle an issue.”
While this won’t always work, these summaries can sometimes help PMs (and other leadership) see that particular features might not be the top priority.
After all, if you’re having trouble defining why a user wants to do something, your PM might also have difficulty.
By taking these two steps, looping for understanding and problem framing, you can not only ensure that you’re designing the right thing but also build a better relationship with your team.
Design communication is the other half of what we do
One of the most essential things for designers to do early on is to get as much clarity as possible on what needs to be designed.
Product Managers and Subject Matter Experts may clearly know how to do that. However, they might not realize that they’re not explaining things well.
This is where looping for understanding (and problem framing) can be a critical skill.
Taking the time to ask questions and ensure that you can summarize what they’re looking for is not only how to stop wasting time designing the wrong thing.
It’s how you can build up trust and relationships in your organization.
Kai Wong is a Senior Product Designer and Data and Design newsletter writer. He teaches a course, The Strategic Designer, on using data to communicate more effectively and get buy-in for your design recommendations.