The Happy Path Hides Assisted and Interrupted Users

What the journey problem looks like and why it affects the business

The cleanest journey is often the least representative one. A happy-path map removes interruptions, access needs, support, retries and non-completion, the conditions that frequently create cost, harm and lost value.

Add route coverage based on material conditions and failure evidence, then design acceptance and recovery tests for more than the uninterrupted digital path.

This guide is for service owners, product leads or customer-experience leads. Budget approval sits with the leader accountable for exclusion, abandonment, support cost or unequal outcome risk.

The named owner holds decision authority; specialists contribute evidence within their remit, but contribution does not replace accountable ownership.

Check which routes matter to this journey decision, including assisted and interrupted users. This guide does not create personas or establish population-wide prevalence.

Agree the user outcome, evidence and decision authority before choosing an intervention. Technology or AI cannot replace that work.

What to expect in the working pack

Use the working pack as you follow the guide. Start with the charter, assign stable evidence IDs and update the decision and review fields at each checkpoint. Its entries need supporting sources; the workbook alone is not evidence:

• Start here: Read the decision sequence, evidence labels, required inputs and stop conditions before changing the map.
• Journey charter: Record the user outcome, start, end, included routes, material exclusions, consequence and authority.
• Journey map: Connect stages to user tasks, context, channels, systems, handoffs, owners and unresolved questions.
• Evidence register: Separate observed facts and participant statements from interpretations, inferences and unknowns.
• Friction and failure log: Record symptoms, affected routes, severity, recurrence, consequences and competing explanations.
• Intervention and acceptance: Link each proposed change to an owner, dependency, test, guardrail, rollback and human decision.
• Outcome and recovery: Observe task and value outcomes alongside assistance, recovery, exceptions and harm checks.
• Review and change log: Govern versions, evidence changes, approvals, reopen triggers, replacement and retirement.

Use the same evidence, issue and intervention IDs across sheets so a reviewer can move from a claim to its source, consequence, proposed change and decision. The guide-specific seed rows show the minimum structure; replace them with authorised organisation-specific evidence.

Do not enter participant names, contact details, recordings, free-text case notes or unnecessary personal information in the workbook. Store sensitive evidence in an approved controlled repository and enter only a permitted reference. The workbook does not create consent or lawful authority.

What evidence distinguishes the real cause

The visible symptom does not establish the cause. Build one dated evidence set before redrawing the journey, commissioning technology or approving an intervention.

Label every material statement. Use VERIFIED only where a current, attributable source supports the statement and its permitted use. Use OBSERVED for a behaviour, event or participant statement without turning it into a population claim. Use INFERRED where evidence supports but does not prove the explanation. Use PROPOSED for a future design or decision. Use UNKNOWN where evidence is missing. Use REQUIRES VALIDATION where the claim must be tested before it may govern investment or public copy.

Three competing explanations deserve deliberate testing: Successful digital users dominate current evidence. Interruptions cause lost progress or repeated entry. Assisted routes carry hidden cost and accessibility failures. Record contrary cases as carefully as confirming cases. A diagram, analytics trend or stakeholder consensus can indicate where to investigate, but none proves why the condition exists.

The research standard should cover the end-to-end experience and the routes people actually use. GOV.UK Service Manual: Researching user experiences provides the general research frame, while GOV.UK Service Standard: Make sure everyone can use the service helps bound the whole problem rather than only the organisation's visible touchpoint. Where the journey crosses channels or teams, preserve those interfaces instead of hiding them inside a single stage.

Accessibility is part of journey evidence and acceptance, not a final compliance check. The Web Content Accessibility Guidelines 2.2 include requirements relevant to complete processes, interruptions, redundant entry, errors and accessible authentication. Test with disabled users and people who need support where the decision may affect them. Do not claim universal access from an automated check alone.

Personal information must be handled under the organisation's approved privacy and research process. The Protection of Personal Information Act (POPIA) is the primary South African statutory source. This guide is not legal advice; the Information Officer or qualified adviser retains legal authority. Record purpose, permitted use, access, retention and deletion arrangements before collecting identifiable evidence.

Stop and re-charter if the decision is unnamed, the population cannot be bounded, the evidence cannot be used lawfully, assisted or excluded users cannot be represented, the owner lacks authority, or the proposed work crosses the scope boundary. Record UNKNOWN when evidence is missing.

How to fix it step by step

Step 1: Define the journey decision

Open Start here and Journey charter. Write the decision as a choice an authorised person must make, not as an aspiration such as “improve experience.” Add the economic consequence, decision date and owner. Then write the user outcome in observable terms: what will the user be able to do, under which conditions, and how will completion be recognised?

