How to write a problem statement before choosing a solution.

1. Put a person in a real situation.

Describe the relevant situation rather than inventing a personality. First-time volunteers preparing for their first session is a more useful starting point than busy people who care. The first phrase tells you when the difficulty occurs and whose experience to investigate. The second could describe almost anyone and cannot guide a useful conversation.

Be explicit about whose experience is missing. Someone with a slow connection, a different language preference, or an assisted way of completing the task may encounter a different barrier. Do not add personal details simply to make the statement vivid. Include a circumstance only if it helps explain the task or changes what a useful response would need to support.

2. Describe the task without prescribing the channel.

GOV.UK's user-needs guidance separates the person's goal from a proposed solution. Make that distinction visible in your document. A person might need to confirm where to arrive and whom to contact; a notification, printed sheet, phone conversation, or clearer page could each help in different circumstances. Needing an app assumes a channel before establishing the task.

Write the task as something the person would recognise. Avoid an internal department's objective such as increase engagement when the person's job is choose a suitable role. A team can care about engagement, but the statement should first explain what the person is trying to accomplish. Otherwise you risk improving a dashboard while leaving the actual handoff confusing.

3. Separate the barrier from your explanation of it.

Record the difficulty and its consequence at the strength your source supports. If a participant says they contacted a coordinator because the page did not identify a meeting point, that is an account of what happened. It is not yet an observed test of the page, proof of the only cause, or a count of everyone affected.

Keep an explanation such as the wording is too technical on an assumptions line until you have investigated it. The issue might instead be outdated information, a broken link, an unfamiliar place, or a mismatch between the page and the invitation. A statement that leaves these possibilities open makes it easier to compare responses without defending the first idea somebody suggested.

4. Attach a short evidence note and an uncertainty.

Beside the statement, record the source, date, context, and whether it is observation, a participant account, or a team assumption. Use private source IDs rather than copying identifying material into a widely shared brief. Preserve contradictions too: a person who completed the task easily may have had information or assistance that another person lacked.

If there is no direct evidence yet, call the statement provisional. That is a useful status, not a reason to dress it up as a validated insight. Decide what would change your understanding and whom you should learn from next. A statement can guide initial research before it is supported, provided the team does not quietly treat that provisional wording as an established fact.

5. Rewrite a solution request as a bounded problem.

This hypothetical example is not a SIX33 research result. A team starts with we need a volunteer app. Its only evidence is two recent messages from first-time volunteers asking where to meet and whom to contact. Those messages support investigating arrival information. They do not establish demand for an app or show how common the difficulty is.

A provisional statement could be: before their first session, some first-time volunteers cannot confirm the meeting point and contact person from the information they received, so they need another exchange with the team before they can plan their arrival. The evidence note identifies the two messages, the invitation version, and the unanswered question of whether the information was missing, hard to find, or out of date.

A next learning step is to review the invitation and ask people about their latest preparation experience. If you later observe people finding the details successfully but still being unsure about transport, revise the problem instead of forcing the new evidence into the arrival-information explanation. A solution-neutral statement should make a changed understanding possible, not merely make an old feature request sound more thoughtful.

6. Use the statement to choose a learning step, then a brief.

Ask a colleague to name two materially different responses that could address the statement. If the only possible answer is the feature you already wanted, check whether the wording has smuggled in that feature. Also ask whether the person, moment, barrier, and consequence can be understood without an explanation from the author.

Do not promise an improvement the statement has not tested. Fewer clarification messages, for example, might reflect clearer information, fewer participants, or people deciding not to ask for help. Decide what you need to learn before choosing a measure. Once the task and uncertainty are clear enough, turn the proposed delivery into a brief with an owner, scope, exclusions, and an appropriate evidence gate.

Keep the earlier version and the reason for any revision. A short record of what changed prevents a team from remembering that it knew the answer all along. The goal is not a perfect sentence that survives forever. It is a precise, revisable description that helps people spend their next effort on a real difficulty rather than on the most attractive imagined solution.