User Journey Diagnostics¶
Diagnostic trace — instantiates Mental Model Mismatch Repair
Traces a whole sequence of touchpoints to find where a wrong expectation accretes, mapping the assumptions that build up when no single screen or message created the mismatch alone.
User Journey Diagnostics is the mechanism for a mismatch that no single screen produced. It follows a person across an entire sequence of touchpoints — forms, emails, status pages, phone calls, waiting periods — and finds where a wrong expectation accretes, assembling the map of assumptions the person picked up along the way. Its defining move is that it looks at the path, not the moment: it assumes the false belief was built incrementally, each step contributing a plausible-but-partial cue, so that the mismatch lives in the sum of the journey rather than in any one interaction. Where a single-screen test would find each touchpoint blameless, this diagnostic finds the compounding — the place where reasonable local reads add up to a wrong global model.
Example¶
A claimant files an auto-insurance claim online and comes away certain the claim is approved and paying out, when in fact only the first notice of loss was received. No single touchpoint lied. The intake form ends with "Your claim has been submitted!" (true). A confirmation email carries a claim number and the phrase "we're on it" (reassuring). The status page shows a green Received badge and a progress bar already one-third filled (encouraging). A text says "An adjuster will be in touch" (routine). User Journey Diagnostics walks the whole sequence and maps the assumptions each step seeds: submitted = accepted, claim number = active payout, green + progress bar = approved, adjuster assigned = decision made. The diagnosis is that the mismatch is a stacking effect — four cues each innocuous, jointly manufacturing "approved" — with the assumption map showing exactly which reads compound. It hands that map to repair; it does not decide whether to fix the badge, the copy, or the sequence.
How it works¶
- Bound the journey. Define the path end to end — every screen, message, and wait between the trigger and the point where the wrong expectation surfaces.
- Reconstruct the model at each step. For each touchpoint, ask what a reasonable person would now believe, given everything so far.
- Map the accreting assumptions. Record how each step's plausible local read adds to a running model, and where the running model first diverges from reality.
- Corroborate across sources. Check the reconstructed reads against real user reports, support-contact themes, and drop-off data, so the map reflects what people actually infer, not what a designer imagines.
Tuning parameters¶
- Journey breadth — a single funnel or every channel (web, email, phone, mail). Wider breadth catches cross-channel stacking but multiplies the touchpoints to trace.
- Reconstruction grain — one belief per major step, or a fine-grained read of every cue. Finer grain locates the exact accretion point at higher effort.
- Corroboration strength — reconstruct from the artifacts alone, or triangulate against real user reports and analytics. Stronger corroboration resists a designer's just-so story.
- Attribution stance — whether the map merely lists contributing steps or estimates how much each one adds to the wrong model, which prioritizes the repair.
When it helps, and when it misleads¶
Its strength is that it catches the distributed mismatch — the one where every touchpoint passes its own review yet the journey as a whole teaches a false model. Formalizing the path as a service blueprint[1] is what makes the accretion visible and the compounding legible.
Its failure mode is a plausible narrative unbacked by evidence: a diagnostician can walk any journey and construct a story of accreting assumptions that no real user actually formed, which is why the map must be corroborated against genuine user reports rather than imagined reads. Its classic misuse is scope creep — mapping the entire product experience when the mismatch lives in three steps — which buries the diagnosis in a beautiful, unactionable atlas. The guarding discipline is to bound the journey to the stretch that produces the observed wrong expectation, and to corroborate every accreting assumption against real behavior before trusting it.
How it implements the components¶
mismatch_diagnosis— explains the gap as a stacking effect across touchpoints, naming the point where reasonable local reads first compound into a wrong global model.assumption_map— its signature output: the running list of assumptions each step seeds and how they accumulate into the false belief.evidence_check— corroborates the reconstructed reads against real user reports, support themes, and drop-off data, so the map reflects what people actually infer.
It maps where a wrong expectation accretes but does not reconstruct one operator's in-the-moment belief during a single discrete failure (expected_behavior) — that is its near-twin Incident Mental-Model Review — nor stage a controlled observation of the live system (actual_behavior, Usability Testing). It diagnoses; it does not perform the repair (correction_locus_decision, model_revision_path).
Related¶
- Instantiates: Mental Model Mismatch Repair — User Journey Diagnostics supplies the cross-touchpoint assumption map the repair acts on.
- Sibling mechanisms: Usability Testing · Incident Mental-Model Review · Interface Affordance Redesign · Documentation Revision · Simulation-Based Correction · Training Feedback Loop · Expectation Audit
Editorial Notes¶
Form Classification¶
Form family: Analysis, Modeling & Optimization
Rationale: User Journey Diagnostics operates as an analytical, modeling, inference, comparison, or optimization procedure that derives insight or a solution because it traces a whole sequence of touchpoints to find where a wrong expectation accretes, mapping the assumptions that build up when no single screen or message created the mismatch alone.
Independent corroboration: The frozen evidence defines User Journey Diagnostics as 'Traces a whole sequence of touchpoints to find where a wrong expectation accretes, mapping the assumptions that build up when no single screen or message created the mismatch alone', so its operative form is Analysis, Modeling & Optimization.
Nearest alternative: Representation, Specification & Plan — User Journey Diagnostics includes features of a static representation, map, specification, schema, or prospective plan that externalizes information, but its defining operation is an analytical, modeling, inference, comparison, or optimization procedure that derives insight or a solution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Both independent reviews identify human computer interaction as the historical home of the operation—Traces a whole sequence of touchpoints to find where a wrong expectation accretes, mapping the assumptions that build up when no single screen or message created the mismatch alone.. The retained alternates document formative adjacent traditions; the reach field, not the origin field, carries later applicability.
Related originating lineages:
- Communication & Media Studies — Communication and media research supplies a parallel or contributing lineage for the mechanism's defining operation: traces a whole sequence of touchpoints to find where a wrong expectation accretes, mapping the assumptions that build up when no single screen or message created the mismatch alone.
- Computer Science & Software Engineering — Computer science and software-engineering practice supplies a parallel or contributing lineage for the mechanism's defining operation: traces a whole sequence of touchpoints to find where a wrong expectation accretes, mapping the assumptions that build up when no single screen or message created the mismatch alone.
- Organizational & Management Science — Organizational design, management, and operational governance supplies a parallel or contributing lineage for the mechanism's defining operation: traces a whole sequence of touchpoints to find where a wrong expectation accretes, mapping the assumptions that build up when no single screen or message created the mismatch alone.
- Psychology — Psychology's perception, cognition, behavior, and risk-communication tradition contributes a separate formative lineage to the mechanism's user journey diagnostics logic.
Review resolution: Both blind reviewers independently place the defining operation—Traces a whole sequence of touchpoints to find where a wrong expectation accretes, mapping the assumptions that build up when no single screen or message created the mismatch alone.—in human computer interaction. Their queued differences are secondary: alternate_origin_disagreement, origin_mode_disagreement, encyclopedia_synthesis_disagreement. Reviewer A uniquely contributes ['psychology']; reviewer B uniquely contributes ['communication_media_studies', 'computer_science', 'organizational_management']. I preserve the full evidence-supported union of 4 alternate domain(s), without a numeric cap. origin_mode=single_lineage reflects the more specific lineage judgment in reviewer B's evidence, while domain_reach=universal separately records present-day portability. The affirmative encyclopedia-synthesis finding is preserved, and confidence=high uses the more conservative reviewer level.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Its nearest twin is Incident Mental-Model Review: both diagnose a mismatch from evidence rather than staging a fresh test. The clean separation is event versus path — the incident review root-causes one discrete failure that already happened; this diagnostic maps the assumptions that quietly accumulate across a routine journey where nothing "failed" at all. If there is a single culprit interaction, that is an incident; if the culprit is the sequence, it is a journey.
References¶
[1] Shostack, G. L. "Designing Services That Deliver". Harvard Business Review 62(1), 133–139 (1984). Presents service blueprinting as an explicit visual description of a service process that exposes its stages and potential failure points. registry ↩