How to bring up inconvenient feedback, or when user insights aren’t about design
If you see something, saying something can help your team immensely
“There’s one other thing I’d like to bring up,” I said. I was 95% sure my suggestion would be rejected, but it was essential to talk about it.
Last week, I discussed how designers sometimes feel uncomfortable making direct design recommendations to the team. Whether it’s a fear of hierarchy or being challenged, some designers struggle to recommend things directly.
But even if you’re okay talking about design recommendations, you sometimes uncover deep insights that aren’t directly related to UX.
In those cases, it’s still important to speak up because you are often the first person to notice these problems,
Talking to users often uncovers deep insights outside of design
Designers are often the first ones to uncover signs of a new problem. To explain what I mean, let’s use the analogy of a pebble in your shoe.
For some people, a pebble in their shoe isn’t a problem. Sure, it’s annoying, and they might be slightly frustrated by it, but they’re willing to put up with it in certain circumstances.
So it doesn’t become a customer complaint or come up in sales calls. Customers don’t complain about it on social media. Moreover, many users may not believe anyone can solve their problems, so they don’t complain.
However, when designers spend a lot of time talking with users (testing another feature), users are often willing to voice their frustrations over their current experience.
Whether it’s a 30-minute rant about how your product makes their job difficult or why they never use a particular feature, your interview is often the first time anyone in the organization has heard this feedback.
One typical example of this is the company’s homepage. You might be testing the task of “Getting to the feature from the homepage,” but you might see that 4/5 struggled (and voiced frustration) using our top-level navigation menus.
The problem is that you’re probably 95% sure stakeholders will shut you down. After all, they’ll probably say that we’re not designing the homepage. We’re designing feature X.
But ignoring it and pretending you never found it isn’t the right approach either. So, what exactly do you do with this sort of information?
You preserve it by tying the problem to business impact.
The (business) roadmap, metrics, and how design can help
Here’s a crash course on how design can improve metrics. I have a course on the subject if you want to know more.
The purpose behind any business project is a specific business Goal. A business has chosen to invest multiple employees’ time, effort, and resources into a project because it wants a specific business outcome or goal.
We might design a new onboarding because the product team (and users) have told us it’s terrible, but the business decides to invest resources because it thinks it will attract 50,000 more users to the homepage a month.
However, having a business goal requires measuring progress because you won’t get there overnight. Businesses, therefore, rely on metrics, quantitative measures of user behavior, to track trends, monitor progress, and evaluate whether they’re moving towards their desired outcome.
For example, if the Metrics around a re-designed onboarding go:
March 2024: 11,000 users land on the homepage
April 2024: 15,000 users land on the homepage
May 2024: 19,000 users land on homepage
We haven’t hit our 50,000-user goal, but our design changes are having a positive effect.
So, what does that have to do with design changes? The idea is to align your design changes with the business outcome. If we introduce our homepage recommendation as a weird fact, it will be dismissed as one.
However, if we introduce “Users can’t find our feature” with the context of “We won’t hit our 50,000 user goal unless we change this,” teams will be much more likely to take action.
Here’s how to do that
Preliminary hypothesis: how to get teams to remember user feedback
Let’s go back to our example of the home page. If 4/5 users had trouble getting to your feature from the homepage, what would that likely affect?
It affects the number of people who can find a particular feature. To avoid getting into metric jargon, let’s call this “Feature Discoverability.”
To talk about this finding, put it into this format:
“Users are [doing Y] for [Z reasons], which likely impacts [a relevant metric].”
This offers us a specific way to bring up what is observed and tie it to something that matters to the business. Let’s break it down:
Users are doing Y for Z reasons: This is what you observed during your testing session. Did users fail to find a feature until you pointed it out? What things did they say or do that might be a reason for this?
which likely impact [A relevant metric]: The relevant metric, in this case, is “Feature Discoverability,” which may be related to business outcomes
When you present your findings like that, instead of just in pure design terms, your stakeholders are forced to think about a couple of questions. This may include things like:
Does Feature Discoverability matter? (Of course, it does)
How important is it to tackle feature discoverability now vs later?
How do we incorporate it into the larger product roadmap if we keep it until later (and it still matters)?
etc.
By presenting the user finding not just as an observation but as something that can affect a product’s bottom line, you can get your businesses to pay attention to and focus on questions around the context.
You are often the first line of defense against user problems
Users always surprise me, no matter the project.
Even on the third iteration of a design, I sometimes gain insights into things beyond the user experience. If this is the first time I’ve heard of it, it’s also often the first time your team has.
So, if you hear something that might affect the overall business outcome, it’s essential to discuss it. Even if your team might not be able to tackle it right now, doing this may help you communicate problems that they may not be aware of.
Kai Wong is a Senior Product Designer and Creator of the Data and Design newsletter. His course, Data-Informed Design, shows you how to work more effectively and complete design projects faster without sacrificing quality.