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.