User Journey Mapping - Future State
From Current to Future
A future-state journey map describes how a service should work after improvements. It connects current-state problems with a proposed experience that helps citizens, businesses, government officers and other agencies achieve their goals.
Learning outcomes
- Use current-state findings to identify improvement opportunities.
- Define the intended user outcome and design principles.
- Create a future journey across digital and non-digital channels.
- Identify organisational changes needed to deliver it.
- Prioritise improvements and define measures of success.
| Current-state finding | Future-state opportunity |
|---|---|
| Requirements scattered across pages | One complete, task-based requirements page |
| Mandatory documents discovered late | Explain documents before submission |
| Confirmation only says Submitted | Confirm receipt and explain the next step |
| Users repeat information when calling | Authorised support staff access relevant details |
| Delivered output misses the need | Confirm scope early and check output before delivery |
The current-state map provides the evidence behind proposed changes. The future-state map is a proposal to test and refine.
Essential Terms
Select a card to reveal a key concept.
Outcomes and Principles
Begin with what users need to achieve, then identify what should improve.
The requesting officer can understand requirements, submit a complete request, follow progress and receive usable data within an agreed timeframe.
Build the Future Journey
Retain useful stages from the current-state map and adjust them where necessary. Describe the proposed experience at each stage.
| Map element | What to specify |
|---|---|
| User actions | What the user will do |
| Information and support | What they need to proceed |
| Channels and touchpoints | Where interactions occur |
| Expected experience | What becomes clearer, easier or more reliable |
| Service response | What the organisation must provide |
| Dependencies | Teams, systems, policies and information needed |
| Success measures | How the improvement will be assessed |
Expected thoughts and emotions are design hypotheses. Validate them with users; a redesigned journey does not automatically create confidence or satisfaction.
Handovers and Delivery
A future journey should explain what happens when users move between channels or encounter a problem.
- Can users save progress and continue later?
- Can support staff identify the request without a restart?
- Do emails and portal statuses describe the same situation?
- Who owns the request at each stage?
- What happens when information is missing?
- How are delays communicated?
- What route exists for incorrect or unusable outcomes?
An email requesting clarification should be reflected in the portal, with a clear required action. Confirm when the response has been received and the request can proceed.
| Proposed user experience | Supporting delivery change |
|---|---|
| Complete checklist | Teams agree requirements and maintain a shared source |
| Meaningful progress updates | Consistent processing-stage definitions |
| Clear contact and escalation | Assign responsibility for enquiries and exceptions |
| Less repeated information | Authorised teams access and reuse relevant records |
| Usable data on delivery | Confirm scope and check output |
A clear status page depends on accurate information from processing teams. Improvements often require changes beyond the interface.
Prioritise and Validate
Prioritise using evidence and practical constraints. Then test proposed changes with users and delivery teams.
Journey Explorer
Explore a proposed inter-agency journey, a public-facing example and a validation plan.
Practical Activity
45–60 minutes · Small groups · Use the current-state map from Module 6.
- Select three problems. Explain the evidence and their effect on the goal.
- Define the intended outcome. State what users should accomplish.
- Create the future map. Show actions, touchpoints, service responses and intended improvements.
- Identify dependencies. Record teams, systems and decisions needed.
- Prioritise changes. Select one improvement to test first.
- Define validation. Identify users to involve and measures to observe.
| Worksheet row | What to record for each stage |
|---|---|
| User actions | Proposed actions |
| Information and support | Guidance and help required |
| Channels and touchpoints | Proposed interactions |
| Service response | What delivery teams provide |
| Intended improvement | The current problem being addressed |
| Dependencies and owner | Teams, systems, decisions and responsible role |
| Validation | Evidence to gather and success measures |
Group presentation
Present the proposed journey, the three problems it addresses, its main dependencies and how you will test whether it works.
Design around the user’s outcome and connect the journey to realistic service changes. Test, refine and implement the proposal.
Do not assume that a new interface resolves unclear ownership, disconnected channels or internal delivery constraints.
Knowledge Check
Select one answer per question to see feedback.
