The proposed solution is not the problem
“We need a configurator” describes a possible answer. The problem may be that people do not understand the differences between options, the sales team repeatedly explains the same points, or a quote arrives too late. Each cause leads to a different product. A configurator may be appropriate; in other cases clearer comparisons, a better form or a changed internal process may be enough.
Start with behaviour, not broad opinions
Statements such as “the experience is not modern” or “users want something simpler” are difficult to use. A useful description names the context, person, obstacle and effect: customers comparing two services cannot find the relevant conditions, leave the page and call for help. This level of precision lets the team look for evidence and observe whether an intervention works.
- Who encounters the problem, and in what situation?
- What is the person trying to achieve, beyond using a screen?
- What do they currently do to work around the obstacle?
- How often does it happen, and what consequences follow?
- Which information comes from observation, and which remains an assumption?
The user and the organisation may see different problems
The organisation may want more enquiries, lower costs or fewer errors. The user wants to understand, decide or complete a task with confidence. A healthy product connects the two: clearer information, for example, helps a customer choose and reduces unsuitable enquiries. If the goals conflict, that conflict should be made visible before design rather than hidden inside a screen.
Seek evidence in proportion to the risk
Not every decision needs a large study. For a small change, conversations with support, site-search terms and a few observed sessions may be enough. For a new product or an investment that is hard to reverse, interviews, analysis of the existing process and a tested prototype are justified. The goal is not absolute certainty, but reducing the most expensive unknowns before implementation.
Define an observable change
The problem becomes actionable when we know what a better situation would look like. People might choose the right option without help, complete a process correctly or find an answer before contacting the team. The indicator need not be perfect or limited to conversion. It can combine quantitative data with qualitative signals, such as the kinds of questions received and the confidence expressed during testing.
A good brief keeps the solution open long enough for the team to find a better answer than the first idea.
Record constraints and what you are not solving yet
Budget, time, existing systems, legal obligations and team capacity are part of the problem. Non-goals are equally useful: which audience is outside this phase, which process remains manual and which outcome is not promised. They protect the project from accidental expansion and make prioritisation more honest.
- Write the problem in one paragraph without naming an interface.
- Separate observed facts from interpretations and assumptions.
- Choose an outcome you can recognise after launch.
- List the risks that could invalidate the direction.
- State what this phase does not attempt to solve.