Journey Mapping: Find the Waiting Between Screens

A business applicant completes the onboarding form. The confirmation page says “Submitted.” Three days later, the applicant still cannot use the account and does not know whether anyone needs something from them.

The interface has reached its final screen. The customer's work has continued.

Consider a fictional application in which operations needs a document held by the applicant's finance colleague. An email goes to the person who submitted the form, a support conversation starts, and the request eventually reaches the colleague. This example is invented to examine the handoffs; the elapsed time is not a measured result from a real service.

A useful customer journey map follows that work until the person reaches the outcome they came for. It includes the queues, messages and colleagues between the screens. This guide shows how to build that view without turning assumptions into research findings.

Illustrative scenario; no actual customer or program result is shown.

Define where this journey really ends

“Application submitted” is a useful event to measure. Whether it is the right end condition depends on the question being investigated. If the question is how people complete a form, submission may be a reasonable boundary. If the question is why new customers cannot start using the service, the map needs to continue.

For the fictional case, define the outcome as “The applicant can complete the first permitted account task.” Include the decision and communication if the application cannot proceed. A rejected applicant has also experienced the service; excluding that path would hide part of the problem.

The UK Government Service Manual describes experience maps as a view of what people do, think and feel across their use of a service. It recommends gathering multiple users' experiences and separating maps when groups follow materially different paths. That is a useful research method here, not a legal requirement for every private product. Creating an experience map

Write the boundary at the top of the working map. Otherwise one workshop participant may map the interface while another maps the operation, and both may believe they have covered the whole experience.

Reconstruct a recent case before designing the ideal one

Start with a participant who has experienced the journey, with appropriate consent. Ask them to describe what happened in sequence. Useful prompts are concrete: What did you see after submitting? What did you do next? How did the document request reach your colleague? What told you that the request had been resolved?

With permission, use the messages or records they refer to. A participant's recollection and an event timestamp are different kinds of evidence. Keep both, and record any disagreement rather than forcing the account to fit the system log.

The Service Manual's research method uses event cards to reconstruct an experience with participants. It also distinguishes what happened from their ideas about what should have happened. Preserve that separation in your own notes: an attractive future state is not evidence of today's service. Researching user experiences

One case can expose a question worth investigating. It cannot establish how common the problem is. Include different outcomes and relevant user groups before treating the map as representative. In this example, that might mean completed, withdrawn and unresolved applications, and people who submit their own documents versus those who depend on a colleague.

Avoid filling gaps with plausible emotions. If a participant says they were confused, record the statement with its context. If the team merely suspects confusion, label it as a hypothesis and decide how to investigate it.

Give the wait a place in the map

The following is a fictional working map. It demonstrates what to record; it contains no measured service times or customer findings.

At each wait, ask who can move the case forward, whether that person knows, and what the customer can see. “Pending” answers none of those questions on its own.

Do not expose internal queue detail just because the team can see it. The customer needs useful information: what action is required, who should take it, how to do it safely and how to get help. A precise status should reflect what the service actually knows. If a completion estimate is uncertain, do not display a confident countdown.

Follow the handoff without losing its owner

This is a proposed service design for the fictional case, not an implemented workflow. An unresolved request returns to a named owner.

1. Application submittedApplicant receives the case reference and an accurate explanation of what happens next.↓
2. Information requestedOperations explains the missing document and assigns the next action.↓
3. Authorized colleague respondsThe colleague receives only the permitted access needed to supply the document.

   Request stuck or misdirected: route it to the named case owner, who can explain the safe recovery path. Do not create another application merely to restart the handoff.

   ↓
4. Operations reviews the responseReceipt and acceptance are separate states. An insufficient response returns to a named owner.↓
5. Decision communicatedApplicant can understand the outcome and the available next step, including when the application cannot proceed.

Use the map to ask what happens when the intended handoff fails. The colleague may not have access. A link may expire. The document may arrive but fail to attach to the application. A reminder may go to the wrong person. Each condition needs a recovery path that a service team can explain.

A journey map describes the experience from the customer's perspective. If investigating the wait requires detailed queues, systems and operational dependencies, connect it to a service blueprint or process model. Keep the two views linked through the same stages and case references; do not make the customer map unreadable by placing every internal component in it.

Separate elapsed time from work time

To investigate a delay, define the timestamps before calculating a metric. For this example, request-created to acceptable-document-received measures one elapsed interval. It includes time the applicant or colleague spends responding. Document-received to review-completed measures a different interval, which may include an internal queue.

Those intervals answer different questions. Combining them into one average and assigning all of it to operations would hide who was able to act at each stage.

Record the observation period, time zone and treatment of non-working hours. Distinguish a system event from a person seeing a notification. A delivered email is not proof that the recipient read or understood the request.

Also keep unresolved cases visible. Calculating duration only for completed cases can make a service look faster while its oldest cases remain stuck. Show the age and count of open cases separately from the duration of resolved cases. These are proposed measurement choices for this investigation, not a universal KPI specification.

Protect participant information in the working map. Use reference IDs where possible, restrict access to the underlying records and remove unnecessary personal details from material shared beyond the research team.

Choose a change that answers the evidence

Suppose the research supports a specific finding: applicants receive a document request but cannot tell which colleague should respond. A new progress animation would not directly address that finding.

A candidate change might let the applicant identify an authorized colleague and see whether the request is still waiting for their response. Before building it, test the wording and handoff with people who use and operate the service. Establish what access the colleague needs and what information they should be allowed to see. A convenient forwarding link should not disclose the rest of the application.

Write a small decision record: the observed interruption, the proposed change, the expected mechanism and the evidence that would change your mind. For example, clearer assignment might reduce requests sent to the wrong person. It might also introduce permission questions or make applicants feel they have lost control. Both belong in the evaluation.

Do not infer a causal improvement from a single before-and-after number. Demand, staffing, policy and applicant mix can change. Choose an evaluation method appropriate to the decision and record those limitations.

For the wider discovery process, see product discovery research in payments. The product management responsibilities guide explains how discovery decisions relate to delivery and operations.

Review the future journey with the people who will run it

Use a walkthrough to test proposed behavior before presenting the new map as a promise. The following checks are suggested, not completed tests:

• The applicant can tell whether they need to act or wait, using the displayed status and message.
• The colleague receives only the access and information needed for the requested action.
• An expired link has an understandable recovery route without creating a duplicate application.
• A supplied document is linked to the correct request, and its receipt is distinct from its acceptance.
• Support can identify the next owner when the case has stopped progressing.
• A declined, withdrawn or incomplete application has a clear outcome and next step where one is available.

Record findings, the decision made and unresolved questions. A walkthrough may reveal a design issue; it does not establish that the live service behaves as intended. Verify the implemented behavior separately.

The map has done useful work when it helps the team choose and assess a specific change. Keep its date and evidence references visible, and update it when the service changes. The time between two screens is part of the product even when no screen is open.

Primary research guidance checked on 24 October 2026. The application, working map and proposed controls are original illustrative examples. No measured customer result or personal delivery experience is claimed.