The right approach to diagnosing a problem

Problem-solving is not a skill, it is a way of thinking. Though having the right skills and relevant experience matters. Your true value as a designer is based on the scale of problems you are able to solve.

In simple words, A problem is defined as the gap between the actual and expected results. (Read that again)

A person’s ability to be an effective problem solver and bridge this gap, lies in their approach to solving that problem.

Understanding the clear difference between a good and a bad solver depends on the initial approach a person takes to a problem.

• Bad Problem Solver: Jumps straight to causes and is already in a solution mode.
• Good Problem solver: Tries to understand the problem in great detail first.

Let’s understand this better with an example: A client comes to you with a problem that his cupcake sales are low.

A bad problem solver bombards the client with statements like, “your packaging is bad, you need better customer service, try building a website”, and so on.

On the other hand, A good solver has learned to tame this demon, he takes his time and tries to better study the problem first. With this person we hear questions like: “How are you selling your cupcakes?”, “Who are the people buying your cupcakes?”, “At what time are they buying your cupcakes the most?”

Asking the right question is already half the answer, and the more questions you ask and the more time you spend on defining the problem, this helps you gain some valuable data. And the root cause of a problem is often hidden in the data you collect. So, the more data you have the better your chances are of finding that exact root cause.

Setting meaningful requirements

Once you have the exact root cause of the problem, you use this to set meaningful requirements. These requirements will give a clear direction to your product and help you create a better process. In this approach of problem solving, more emphasis is given to the problem and we spend more time and effort on the problem rather than the actual solution.

As Albert Einstein said,

“If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it.”

Another thing to keep in mind is to know if your requirements are meaningful. The difference between a requirement and a meaningful requirement is verification and validation.

• Verification is “Are you answering the questions correctly?”
• Validation is “Are you answering the correct questions”

Coming back to our Cupcake example. A requirement could be to increase sales of cupcakes. The design team puts their heart and soul to achieve this requirement and ends up increasing the cupcake sales by 10%. But after a few months, it’s seen that the profits are not getting better. So, further analysis shows that a min of 20% increase in cupcake sales was required to sustain the cupcake business for the long run.

Obviously, this could have been avoided by if the the problem was better defined in the initial stage.