Framing the problem before you design

Many beginner UX projects go wrong before any research or design happens, because the team starts from a solution. “We need an app”, “add a dashboard” or “redesign the homepage” are answers, not problems. Problem framing means stepping back to agree on who is struggling, in what situation, with what consequence, and how you will know things have improved. It takes an afternoon, and it protects weeks of work: every later decision in this course, from who you interview to which screens you prototype, is checked against the frame you write now.

A practical format is the four-part problem statement: user, situation, struggle and impact. For example: “First-time landlords listing a single flat (user) who are pricing their first rental (situation) cannot tell whether their asking rent is realistic (struggle), so listings sit empty for weeks or rent below market (impact).” Write it in plain words without naming a feature. Then add one outcome you can observe, such as days to first enquiry or the share of users who complete setup, and two or three real constraints: budget, platform, deadline or legal requirements.

Next, separate what you know from what you assume. Draw two columns, “facts we have evidence for” and “assumptions we are betting on”, and list everything the team believes about users. Mark each assumption by risk: if it turned out to be wrong, would the project fail? The riskiest assumptions become your research questions. A good research question is open and answerable through observation, such as “How do first-time landlords decide on a price today?”, not “Would landlords use a price calculator?”, which invites guesses about a future that participants cannot predict.

The common mistakes are framing too broadly, framing around a feature and skipping stakeholders. “Improve the customer experience” is too broad to guide any decision; “help returning customers reorder in under a minute” is workable. If the statement only makes sense when a particular solution exists, rewrite it. Finally, share the frame with whoever can block or fund the work and ask them to correct it now. A frame that a manager quietly disagrees with will resurface later as a request to change direction, usually after you have built the prototype.