How to Write the Problem Statement in a UX Case Study

A problem statement is often treated like a polite opening paragraph. In a portfolio review, it has a more practical job. It tells the reader what situation you were trying to improve, who was affected, and how the rest of the case study should be evaluated.

Start with the situation, not the solution

A weak problem statement usually jumps too quickly into the product idea. “We designed a better dashboard” gives the reader almost no reason to care. A clearer version starts with the situation: new account managers could not identify which customers needed attention because important signals were spread across three separate views. Now the reader understands why a dashboard might matter.

Name the user, but avoid generic user pain

“Users were confused” is too broad. The reader needs to know which users, in which moment, and what the confusion caused. A better version might say: “First-time applicants were abandoning the loan application after the income step because they did not understand which documents were accepted.” This creates a sharper design problem.

Include business context when it affects the decision

A case study does not need a business essay, but some business context helps. If the company needed to reduce support tickets, increase activation, shorten onboarding, or improve task completion, say that. The goal is not to sound corporate. It is to show that your design choices were connected to a real constraint.

Keep the scope visible

Many case studies become vague because the problem is too large. “Improve the banking app experience” is not a useful scope. “Reduce confusion during card activation for new mobile wallet users” is much easier to evaluate. A scoped problem statement helps you decide what belongs in the case study and what should be left out.

Connect the problem to the method

Once the problem is clear, your research and design process should feel necessary. If the problem is about trust during payment, the reader expects evidence about trust, risk perception, and user confidence. If the process does not connect back to the problem, the case study starts to feel like a list of activities.

A practical formula

Use this structure as a starting point: user group, situation, friction, consequence, design challenge. Example: “New sellers were trying to publish their first product listing, but pricing and shipping rules were unclear. This caused repeated support requests and incomplete listings. The design challenge was to help sellers understand the required steps without turning the flow into a long tutorial.”

Frequently Asked Questions

How long should a problem statement be? Usually one short paragraph is enough. If it needs several paragraphs, the scope may be too broad.

Should I include metrics in the problem statement? Include them if they are real and relevant. Do not invent numbers to make the problem sound stronger.

Can I write the problem statement after finishing the case study? Yes. Many designers understand the real problem more clearly after reviewing the full project.

What is the most common problem statement mistake? Starting with the solution before the reader understands the situation.

Should junior designers include business context? Yes, when they have it. If they do not, they can explain the assumed context honestly.