Do not move on if stakeholders use different outcomes. Record each competing definition in the Evidence register, identify its source and mark it INFERRED or REQUIRES VALIDATION until an authorised owner resolves it. This prevents the map from manufacturing consensus.

Step 2: Collect and label the evidence

Create evidence IDs before interpretation. For each source, record date, population, context, limitation, confidence and permitted use in Evidence register. Link interviews, observation, analytics, search, CRM, support and operating evidence through controlled references. Do not paste sensitive raw data into the workbook.

Collect unsuccessful, assisted, interrupted and contrary cases as well as successful ones. If the available sample contains only people who completed through the easiest route, record that limitation. It may still support a local observation, but it cannot support a universal journey claim.

Step 3: Set the population, routes and observation window

Use Journey charter to set a start condition, end condition, included population and routes, material exclusions and the point at which the decision stops. Use conditions, not channel names: “the user recognises a need” is a condition; “visits the website” is one possible route.

In Journey map, give every retained stage an observable entry and exit. A stage should represent a change in user state, value, risk or decision, not every click, message or internal action. Keep channels and systems in their own columns. Record exclusions visibly so a neat map cannot imply unsupported completeness.

Step 4: Map tasks, handoffs and possible causes

Map user tasks in Journey map first. Then add context, channels, systems, handoffs and owners. Where internal activity enables or blocks the user, show the interface without replacing the user's task with an internal status. Link each material transition to evidence IDs.

In Friction and failure log, describe the symptom without assuming the cause. Record affected route, severity, recurrence, possible consequence and at least one competing explanation. A high-friction step may be caused by missing information, an eligibility rule, an inaccessible interaction, an ownership gap or an upstream promise; the map should keep those possibilities open until evidence distinguishes them.

Step 5: Check the business consequences and competing causes

Connect the issue to something the business can decide. Quantify revenue, cost, delay, risk, retention or service-demand exposure only where a defensible source exists. Otherwise describe the consequence and mark its size UNKNOWN or REQUIRES VALIDATION. Never invent a saving, conversion uplift or affected population.

Use the Friction and failure log to compare explanations. Ask what evidence would disconfirm the preferred cause. If the issue falls mainly inside a wider operating, persona, analytics or acquisition problem, follow the boundary link rather than stretching this guide into a full transformation audit.

Step 6: Name owners, escalation and recovery routes

In Intervention and acceptance, name one accountable owner, necessary contributors, dependencies and decision authority. A functional contributor is not automatically the journey owner. The six value paths cross functional budgets, evidence and ownership; diagnosis therefore needs cross-functional authority, access and independent challenge, whether led internally or externally.

Specify receiving acceptance for handoffs and escalation for exceptions. Record a rollback route before implementation. If the owner cannot pause, reject or reverse the change, escalate the authority gap instead of recording a false owner.

Step 7: Agree acceptance, guardrails and rollback tests

Write the acceptance test before implementing the change. For this guide, the minimum condition is: The decision map includes all evidenced material routes, records known exclusions and unknown prevalence, and tests completion, interruption, assistance and recovery without reducing them to one average path. Add guardrails for accessibility, privacy, service demand, quality and excluded routes where material.

For this discovery decision, make the trade-off explicit between current route coverage and interruption and return: state who gains, who bears additional effort or risk, which guardrail protects affected routes, and what evidence would make the owner pause, adapt or reverse. Record it in Intervention and acceptance and verify it in Outcome and recovery; a local improvement is not a success if it shifts burden to an assisted, interrupted or excluded route.

Use Outcome and recovery to define the observation window, support route, recovery route, exception and harm check. Test the negative case explicitly: The redesigned happy path is faster for unaided users, while users who pause or need assistance lose progress and create more support demand. A local improvement fails acceptance when it damages the wider outcome or hides who was unable to progress.

Step 8: Record the decision and review triggers

Record the human decision in Intervention and acceptance and the version in Review and change log. State whether to proceed, adapt, pause, stop or commission deeper diagnosis. Include approver, effective date, next review, evidence change and the trigger that would reopen or retire the decision.

Do not convert PROPOSED work into VERIFIED evidence merely because it was approved. Approval authorises action; observation supplies outcome evidence. Keep those states separate through implementation and review.

Worked example

A hypothetical application service maps a ten-minute online completion. Support evidence reveals users who pause for documents, share a device or need an adviser. The revised decision retains progress, removes unnecessary re-entry and records assisted completion separately.

