How do you define the problem statement in design thinking?

The problem statement is like the North Star that guides the whole process. When you have a clear problem statement, it helps everyone on the team understand what they're tackling. It also makes sure you're thinking about who are affected by the problem and their needs. This clarity helps spark creative ideas and makes sure one is not wasting time and resources on the wrong stuff. Plus, it sets the stage for measuring progress and success. It keeps everyone on the same page and working together, and it helps you spot and deal with any potential roadblocks early on. And, of course, it's key for getting everyone, including stakeholders, on board with what you're trying to do.

First off, it is always important to remember that the field of UX is concerned with solving problems that return value to the business and users. Failing to properly capture/reconcile business goals and user needs, either at the start of the project or continuously throughout the project's duration, is the difference between solving the right problem or an arbitrary one (which is never good). Problem statements: a) frame your understanding of the problem, b) define scope so you remain grounded c) provide a forecast for impact These statements can either be a sentence or a few paragraphs, and should always clearly state the problem—without ambiguity.

There might be many problems that you have discovered in your research, but you need to prioritize and articulate the best and most critical set of problems from that lot. Choose your wars wisely A problem statement most of the time can be given to you in a ready-made fashion from Product teams, but do not take it for face value or as is. Try to dig deeper and validate if we are solving the most critical problems from a zoomed-out perspective Any designer's ideal goal would not be to work on small problems that create a smaller impact This does not mean it is bad to work on small problem areas, but if you want to create a bigger impact you need a different perspective from the start of your project

The "opportunity" statement is a point in a users' experience where value can be added, where we can make their lives easier. Not only should it include the problem, but the root cause, which can often be gathered using the 5 Why's method. It should include entry and exit points for context and reference touch points whether human or technical.

In design thinking, defining the problem statement is a critical initial step that sets the direction and scope of the design process. Here's how you can define a problem statement effectively: Understand the Context: Begin by gaining a deep understanding of the context in which the problem exists. This involves researching the users, their needs, and the environment in which the problem occurs. Observe and Empathize: Engage in empathy-building activities, such as user interviews and observations, to put yourself in the users' shoes and understand their pain points and frustrations.

Measuring user sentiment along the journey is key during this part, if a user is coming into a journey already frustrated, you may need to increase the scope of your study to include external factors or outlier conditions.

Gather stakeholders insights, research insights, analytics, and perform contextual inquiry when possible to synthesize domain knowledge around the problem. Use inductive reasoning where you have gaps, and get started with a simple problem statement. Refine the problem and look for ways to quantify milestones toward your goals to overcome the problem.

Also, identify your key stakeholders and what metrics or key points motivate them or how they think about the problem. You're not synthesizing the data for yourself, you're synthesizing the data for your team, so have a good idea of how your data will be consumed and by who. Have you identified KPI's, who decision makers are and what they're looking for to make decisions?

Making meaning out of collected data can be overwhelming, at times. Resist the urge to organise data into predefined boxes early in the process; externalising analysis will provide a broad overview and reveal hidden relationships between pieces of data. Have a big wall? Print what you have and pin them, then zoom out. No wall? Spread them on the floor. The goal here is to reframe how you interpret what is in front of you.

Always consider the balance between the ideal experience and the impact it will have on the business providing the experience. Are there any upstream factors that would limit the potential impact? Will your insights require large systemic or process change? Would the solutions create new problems for others?

This is your big empathy moment. Have you removed all of your personal bias? Have you gotten as close as possible to the users' experience and environment to fully realize the problem. Problems are often multi-faceted and distilling them down to one statement will never address every users' unique perspective, but give yourself a gut level check to ask yourself those questions.

I find it useful to bring data into the problem statement to help tell the story effectively to data-driven collaborators and stakeholders. What is the state of things? What is the trend?

Once you've landed on a statement you feel confident about, the team should be in agreement, a simple meeting can achieve this. If you've been collaborating with your peers during this process, they will feel more aligned and that they've had a chance to contribute. This will make the process much easier. This will be where you go back to, to ask did we solve and add value.

Get alignment that the problem warrants solving, and how success might be measured. One way I’ve checked for alignment is to ask “if we were to solve this problem as stated, would we feel good about ordering a cake to celebrate?”

Experience, language and simplication are key figuring out direction. Here's are Qs from problem statement sprint I conduct after a VP sprint. It only works if you give 1-2 word answers each: Who does problem effect? ? Who are primary, secondary users & spectators? ? What are the problem's boundaries? ? What current issue requires immediate attention? ? What's the impact of ultimate goal? ? Whats background info is needed/missed? ? End solution in one word? Dive deeper further with these in later stage: What if problem isn't solved? ? When do issues occur in one word? ? When are you looking to plan, ideate & ship? ? Where's the problem occuring? ? Where do we need to focus most? ? Why it's better for users? Write your statement.