A request usually arrives as a feature: add a filter, build a chat screen, make an app. Behind it is a problem someone has noticed. If the team designs the feature without understanding the problem, it can deliver exactly what was asked and still change nothing.
Starting from the solution also narrows the options too early. A reorder problem might be solved by a filter, a reminder, a saved list or a single button on the home screen. Only a clear view of the problem shows which is worth building.
Describe who is stuck and where
A useful problem statement names a specific person, the situation they are in and what they cannot do. “Shop owners reordering stock cannot see what they bought last month without calling us” is something a team can design for. “Improve the reorder experience” is not.
Describing the situation matters as much as the person. The same shop owner behaves differently at the counter with customers waiting than in the evening with time to spare. Design has to fit the moment the problem actually happens.
Say how you know
Next to the problem, note the evidence: support calls, sales conversations, usage data, sessions the team watched. If the evidence is thin, that is useful to know. It may mean a little research is needed before any design, or that the idea should be tested cheaply first.
It helps to separate what is known from what is assumed. Both belong on the page. The assumptions are exactly where a quick test or conversation can save weeks of work.
Define what better looks like
Write down what would be true if the problem were solved. Fewer calls about reordering. Orders placed in less time. People finding their history without help. This gives the team something to check the design against, and something to measure after release.
Keep these outcomes about the person, not the feature. “The filter is used” is not a sign the problem is solved. “Fewer people call to ask what they ordered” is.
Keep it to one page
The statement should fit on a single page that anyone in the company can read in a couple of minutes. Share it before design starts and ask people to challenge it.
Disagreements at this stage are cheap. The same disagreement discovered after weeks of design and development is not.
