Frame the Service Problem Before Its Interface

When a team says, “We need a new appointment app,” it has named a possible solution, not an established problem. Design thinking starts by widening the view to the task a person is trying to finish. Service design also asks what happens behind the interaction: staff, operating rules, and information passed between them. A booking form may be easy to use while a visitor still makes a wasted trip because the required documents become clear only on arrival. Changing a button cannot repair that failure. Ask who is trying to achieve what, where the whole journey breaks, and what the team can verify. The Design Council's Double Diamond describes discovery and definition before development and delivery; the stages invite iteration rather than a rigid handoff sequence.

Separate four things in the brief. A need is the person's underlying goal, such as booking a visit that lets them finish the transaction in one trip. A symptom is an observation, such as some visitors returning because they lacked a document. An assumption is an untested explanation: perhaps people do not read the confirmation message. A solution is a proposed change, such as adding a checklist to that message. If the team writes the solution in the need field, it loses a way to judge success independently of the chosen feature. Record a symptom in a checkable form, distinguish its source from an interpretation, and write the decision the evidence is meant to inform. One staff member's account does not establish a rate for every visitor.

The service boundary starts before the screen and ends after a request is submitted. The UK Government Digital Service distinguishes a team's transaction from the user's wider problem and recommends mapping the journey with the organizations that help deliver it. In a training example, the appointment journey begins when a person realizes a document is needed, continues through checking requirements, booking, preparing papers, arriving, and receiving an outcome or an explanation for delay. The team's authority may cover booking and guidance only. Its map should still show dependencies on document verification and reception. Mark what the team controls, where cooperation is required, and what lies outside its mandate. These boundaries keep the team from promising a seamless experience it has no means to deliver.

Write a problem statement that does not smuggle in its answer: “A visitor booking a document appointment needs to know the visit requirements before travelling, because some visits are repeated after a document is missing. We will find where that information gets lost and test a way to improve readiness.” Do not write “the visitor needs an intelligent app.” That wording forecloses alternatives such as a better requirements page, a clearer confirmation, or a changed reception process. A useful statement names a person, task, obstacle, context, and limit of knowledge. Turn it into a decision question: Does the guidance gap recur across booking channels? Is the missing document linked to the message, the interpretation of a term, or a rule change that did not reach the digital channel? Collect only data needed for those questions.

Discovery does not mean endless research. Make a three-column ledger: evidence held, assumption to test, and a small step that could change the decision. The visit log is evidence about visits, not the entire experience. A message copy is evidence about what was displayed, not what readers understood. An interview explains a participant's account, not the whole population. If interviews and message review support a guidance gap, test clearer instructions before building a new interface. If messages prove complete but office requirements change without being passed to the booking channel, redesign the requirement update handoff. The same visible complaint can demand a different intervention; that is why problem framing follows evidence.