Writing problem statements and explaining context

The problem section sets up everything that follows. If readers do not understand the problem, they cannot judge your solution.

What to include

• Users: who they are and what they were trying to do.
• The problem: what was going wrong, ideally with evidence (data, quotes, complaints).
• Why it mattered: impact on users and the organisation.
• Context: the product, team, your role and timeline.
• Constraints: what limited the solution.

Be specific

"Users found the app confusing" is weak. "Two in five people who started a claim abandoned at the photo upload step, and support received 300 calls a month asking how to send photos" is strong.

Respect confidentiality

If you cannot share exact figures or names, use percentages, rounded numbers or describe the organisation generically. Never break a non-disclosure agreement.

A well-framed problem makes your work meaningful and your decisions understandable. It also shows that you start with problems, not solutions, which is one of the main things hiring managers look for. A vague problem makes even good solutions look arbitrary.

Weak: "The client wanted to modernise their booking app."

Strong: "Patients at a chain of dental practices booked appointments mainly by phone. Receptionists spent about three hours a day on calls, and 18% of appointments were missed. The online booking tool existed but was used for only 9% of bookings because it did not show real availability. I was the sole designer on a six-week project to increase online bookings and reduce missed appointments."