Working Framework
What it is
A diagnostic language for naming service conditions precisely — reading what kind of problem a service has, rather than calling it “confusing,” “fragmented,” or “broken.”
The problem it addresses
Most service diagnosis collapses into loose vocabulary. A journey is “disjointed,” a flow “needs simplifying,” a touchpoint is “a pain point.” These words feel like analysis but carry almost no diagnostic weight — they describe a feeling of wrongness without naming its kind, and two very different failures end up with the same label. When the diagnosis is vague, the response is vague: teams redesign the whole journey in broad terms instead of fixing the specific condition that’s actually failing.
Blueprint Grammar exists to make the naming precise enough to act on. It gives a bounded set of conditions — singles and pairs — so that “the repair journey is confusing” becomes “a transfer failure between triage and the contractor, with repeated effort on the tenant’s side.” The second reading tells you where to look and what to fix. The first doesn’t.
When to use it
Use it when you already have something to read and the remaining problem is interpretation — you can see something is wrong but can’t yet say what kind of condition it is.
- Service journeys with repeated hand-offs, where the person keeps carrying continuity themselves.
- Flows where prerequisites stay hidden until too late — eligibility, documents, approval, or another actor required all along.
- Support-heavy experiences, where staff repeatedly step in to recover, explain, or manually carry people through.
- Cross-touchpoint situations, where effort reappears as people move between channels and rebuild progress.
- Workshops where friction is visible but the conversation collapses into “pain point” or “confusion.”
If the main gap is evidence, the next step is research, not the grammar. If the main gap is naming what the evidence already shows, the grammar becomes useful.
How it works: the grammar
The grammar has two layers. Singles name one condition when it explains most of what’s going wrong. Pairs name two conditions working together when a single term would be too blunt. A reading uses at most three conditions — the discipline is to resist naming everything.
Each condition below carries a usage rule (“use this when…”) and the mistake it’s most often confused with. The confusion note is the evidentiary gate: it tells you what the condition is not, so the name isn’t applied loosely.
Singles
Indirect access — a service says access is available, but the person still needs another person, permission, or a hidden step to get through. Use when entry depends on help, approval, or a condition the service doesn’t show up front. Often mistaken for poor wording — but the issue is hidden mediation, not explanation.
Threshold — the hard part is getting over the line into the next step. Use when the key question is entry: what must happen before a person can move forward. Often mistaken for general onboarding trouble — but the pressure sits at the crossing itself.
Route — the service only works if the person can keep track of the sequence. Use when the problem lives in the path between steps, not one screen or form. Often mistaken for one broken touchpoint — but the issue is the sequence as a whole.
Dependency — the visible service depends on hidden work elsewhere. Use when the person-facing experience relies on another team, queue, or system they can’t see. Often mistaken for delay or staff error — but the real issue is the hidden support work the service depends on.
Exchange — the service depends on something important being handed over well. Use when information, trust, responsibility, or case state has to pass between people or teams. Often mistaken for bad content — but the failure is in the handover.
Interruption — the process breaks and the service doesn’t help the person recover. Use when a pause or break leaves people unsure how to restart. Often mistaken for a one-off disruption — but the issue is weak recovery.
Repeated effort — the same small piece of work keeps coming back. Use when re-entry, restating, or chasing becomes part of the service burden. Often mistaken for a minor nuisance — but the repetition has become structural.
Return — coming back is part of how the service really works. Use when retrying or looping back is normal rather than exceptional. Often mistaken for failure to get it right first time — but the service actually runs in cycles.
Three further singles are provisional — published but still under review:
Directed effort (provisional) — progress is possible only if someone pushes far harder than the task should require. Under review to confirm it’s a distinct condition rather than a consequence of another failure.
Ambiguity (provisional) — a person can continue but still can’t tell what the situation means. Under review to keep it from becoming a loose container for every unclear moment.
Shelter (provisional) — the service needs to give pause or reassurance before movement can restart. Under review to clarify when shelter is primary rather than better read through a pair.
Pairs
Indirect access + Threshold — access looks open, but the real gate is hidden (permission, proof, or reassurance surfacing only at the crossing).
Route + Interruption — the path exists, but breaks in it are hard to recover from.
Dependency + Exchange — the experience depends on hidden coordination and a handover that isn’t holding. Both are needed: the hidden dependency and the failed transfer.
Two pairs are provisional: Shelter + Return (safe pause and re-entry together, after a setback) and Route + Shelter (a path that only works if it contains places to pause and regroup).
A worked reading
Situation. A resident — John — finds a sticker on his recycling bin telling him it won’t be collected. He follows the online replacement process: registers an account, verifies his email, expects to pay, and is surprised to find replacements are free. He then receives a confirmation email from a no-reply address that tells him, in the language of compliance, what won’t happen if he fails to leave the old bin out correctly. A crew placed the sticker; a separate process makes John re-request what the crew already identified; a crew is then sent again to deliver the replacement.
Usual reading. The sticker is talked-down-to in tone, the email is unfriendly, the process is laborious. Fix the copy and simplify the form.
Grammar reading. The clearest reading is Dependency + Exchange. The resident-facing process only exists because two functions that already share the case — the collection crew who identified the broken bin, and the council system that holds John’s account and address — were never connected. The crew know the bin is broken; the service makes John re-enter that knowledge from scratch. Repeated effort runs throughout: John supplies information the institution already holds. Route matters too — the case passes crew → sticker → resident → online form → crew again, and no single actor carries continuity. John carries it himself.
What the grammar clarifies. It separates a tone problem from a structural one. The unfriendly email isn’t a copywriting failure — it’s a symptom of a workflow in which the resident is the connective tissue between disconnected functions. Naming the condition as Dependency + Exchange moves the diagnosis from “rewrite the sticker” to “why is John in this loop at all?” The repeated-effort reading shows the labour isn’t incidental friction; it’s built into a process that never used what the council already knew.
Why it matters. The precise reading changes the next move entirely. A tone reading produces a kinder sticker. The Dependency + Exchange reading asks whether the crew who place the sticker could carry a replacement and swap it on the spot — dissolving the resident-facing process rather than improving it. One is a better solution; the other questions why the solution takes this form. The grammar is what makes the second question sayable.
What remains uncertain. The material is one resident’s account, not the service’s operating data. It doesn’t show whether this path is typical or an edge case; whether the crew-to-swap model is blocked by cost, legacy systems, or organisational silo rather than oversight; or whether the disconnect sits in one hand-off or across the whole waste service. The reading is a bounded interpretation of one public post — a strong hypothesis about organisational fragmentation, not proof of it.
What it doesn’t do
- It’s not a replacement for research. It works once there’s something to read; it doesn’t substitute for gathering evidence.
- It’s not a journey-map format. It’s a diagnostic language, not a way to document every service.
- It’s not a workshop gimmick. It sharpens interpretation; it doesn’t relabel every sticky note.
- It’s not an answer machine. It narrows readings; it doesn’t remove the need for evidence, reasoning, and editorial restraint.
- It’s not for problems working as designed against the user. Deliberate cancellation friction, dark patterns, and manufactured obstacles are not service conditions to diagnose — they are governance and ethics problems. Reading intentional adversarial design as “Threshold” or “Repeated effort” sanitises a business decision as a design defect. When a service is failing the user on purpose, the grammar’s job is to hand the problem off, not absorb it.