Avoid premature solutions: how to respond when stakeholders ask for certain designs
How to avoid anchoring problems that result in stuck designers
“So, we’re trying to design a table that helps users find exactly what they’re looking for, " The product manager told me, which was more problematic than you might think.
Non-designers suggesting design solutions has been a problem since UX was created in the 1990s, but you might not have understood why this was such a big deal.
After all, it’s just a suggestion from a stakeholder, right? Except that’s not all it is: sometimes, it becomes the anchor that weighs us down as an anchoring problem.
You must reframe these suggestions early to avoid much future pain.
Anchoring problems and one of the fallacies that currently exist
In Designing Your Life, Bill Burnett and Dave Evans introduce anchoring problems using the Grand Canyon mule trip example.
“Charlie” wants to explore the Grand Canyon with his family, and he has a specific vision of the experience: exploring it by mule.
The only problem? The mule trips have a weight limit of 200 pounds. So each summer, Charlie tries to diet to hit 200 pounds and fails. The result? He skips going to the Grand Canyon with his family four summers in a row.
You could explore the Grand Canyon by helicopter, on foot, by mule, or in any of a dozen other ways, but because your heart is set on a specific solution, you make the problem much more complicated than it needs to be.
This can happen when you accept a non-designer suggestion for a design solution. While sometimes it might not be that bad, I once worked on a project that had to jump through many hoops because “Derek hated tables.”
Our executive had a design solution in mind for showing the status of an inventory of all devices discovered: Don’t use tables. Use cards.
The problem was that cards couldn’t handle the scale of devices we discovered. We often would discover 50–100 devices at once, and showcasing 50 cards to users was getting them confused.
Tables appeared to be the only viable design solution, but this resulted in weeks of back-and-forth that were only resolved with layoffs.
Why? Because the further you move away from the anchor, the harder it is to pull up.
The anchoring problem: it’s harder to move the further away you are
Imagine this: the Product Manager has a vision of a design solution based on some requirements and voices it to the team. They say, “I want a table that allows us to check statuses of 100 devices at once.”
You don’t say anything, so that sets the anchor of a design solution as “a table with a bunch of devices and statuses.”
The Engineering and Product teams now think, “Okay, for this project, we’re building a screen that shows a table with statuses.”
Engineering might even explore some backend stuff to support tables with dynamic statuses.
If you come back with design screens for something else, a data visualization that reflects statuses? That can sometimes feel like pulling up your anchor when your boat is a mile away.
You’re not designing what the rest of the team had in mind. Does that mean it will get shot down? No. But it’s much easier to lift the anchor when you’re right next to it and ensure there’s no struggle a few weeks later.
To do this, you can lean on the 5 Whys.
5 Whys, How Might We, and avoiding a design solution statement
In these situations, one of the most important things to do is to take action when you hear anchoring problems in meetings.
Because it can happen unexpectedly, it’s best to keep your tools simple to be prepared for these situations. Therefore, it’s best to use 2 common tools to help you:
5 Whys to uncover root causes
How Might We rephrase the statement
Here’s how it works.
Uncover the root causes with 5 Whys
When you find yourself in these situations, the simplest thing to do is to address the issue from a business perspective.
So, the first question you must ask is, Why? Interrupting meetings can feel incredibly awkward, but it’s one of the surest ways to transition away from anchors that will weigh you down.
As a result, you must keep two things in mind. The first is that the person you’re questioning will not know why it’s an issue from a user perspective.
If you’re expecting the 5 Whys to go like:
“Users aren’t using a feature.
Why? Current design principles prioritize minimalism over discoverability.”
That is not going to happen. However, you can uncover issues from a business perspective if you can ask questions effectively. The best way to do this? Modify your Whys to target business needs. For example:
“We’re trying to design a table that helps users find exactly what they’re looking for.”
Why is this a priority?/Why does this matter?/Why Now?
“Because it’s taking users a bunch of extra time to find the right result out of all that information.”
Why is this a priority?/Why does this matter?/Why Now?
“Because spending that extra time means our overall performance metrics aren’t where they need to be.”
The second thing to realize is that while the purpose of these questions is clear to you, it might not be apparent to your team. So, you need to emphasize the payoff answering these questions will have.
Here’s how you might approach this in meetings:
“Hi, I wanted to make sure I understand your perspective so that I don’t waste time designing the wrong thing.” (Payoff to questions)
Why is it a business priority to design a table that helps users find exactly what they want?” (5 Whys to anchoring statement)
After this, it’s time to rely on How Might We.
How might we, or rephrasing the solution
After you ask the questions, quickly replace the anchoring statement with a better one.
Remember, you may not be expecting these statements in meetings, so the idea is to replace them with something better in the moment. It doesn’t have to be perfect, just less problematic.
So after you ask your questions, try to rephrase answers into a more neutral “How Might We.”
For example, after asking your questions, you might say:
“Based on what I’m hearing, would you say, “How Might We provide users a quick way to find the right result out of a database of hundreds of entries?” to be a good summary?”
This rephrasing statement showcases that you’re listening and opens up more possibilities on the design side.
Notice, you’re not designing a table in specific. You could design something like a robust search system (with features like autocomplete).
You could design a table with smart defaults or a “history” section to quickly return to where they were working.
There are many more possibilities, and you aren’t locked into a specific design too early.
This is how you avoid getting stuck as a designer.
Don’t let an anchor keep you from going where you want
Anchoring problems are more common than you think because people like examples.
Using a table may not be the only solution. Your Product Manager may not like tables, but they need some way of giving an example to explain what they’re thinking about, so they might bring them up all the same.
They may not realize until six months down the line that everyone followed the first example that came to mind, which designers created and Engineers built, and now they’re stuck with a table nobody likes.
But this is where designers can have an impact. By re-framing what the business is looking for (with the 5 Whys and How Might We), we can avoid prematurely anchoring ourselves to a single design solution.
If you hear non-designers providing design solutions, do a quick reframe. Doing that now can save you weeks of frustration, and it’s not that difficult to change.
April’s Data-Informed Design cohort closes enrollment on Sunday!
Kai Wong is a Senior Product Designer and Data and Design newsletter writer. He teaches a course, Data-Informed Design, using data to communicate more effectively and get buy-in for your design recommendations.