This is a hypothetical teaching example, not an Abrasim client result and not evidence of a guaranteed outcome. Its purpose is to show the decision structure: identify the user outcome, preserve competing explanations, assign authority, test the change across the journey and record what would reverse the decision.

How to verify the journey change

Verification asks whether the decision changed the user outcome under the stated conditions, not whether the map was completed. Review the workbook as one connected evidence chain:

1. Recheck the population, routes, start, end and exclusions in Journey charter.
2. Sample evidence IDs from Journey map back to the Evidence register and controlled sources.
3. Confirm that high-severity items in Friction and failure log have an owner and disposition.
4. Execute the acceptance, guardrail, negative-case and rollback tests in Intervention and acceptance.
5. Observe task outcome, first value, assistance, recovery, exceptions and harm in Outcome and recovery for the agreed window.
6. Record contrary evidence and unresolved limitations rather than averaging them away.
7. Ask the authorised owner to decide proceed, adapt, pause, stop or investigate.
8. Record the decision, evidence change and reopen trigger in Review and change log.

Use evidence appropriate to the decision. Behavioural observation can show where people struggle; operational records can show delay and recurrence; analytics can show patterns within its collection limits; participant accounts can explain context; commercial records can show qualified value. Reconcile them instead of treating one source as complete.

Verification is incomplete when only the easiest route was tested, personal data was used outside permitted purpose, accessibility was checked only by automation, a downstream team was not involved, or the outcome window ends before value or recovery can be observed.

Use this evidence with AI safely

AI can help organise authorised evidence, identify contradictions and draft questions. It must not invent missing user evidence, infer sensitive attributes, make the final decision or receive personal or confidential data outside an approved environment. Remove or replace identifiers and use controlled references.

Copy and adapt this prompt:

Role: Journey evidence reviewer. Decision: Add assisted, interrupted and non-completing routes to the decision boundary. Scope: Material journey-route coverage for one decision; not persona creation or demographic completeness for its own sake. Evidence questions: E01: What evidence establishes current route coverage | E02: What evidence establishes assisted completion | E03: What evidence establishes interruption and return | E04: What evidence establishes non-start and non-completion | E05: What evidence establishes access conditions. Competing explanations: Successful digital users dominate current evidence | Interruptions cause lost progress or repeated entry | Assisted routes carry hidden cost and accessibility failures. Acceptance and guardrails: The decision map includes all evidenced material routes, records known exclusions and unknown prevalence, and tests completion, interruption, assistance and recovery without reducing them to one average path. Use only authorised, minimised summaries with evidence IDs and labels. Separate VERIFIED, OBSERVED, INFERRED, PROPOSED, UNKNOWN and REQUIRES VALIDATION; cite the supplied ID for every material statement. Identify contradictions, missing routes, unsupported causal claims and the smallest next test. Do not invent users, prevalence, outcomes or legal conclusions. Return an evidence table, risks, questions, decision options and human approvals required.

Review the output against source records. If it cannot cite the supplied evidence ID for a statement, treat that statement as REQUIRES VALIDATION. Human owners retain responsibility for research, privacy, accessibility, commercial and operational decisions.

How to keep the problem from returning

Use three standing controls:

• Include interrupted and assisted cases in every review.
• Treat successful completion as one route, not the default user.
• Track recovery and support outcomes alongside task completion.

Review the journey after a material offer, channel, system, policy, operating-model or population change; after recurring exceptions; when evidence becomes stale; or when the acceptance result changes. Do not update the diagram silently. Update the evidence, decision and change log together.

Assign a review owner even when the map is maintained by several teams. The owner does not need to produce every input, but must be able to convene contributors, access evidence, preserve dissent and obtain an authorised decision. If that authority does not exist, record the governance constraint openly.

Continue with the preceding guide when earlier boundary work is unresolved, then use the next guide when that is the next question you need to answer. Use research sample excludes important users when the adjacent problem owns the wider diagnosis: The persona guide repairs who is represented in research; this guide repairs which journey routes are represented.

If the issue crosses teams, budgets, systems or evidence sources and cannot be resolved safely within the guide, Assess the journey coverage and ownership gap. An assessment should first agree the decision, evidence access and authority. Technology choices follow the findings.

Primary sources used

Source cutoff: 2 September 2026. Review by 2 March 2027, or sooner after a material change. These dates apply to the external references below; local organisational evidence still needs its own date and limitation.

• GOV.UK Service Manual: Researching user experiences
• GOV.UK Service Standard: Make sure everyone can use the service
• GOV.UK Service Standard: Provide a joined-up experience across channels
• W3C Web Content Accessibility Guidelines (WCAG) 2.2
• South African Government: Protection of Personal Information Act