The room is ready before the inquiry is.
The journey has a name. The problem statement is already on the wall. Service has the case history. Product has the defect timeline. Analytics has a heatmap. Marketing has an offer waiting for a decision.
Everyone has brought something useful.
Then someone reads the brief: “Digital friction is causing relationship decline.”
The brief already contains the answer.
Before anyone designs a solution, the brief needs four things kept apart: what we know, what we infer, what we need to learn, and the smallest useful probe.
What the bank saw—and what the brief added
Consider a hypothetical continuation of the case from my previous article on the Relationship Ledger: a single retail customer under review.
The customer’s activity inside the bank appears strong. Recent feedback describes high effort and poor resolution, which supports an unfavorable assessment of Relationship Health—the experience the customer appears to be having with the institution. Service records show a recurring digital failure. Marketing has a growth offer queued.
A named owner authorizes repair and pauses the offer. The ledger records what the bank saw, what it believed, what it decided, and what it would revisit.
The defect is repaired. During the review window, observed behavior stays roughly unchanged.
That is a condition worth investigating. It is not yet an explanation.
The workshop brief adds two claims the evidence has not established: that the relationship is declining, and that digital friction caused the decline. An unfavorable assessment is a snapshot, not a trend. Unchanged activity after a repair says nothing about why the experience was poor.
Each function has a legitimate record. The brief has turned those records into a shared story.
That is the collapse: an observation and an interpretation arrive in the room wearing the same label.
A written explanation acquires momentum
Richards J. Heuer Jr. described a related problem in Psychology of Intelligence Analysis. Under pressure to explain events quickly, analysts can commit to an assessment before adequate information is available. Later evidence is then fitted into the original interpretation. Once the assessment is written down, organizational pressure makes it harder to revise. [1]
Heuer was writing about intelligence analysis. The banking application is mine: a circulated brief can give a tentative explanation the authority of an agreed starting point. The meeting needs a purpose, the project needs a scope, and the explanation gets harder to question once work is organized around it.
Design thinking is supposed to resist that move. The Design Council describes the first diamond of its Double Diamond as helping people “understand, rather than simply assume, what the problem is,” and notes that learning about the underlying problem can send a team back to the beginning. [2]
This is not a missing stage in design thinking. It is a failure to let discovery change the brief. When the team is invited only to solve an approved problem, inquiry arrives too late to shape the approval. The fix is reopening the brief, not adding another workshop.
One page before the workshop
Add the four fields to the existing brief or research plan; no separate template is needed. Under Know, attach each source, date, measure, and observation window, and keep customer wording separate from staff summaries. The same applies when an AI model drafts the summary: a fluent synthesis of case notes is an interpretation, and it belongs under Infer until someone checks it against the records.
Know
Service records document the failure; product checks confirm the repair. Recent customer feedback reports high effort and poor resolution. In-bank activity shows little change across the stated comparison periods. Nothing in these records shows a downward relationship trend.
Infer
The feedback supports an unfavorable Relationship Health assessment. The digital failure explains that experience. Repair should have changed financial behavior. A simpler digital journey would improve the relationship.
Only the assessment rests on evidence—reported experience. The rest is untested. If the evidence is too sparse, stale, or contradictory to support an assessment, the status is insufficient evidence—not poor Relationship Health.
Need to learn
What did the customer actually report? If the brief says “low trust,” is that the customer’s language or the bank’s interpretation? Did later contacts concern the original failure, the recovery, or something else? What would strengthen or weaken each explanation?
Imagine three customers given the same “low trust” label: one questions an unexpected fee, another doubts transaction reliability, and a third is unsure help will be available. Those are different concerns to investigate, not interchangeable reasons for the same treatment. Age alone would not tell us which concern applies.
Smallest useful probe
First, reconstruct the service sequence: the initial failure, repair confirmation, later contacts, and any customer feedback. Check whether the unresolved issue in those records is the issue the workshop proposes to solve. This is a first check, not a substitute for discovery with customers; internal records preserve the bank’s interpretation and omit what it never captured.
Suppose the records confirm the repair, while later customer messages describe an unanswered request about the recovery. That supports a narrower statement: the customer reports an unresolved recovery communication issue. It does not establish what explains the customer’s whole relationship with the bank.
Now the brief can change. The next question is what response was owed, whether it reached the customer, and what remains unresolved. An app-redesign workshop no longer follows automatically.
If the record is incomplete, the checkpoint names the missing evidence and how to get it.
Make the first pass small enough to run
For this example, the existing decision owner commissions a named CX research lead as inquiry owner. One person may revise the question; another may act on it. Service brings the contact history, product confirms the repair, and the analyst responsible for the activity measure checks its definition and comparison window.
I would budget 45–90 minutes for the discussion, with preparation identified separately. Treat the time as a starting estimate, not a tested benchmark.
The first meeting ends with the four fields populated—explicit unknowns included—a record check assigned, and a review date. In this illustration, the service lead assembles the chronology and the inquiry owner reviews it within two working days, provided the records are accessible. If they are not, the output names the access gap and who will close it.
Then choose the next method. If the open question concerns the customer’s meaning or experience, ask the customer—before offering the bank’s explanation. Use authorized records and appropriate research permissions, and do not delay service the customer is already owed. If the question expands beyond this relationship, say so, and include contrasting cases that could challenge the explanation, not only similar complaints.
The useful first output is a question the evidence can support, with someone responsible for learning more.
A better question still needs permission to stay open
A “How Might We” question can be specific and still be legitimate. IDEO.org’s guidance starts from insights and asks for a frame that permits multiple possible solutions. [3]
Reducing a verified digital difficulty can therefore be a reasonable design challenge. The problem is treating that difficulty as the established cause of relationship weakness.
Rewriting the sentence will not fix a team that is allowed to explore only one answer. The brief must stay revisable when the inquiry challenges it.
That does not mean all action waits for causal certainty. A verified defect can be repaired on its own merits; an unanswered request can get a response. A broader intervention needs evidence and permission proportionate to its risk, reach, and reversibility. A bounded test can be justified under uncertainty if its safeguards, learning question, and stopping conditions are explicit.
The existence of an inference does not authorize that intervention. Neither does the mere completion of a probe.
Preserve the decision. Keep examining the explanation.
The example is hypothetical. It shows how the inquiry could be organized, not that the approach has improved outcomes in practice.
One page cannot create missing evidence or make uncertainty welcome in an organization that punishes it. If nobody can revise the brief, the page becomes another record of a decision already made.
The previous article asked whether the bank could reconstruct its judgment. This one asks whether the explanation inside that judgment was earned—and remains open to correction. Inquiry is the step that protects the question before anyone acts on the answer.
Service blueprinting can trace the actors, systems, policies, and handoffs behind the problem—and expose evidence that sends the inquiry back. That is the next article’s work.
The room can be ready before the inquiry is. The brief must still be open to change.
SOURCE LAYER
Provenance & references
- Richards J. Heuer, Jr. — Psychology of Intelligence Analysis (CIA Center for the Study of Intelligence, 1999), Chapter 2, printed pp. 15–16 ↗ — Institutional analogy; not a banking study or validation of the proposed inquiry page.
- Design Council — The Double Diamond (Discover; “Evolving with the Framework for Innovation”) ↗ — Official description of the design process. Quote “understand, rather than simply assume, what the problem is” verified word for word on 2026-10-11.
- IDEO.org — Design Kit: How Might We (method description and steps 1–4) ↗ — Guidance on framing design questions from insights.