‘We need a new system’ can open a discussion, but it is not yet a problem definition. Behind it may be a long wait, unavailable information, unclear responsibility or a confusing experience. After asking what digitization should improve, we need to step back: what is actually happening, and which part is worth changing?
Do not confuse a symptom with its cause
Imagine a shop receiving frequent calls about order status. This is a hypothetical example. The team might immediately consider a chatbot. Yet customers could be calling for different reasons: the dispatch message is unclear, the delivery window is missing or the system’s status does not match what is happening in the warehouse. A shared symptom does not necessarily have a shared cause.
GOV.UK’s guidance on discovery recommends reframing a predetermined solution as a problem. Instead of asking how to build a chatbot, we might ask how a buyer can understand the status of an order without extra follow-up. That wording keeps more possible approaches available for examination.
Follow an actual situation
Begin with someone’s latest experience rather than their wish list for a tool. Ask a buyer when they last checked an order, what they saw before calling and which answer helped. Ask a support colleague to show how they found that answer. The information may already exist, but not somewhere it can be used at the moment it is needed.
GOV.UK’s guide to learning about users and their needs combines existing evidence, interviews and observation, including people who provide the service. Internal suggestions remain assumptions until research supports them. A manager’s opinion, a call record and an observed user action should therefore not receive the same label.
Keep what is known separate from what is assumed
For example, ‘the buyer called after seeing the dispatch message’ is an observation. ‘They did not understand it’ is our interpretation. ‘A clearer message will reduce calls’ is a hypothesis to test. Distinguishing them is not pedantry. Treating an interpretation as a fact can lead us to choose the wrong solution and then look only for evidence that confirms it.
Examine constraints at the same time. A delivery date may depend on a supplier and cannot be guaranteed, while the explanation of that uncertainty can still change. Not being able to change everything is different from being unable to improve anything. Understanding the problem should reveal where we have authority, where cooperation is needed and where we do not yet know enough.
Write a definition that leaves room to choose
A useful definition identifies a person, situation, obstacle and consequence: ‘After placing an order, the buyer cannot understand the likely delivery window and has to follow up to plan their day.’ It has not committed to an app or chatbot. We can now compare changes to the message, warehouse information, responsibility for replying or a new tool against the problem, rather than against the appeal of a technology.
The definition must remain open to revision. If observation shows that the difficulty concerns only orders with multiple parcels, narrow the scope. If some buyers cannot access a digital message, do not exclude their experience. The aim is not a flawless sentence agreed in a meeting. It is a shared understanding that supports decisions and can change when new evidence arrives.