Written on the 4th of February 2024.

Never accept solutions from your users

Whenever my boss comes up to me with a feature he would like to see, I always remind him of the mantra "Don't think in solutions but problems". Sounds weird but let me explain.

Let me begin with some math; don't worry, we won't actually calculate anything. If you want to know the surface area of a circle, you simply grab the right formula and plug in the radius of that circle. And voilĂ , you have the surface area of that circle, except of course when you use the diameter of that circle instead of the radius. A mistake that can be quickly made but results in a completely wrong answer. The same applies to computer systems; a processor is nothing more than a rock we taught some math using lightning, after all. If we develop a system that works flawlessly but give the system the wrong input, it will provide the wrong results. It can't correct for that since the program doesn't know it has been given the wrong input. Simply put, rubbish input will lead to rubbish output.

When it comes to designing solutions, the same idea applies; the most important thing to get right is the problem you are solving. Which is harder than it may seem, after all, the user will tell you exactly what they need, right? Unfortunately, no. Your users are smart, often too smart for their own good, and will try to solve the problem themselves. Which, credit to them, they sometimes will, saving you the trouble of having to figure out how to best help them. But when they are unable to figure it out, they will ask, but what they ask is not always what they need.


Problems with proposed solutions

A request the user might have is "The website needs to be available as a progressive web app." Which sure can be neat, but if their actual problem is that the interface is difficult to use on their phone, simply adding the files and metadata for the website to qualify as a progressive web app isn't going to make the interface any better. The best-case scenario is that you will have a look at the website on mobile and come to the same solution as the user. Most likely, you won't have the resources to do this as well and simply stick to the original plan of throwing a manifest file at it.

What I just described is sometimes called the XY problem: someone asks for solution X, but actually wants to solve problem Y. There is a disconnect between the underlying pain point of the user and the requested solution by them. Some more examples are:

As a result of addressing the wrong problem, the user will be provided with an incorrect solution that does not address the pain points they might be experiencing, leaving them with an unsatisfying solution and a lot of wasted time. The wrong conclusion to take from this would be that the user is wrong and should have asked the right question in the first place. I always like to put that burden on the designers and developers; they are the experts after all.

Meme of principle Skinner from The Simpsons with the text: Am I out of touch? No, it's the users who are wrong. Link

How to find the user's problems?

Because users can come to you with the wrong solution to their pain points, your response to their requests is critical in helping them. As mentioned before, if you accept it at face value, you might not be helping them at all. Instead, you could create more problems for them and yourself in the future. Therefore, you must resort to an approach that goes beyond addressing the presented solution. The key lies in asking probing questions to find the root problems and then guiding them towards articulating their desired outcomes within the context of their requirements.

Designers and developers can employ a series of probing questions in identifying these root problems; some essential questions include:

By encouraging users to articulate their objectives and constraints, you can learn the information needed to address their problem instead of fixating on a particular solution, fostering a more holistic approach to problem-solving. However, merely asking questions won't always be enough for larger and deeper problems as well as problems that require larger solutions. Designers and developers can employ additional strategies such as:

Following the idea of "Don't think in solutions but problems" is critical for designers and developers dealing with user requests. The inherent challenge lies in users proposing solutions (X) while intending to address an underlying problem (Y). Recognizing this discrepancy is essential, as blindly implementing a suggested solution can lead to dissatisfaction and resource wastage. The burden is on designers and developers to unravel the actual issues behind users' proposed solutions. Employing probing questions and other strategies collectively forms part of a toolkit for this purpose.

By embracing a holistic problem-solving approach, prioritizing comprehension over immediate fixes, and fostering effective collaboration with designers, developers, and other stakeholders, ensure that their solutions resonate with users' actual needs. The key point is shifting from merely addressing the presented problem to finding the root issue, facilitating a more meaningful and efficient design and development journey. This approach helps us move beyond the appeal of accepting solutions at face value and towards creating solutions that truly cater to users' pain points and expectations.

And that is why I tell my boss to think in problems and not solutions.


Further reading