Frame a testable user problem from task evidence while separating observations, assumptions and proposed solutions.
User experience work begins with people, tasks and context before screen styling. A stakeholder's request for a larger button proposes a solution but does not explain why a user stalled or what they were trying to accomplish. Keep three layers separate: an observation supported by a session or record, a provisional interpretation that may change, and a design decision that still needs testing. This prevents a single opinion from becoming a fact. A support agent's report that customers miss a help link is useful for exploration; evidence of the problem requires the task, where people stopped, and a description or count of comparable cases. The point is not to postpone every decision until a large study exists. It is to state the level of certainty before investing in one solution.
A testable problem statement records who is attempting which goal, in what conditions, where the journey breaks, the cost of the break and what evidence is missing. Name the unit of measurement. Seven failed attempts in ten sessions are not seven affected people in ten if one person retried. Do not confuse failure to find an option with rejection after finding it. The former may point to information architecture or a poor label; the latter could concern trust, cost or comprehension of terms. Derive the research question from the real gap: 'How do participants look for order confirmation after payment?' is more useful than 'Do they like the new button?' Then select observation of a realistic task or an appropriate log analysis according to what needs to be learned. Where evidence is absent, mark an assumption and ask the next question instead of presenting a finished finding.
A small evidence ledger makes the discussion reviewable. Use columns for statement, kind of statement, source, unit of measurement, rival explanation and next step. For example, 'returning occurred in five sessions' is an observation tied to session records; 'the button color caused it' is a hypothesis unsupported by that count alone. If the team wants to enlarge the button immediately, place that in a candidate-solution column and specify what would make it preferable to changing the label or the confirmation location. The practical test is whether a change removes the observed obstacle without introducing another one, not whether the change sounds plausible. A low-cost repair can be made while explicitly treating it as provisional and checking its effect in a comparable task. Research thus remains part of a design-and-evaluation cycle rather than a separate report completed before any interface is built.
Lesson summary
A testable problem statement records who is attempting which goal, in what conditions, where the journey breaks, the cost of the break and what evidence is missing.
