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:

• Superficial file manipulation: Rather than asking about how to retrieve a file extension (Y), someone might ask about extracting the last three characters from a filename (X). The narrow focus of the question neglects the fact that file extensions can vary in length and structure, impacting the robustness of the solution. It can work in some situations, but most certainly not all.
• Distorted string manipulation: Someone might ask about obtaining a string between two delimiters (X) instead of understanding how to parse JSON (Y), which can lead to suboptimal data manipulation solutions, overlooking the broader context of their information processing needs.
• Password security issues: One can insist on longer mandatory passwords (X) instead of implementing other security measures such as two-factor authentication (Y), which can compromise website security by neglecting a more robust and user-friendly approach to authentication.

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.

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:

• What is the ultimate goal you're trying to achieve with this solution?
• Are there any related issues or challenges that you haven't mentioned?
• Can you provide more context about the broader problem you are facing?
• Are there any specific constraints or requirements we should be aware of?

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:

• Root cause analysis: Conduct thorough root cause analysis to identify the underlying issues, avoiding superficial or symptomatic solutions. Encourage a holistic view of the problem, acknowledging interconnected factors.
• Contextual understanding: Strive for a comprehensive understanding of the problem by considering the broader context and potential interdependencies. Collaborate with stakeholders to gather diverse perspectives and insights.
• Open communication channels: Establish open communication channels with stakeholders, encouraging transparent discussions about the problem space. Foster an environment where stakeholders feel comfortable expressing their concerns and providing valuable input.
• Proactive inquiry: Engage in proactive inquiry to uncover the root problem by asking probing questions. Foster empathy to understand the stakeholders' perspectives, needs, and desired outcomes.
• User-centric approach: Adopt a user-centric approach, prioritizing a deep understanding of the end users' challenges and preferences. Encourage users to articulate their needs, ensuring that proposed solutions align with their expectations.
• Prototyping and validation: Develop prototypes or proofs of concept to validate assumptions and ensure alignment with the root problem. Seek feedback from stakeholders and end users to validate and refine proposed solutions.
• Iterative design process: Embrace an iterative design process, allowing for continuous feedback loops to refine solutions based on evolving insights. Iterate on solutions in response to new information, ensuring alignment with the actual problem.

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.

Written by Ron Dekker on the 4th of February 2024.

Further reading

• How to Ask Questions The Smart Way written by Eric Steven Raymond. The article mentions the XY problem amongst others as well as their solutions. It is more aimed towards software developers asking questions, but nonetheless a worthwhile read.