Perspective change for problem-solving

Being a designer in a startup-like setting always is a hectic day both as a design leader and an individual contributor. We, designers, get to solve many complex problems, but the lead time between solving the problem and understanding the problem statement seems to be relatively short at times. Yet, it is precisely the problem-solving mindset challenge that designers face when scaling up their design mindset.

No Thought Problem Solving

As a designer, if you feel constantly overwhelmed with work, you might be busy solving problems like a never-ending checklist. It’s called active problem solving or no-thought-process problem-solving. Frequently, this leads to work exhaustion and burnout in organizations for designers and talented & ambitious leaders in adjacent domains.

Usually, no-thought-process problem-solving: You see a problem, solve that problem, and go on to hunt for the next big issue.

The problem-solving curve here is too short for the product designer to effectively understand the problem, analyze the various angles and deviations, and apply the problem-solving mechanics while keeping other product features in mind. With a shorter problem-solving curve, the design team can usually get more done in less time. But it leads to things failing and falling in various other places that are unexpected. Fortunately, there is a solution to this problem :)

• No Thought Process Problem-Solving is NOT — Fast
• Busy is NOT — Fast
• Progress is NOT — Being Busy

Efficient Problem Solving

Efficient or practical problem solving tends to uncover the root cause and bring more data to the table before the designer or product teams even attempt to solve the problem. However, as designers, we have to apply the research mindset and open ourselves to ask our problem suspects and originators a series of questions.

#1 Whose problem is it?

Figure out the source of the problem. Is it coming from the users, product, or simply some leaders who want you to have a look at it? You need to understand both the origin point of the problem and which the solution will eventually affect. Then you can figure out what the lifestyle and journey-flow for users who will be involved look like in their day-to-day lives.

#2 Should it be solved?

Sometimes non-design problems come to designers because it becomes a protocol. People in companies stop using their brains. Analyze and answer this problem. Is the problem worth solving? Should you solve it, or is it purely engineering or documentation-based?

#3 Should it be solved now?

Some problems are genuinely not the priority. Refocus and rethink on whether we should solve the situation right now or later. Maybe it can be parked in the backlog and picked up after a specific product launch. Is it a scope creep from the PM?

#4 Do we understand the root problem?

Are you simply designing or solving the root problem? Has the PM just pitched you a solution as a problem to solve? Be very speculative of what you are solving and who you are solving a particular problem for in the product. Often a problem has disguised a solution.

#5 Should we solve the root problem?

Sometimes solving a different underlying problem allows the solution to travel to the top. Underlying root causes are the reason why most interconnected issues begin in the first place. As a designer, it is imperative to solve the problem at its origin or the most fundamental issue. Sometimes, the primary concern is smaller than the problem you are to solve.

#6 What are the possible solutions?

Do the competitor study. Sometimes the best solution lies in checking out how others might have solved similar problems. Others have already solved most situations you will face before you in some form or the other. See if there are public solutions to the issues you are facing.

#7 What are some non-obvious solutions?

Competitor study allows you to see what others have done, but it also allows you to see the flaws in your competition’s solutions. Once your competitor study gets completed, it is time to come out of their shoes and drop into yours. See the missing links in their solutions and form your solution that differentiates your products from others.

#8 What new problems might our solutions propagate?

Start using Second-Order Thinking to trace down and unravel the implications of your solution.

“First-order thinking is the process of considering the intended and perhaps obvious implications of a business decision or policy change”

You can zoom out and look at the more extensive practice by employing second-order thinking instead of just first-order thinking.

#9 Are we okay with those problems?

Every solution will have its pros and cons. First, as a product designer, you need to know if the business will be affected adversely due to the issues introduced by your solution. Then, see if you can reduce some of the problems or mitigate new issues before they happen long or short term. Building safe mechanics around future issues is mindful systems thinking that can help businesses capture user interests more appropriately.

#10 Who should own solving the problem?

Divide and conquer. You cannot do everything yourself. Sometimes the problems are meaty enough not to be solved by one single person. It is where you can take the team’s help and leverage their expertise in handling particular domain-specific topics. Delegate problems to the domain experts, ask for help in areas you are stuck with, and focus on solving the problem at hand; knowing the issues you can resolve and which you cannot is a time savior.

#11 How will we know it is solved?

Every time we embark on a journey to problem-solving, set up a meeting with the product team and hash out a product metric that points to certain conclusions. These metric pointers can be qualitative or quantitative, and they will serve as a north star at times. As a designer, you need a metric to tell you the problem solving should end. We shouldn’t be kicking a dead rat.

#12 How might we prevent such problems in the future?

Look at the general problem types in your organization and come up with a framework that allows you to question the problem from different perspectives and align the teams towards a singular goal. It can help you to win more significant battles in the future and not get lost in execution.

Why Efficient Problem Solving?

Efficient problem-solving in the long run will help you and your team tackle problems in a more calculative manner. In addition, it can help the team to go much faster because you will spend your time & energy on the issues that matter. You will have saved a ton of time-solving the correct problems and not playing the catchup game. For this reason, most experienced folks will focus on research first before jumping into the solution.

I sincerely hope that this write-up can help you design your own research questionnaire/framework for problem-solving at your organization.