Turn a solution request into a decision question

An adviser may receive a commission that already names the answer: “Build a new app to remove appointment queues.” That describes a presumed means, not the decision the service owner needs to make. Design thinking starts by understanding people and their circumstances before fixing a solution. Movement through discovery, definition, development and testing is a map for learning, not a ceremonial sequence of approvals. Ask who struggles, at which step, through which channel, with what observable consequence, and who can authorize a service change. If the counter queue is driven by unclear document requirements, another app may increase transfers to support. If paper requests complete smoothly while booking alone fails, a booking change becomes plausible. The complaint headline does not establish the cause.

A short engagement charter protects the diagnosis. It states the decision due at the end of a defined phase, the service boundaries and channels in scope, whose experience will be heard, permissible data, time and resource constraints, and who will accept risk. A useful decision question is: “Which change to the appointment journey reduces avoidable repeat visits while preserving access for people who do not use the digital channel?” This leaves room to compare clearer instructions, simpler booking and staff allocation. “How should we build the app?” excludes the possibility of not building it before evidence is gathered. Define an exit criterion for discovery: enough evidence to locate major breakdowns and test at least one rival explanation, rather than an arbitrary interview count.

Separate observations, interpretations and tests in the charter’s evidence ledger. “Counter visits increased over two weeks” is an observation if records are reliable; “the website caused it” requires a trace linking visits to failed online attempts. Three interviews can uncover possibilities but cannot estimate a population rate. Analytics may reveal abandoned sessions but cannot by themselves explain whether people prefer attendance or misunderstood requirements. Pair different evidence types where the decision matters: a behavioral trace across the journey and an appropriate interview or observation to interpret it. Conflicting findings should remain visible. Write a question that discriminates between two explanations and specify what result would alter the recommendation.

Define the adviser’s role as producing a challengeable recommendation, not automatic authority to change operations or collect every customer record. The decision owner approves research and testing scope and risk boundaries; operations checks delivery capacity; participants understand why they take part and how data will be used. If research reveals a legal, security or other specialist judgment, record and refer it before proposing a definitive treatment. The charter should also say what is outside its evidence: a final causal impact estimate, a guaranteed business outcome, or unresearched user groups. At phase end the team should be able to ask which decision is now possible and which unknown still blocks it.