Prioritisation, Quick Wins and UX Improvement Roadmap Turn future-state concept

Prioritisation, Quick Wins and UX Improvement Roadmap

UIUX • Government Digital Services • Day 3

Prioritisation, Quick Wins and UX Improvement Roadmap

Turn future-state concepts into evidence-based priorities, practical quick wins and an achievable improvement roadmap.

13 learning sectionsImpact–effort matrix70-minute workshop

PRIORITISE

This module helps participants decide which improvements to deliver first, what must happen before implementation and how success will be measured.

The case study continues with a government web portal that links departments, agencies and staff to online services. Earlier findings showed that some users spend a long time navigating nested menus, while others give up before reaching the service they need.

Learning Outcomes

By the end of this module, participants will be able to:

Assess improvements against user and organisational value.
Compare impact, effort and feasibility.
Identify practical quick wins.
Recognise dependencies and delivery constraints.
Assign ownership for improvements.
Build a phased UX improvement roadmap.
Select measures for evaluating results.

1. From Future-State Journey to Delivery Decisions

A future-state journey may contain more improvements than a team can implement immediately.

For example, the proposed portal experience might include:

Clearer service names.
Task-based navigation.
A searchable service directory.
Information about eligibility and access requirements.
Clear warnings before opening another system.
A way to report broken links.
Consistent support information.

Each proposal may have value, but the work, dependencies and expected benefits will differ.

Prioritisation connects the proposed experience to an achievable delivery plan.

Keep each improvement connected to the problem it addresses.

Identified problem	Proposed improvement	Intended outcome
Officers do not understand menu labels.	Replace unclear labels with language users recognise.	More accurate service selection.
Services are buried in nested menus.	Provide direct routes to frequently used services.	Less searching and backtracking.
Officers cannot distinguish similar services.	Add short descriptions and intended-user information.	Greater confidence when choosing a service.
Links open unfamiliar systems without explanation.	Explain the destination and access requirements.	A clearer handoff to the service platform.
Broken links prevent access.	Repair verified broken links and establish maintenance ownership.	More reliable service access.

These are proposed improvements. Their effectiveness still needs validation.

2. Assess User and Organisational Value

An improvement should help users achieve their goals and support the organisation’s service responsibilities.

User Value

Consider whether the improvement could:

Help users find the correct service.
Reduce uncertainty and repeated attempts.
Improve accessibility.
Prevent errors.
Reduce preparation or recovery effort.
Help users complete the task independently.

Organisational Value

Consider whether the improvement could:

Reduce avoidable support enquiries.
Reduce incorrect referrals.
Improve service completion.
Reduce content-maintenance problems.
Clarify responsibility between teams.
Support consistent information across channels.

Case Study Example

A clear service description may help an officer choose the correct system. It may also reduce enquiries to the wrong department.

This creates value for both the user and the organisation.

However, an improvement should not receive a high priority simply because it is visible or attractive. Explain the connection between the change and the expected outcome.

3. Define Impact and Effort

An impact–effort matrix helps teams compare proposals.

Agree on what “impact” and “effort” mean before placing ideas on the matrix.

Dimension	Questions to consider
Impact	How much could this improve the user outcome? How serious is the problem? Which users are affected?
Effort	What work is required to investigate, design, build, approve, test, release and maintain the change?
Feasibility	Can the proposal work within current technical, operational and governance arrangements?
Evidence confidence	How strong is the evidence supporting the problem and the proposed benefit?

Impact Includes More Than User Numbers +

A problem affecting a smaller group may still deserve high priority if it prevents that group from accessing an essential service.

Consider the severity of the barrier, accessibility needs and the consequences of failure alongside how frequently the problem occurs.

Effort Includes More Than Coding +

Renaming a menu item may appear easy, but it could require:

Agreement from the service owner.
Checks against terminology used elsewhere.
Updates to guidance and translations.
Usability testing.
Content approval and publishing.
Monitoring after release.

Estimate the whole change, including its ongoing maintenance.

4. Use the Impact–Effort Matrix

The matrix groups improvements into four broad areas.

Position	Interpretation	Typical response
High impact, low effort	Strong benefit with relatively manageable work.	Consider as a quick win.
High impact, high effort	Significant benefit requiring substantial work or coordination.	Plan as a larger improvement.
Low impact, low effort	Modest benefit with limited work.	Consider when capacity allows or combine with related work.
Low impact, high effort	Limited expected benefit compared with the work required.	Reconsider, reduce scope or defer.

Illustrative Portal Assessment

The placements below are discussion examples, not confirmed estimates.

Proposed improvement	Expected impact	Estimated effort	Initial interpretation
Repair broken links to important services.	High for affected tasks.	Low if the correct destinations are known.	Potential quick win.
Clarify confusing service labels.	Potentially high.	Low to medium.	Test and consider early delivery.
Add short service descriptions.	Medium to high.	Low to medium.	Useful early improvement if content owners are available.
Create a searchable service directory.	Potentially high.	Medium to high.	Investigate metadata, search capability and maintenance needs.
Redesign the full information architecture.	Potentially high.	High.	Plan research, testing and phased implementation.
Add decorative animation to service cards.	Low unless it addresses a demonstrated need.	Variable.	Lower priority.

Discuss why each proposal belongs in its position. Record uncertainty rather than presenting estimates as facts.

The matrix supports judgement; it does not make the decision for the team.

5. Identify Quick Wins

A quick win is a manageable change that addresses a meaningful problem and can be delivered and checked within a short period.

It should have:

A clear problem.
A defined scope.
An accountable owner.
Manageable dependencies.
A practical way to verify the result.

Possible Quick Wins for the Portal +

Quick win	Why it may help	Check before release
Repair verified broken service links.	Restores access to the intended destination.	Confirm the destination, access conditions and service owner.
Replace an unclear link label.	Helps users predict where the link leads.	Test understanding with representative users.
Add a short service description.	Helps users distinguish similar services.	Confirm accuracy with the service owner.
Explain that a link opens another system.	Makes the handoff more predictable.	Check destination and login information.
Surface selected high-demand services.	Provides a more direct route for common tasks.	Use evidence to select services and retain routes to others.

Avoid Misleading Shortcuts +

Moving every service onto the homepage may reduce menu depth but create an overcrowded page.

Removing explanations may shorten the page while making service selection harder.

A quick win should improve the task outcome, rather than simply reduce clicks or visible content.

6. Check Feasibility and Dependencies

A dependency is something that must be available or completed for an improvement to work.

For example, a service directory requires more than a search box.

It may depend on:

A complete service inventory.
Consistent service names.
Descriptions and relevant keywords.
Audience and eligibility information.
Verified destination links.
Named content owners.
A process for keeping records current.

Dependency Example

Proposed improvement	Dependency	Consequence if unresolved
Task-based service categories.	Agreement on users’ tasks and category labels.	Categories may remain confusing.
Searchable service directory.	Reliable service metadata and search capability.	Search results may be incomplete or irrelevant.
Clear access guidance.	Accurate information from destination-system owners.	Officers may encounter unexpected login barriers.
Automated broken-link monitoring.	Suitable tooling and an assigned response process.	Problems may be detected but remain unresolved.

Where a dependency is uncertain, create an investigation task before committing to implementation.

7. Agree Priorities Transparently

Use a short prioritisation record to make the reasoning visible.

Field	What to record
Problem and evidence	The difficulty and supporting findings.
Affected users	Who experiences the problem.
Expected impact	The outcome the improvement could change.
Effort and feasibility	Work required and important constraints.
Dependencies	What must happen first.
Confidence	What is known and what remains uncertain.
Priority decision	Deliver, investigate, schedule or defer.
Rationale	Why the team made the decision.

Voting can help surface preferences, but review the result against evidence, accessibility needs and service responsibilities.

If an essential service link is broken, the team may need to address it even when another idea receives more votes.

8. Build the UX Improvement Roadmap

A roadmap shows how improvements will progress over time.

Organise work into manageable phases. Use dates when there is enough information to make a credible commitment; otherwise, use provisional delivery horizons.

Example Roadmap +

Horizon	Focus	Illustrative work	Expected output
Near term	Restore access and clarify information.	Repair broken links, test clearer labels and add missing service descriptions.	More reliable and understandable service links.
Medium term	Improve service discovery.	Test task-based categories, build a service-directory prototype and validate search behaviour.	A tested approach to finding services.
Strategic	Establish sustainable portal management.	Implement broader navigation changes, improve integrations where justified and formalise content governance.	A maintained service-discovery experience.

Sequence Work Around Dependencies +

For a service directory, a reasonable sequence might be:

Confirm the service inventory.
Assign content owners.
Standardise essential metadata.
Prototype browsing and search.
Test realistic service-finding tasks.
Implement and release the agreed scope.
Monitor results and maintain the directory.

Some activities can run together. Others depend on earlier decisions.

The roadmap should show those relationships.

9. Assign Ownership

Every roadmap item needs an accountable owner.

“Web team” may be too broad if nobody is responsible for the decision or outcome.

Responsibility	Example role
Accountable for the improvement.	Portal product or service owner.
Confirms service information.	Relevant department or agency service owner.
Designs and tests the experience.	UX researcher, designer or assigned project team.
Implements the change.	Content publisher or development team.
Approves relevant changes.	Authorised content or governance representative.
Monitors results.	Named analytics or service-performance owner.

One person may hold several responsibilities. What matters is that the responsibilities are explicit and accepted.

For links to external service platforms, distinguish the portal team’s responsibility from the destination-system owner’s responsibility.

10. Define Measures of Success

Choose measures that show whether the original problem has improved.

For the nested-menu finding, the key question is:

Can officers find and open the correct service more successfully and with less difficulty?

Suitable Measures +

Measure	What it helps reveal
Service-finding success rate	Whether users reach the correct service.
Time to locate the correct service	How long successful discovery takes.
Abandonment during the task	Whether users stop before reaching the service.
Wrong selections and backtracking	Where navigation causes confusion.
Requests for assistance	Whether users need help to proceed.
Understanding of destination and access requirements	Whether the handoff is clear.
Broken-link incidents	Whether access remains reliable.

Establish a Baseline +

Record the current experience before comparing it with the redesign.

Use comparable users, tasks and testing conditions. Record unsuccessful attempts as well as successful ones; measuring only successful users can hide continuing difficulties.

Set targets after reviewing the baseline and delivery context. Do not invent improvement percentages without a basis.

Distinguish Portal and Service Outcomes +

Reaching the destination service is a portal outcome.

Completing an application on another platform is a wider service outcome that may depend on another team.

Track both where appropriate, while keeping ownership and measurement boundaries clear.

11. Workshop Activity: Prioritise and Plan

Use the future-state journey and before–after map from previous module.

Step	Task	Suggested time
1. List improvements	Extract specific changes from the future-state journey.	5 minutes
2. Agree criteria	Define impact, effort, feasibility and evidence confidence.	5 minutes
3. Assess and position	Place improvements on the impact–effort matrix and explain the reasoning.	15 minutes
4. Check dependencies	Identify prerequisites, constraints and unresolved questions.	10 minutes
5. Select quick wins	Choose manageable changes with meaningful benefits.	10 minutes
6. Build the roadmap	Sequence work and assign accountable owners.	15 minutes
7. Define measures and share	Specify baselines, validation methods and review points.	10 minutes

Expected Outputs

Each group should produce:

An impact–effort matrix.
A quick-win plan.
A phased UX or service improvement roadmap.
Named owners and important dependencies.
Proposed measures and validation activities.

Quick-Win Plan Template

Improvement	Problem addressed	Owner	Dependency	Validation	Target review
Clearer service labels.	Officers misunderstand menu options.	Assign a named owner.	Agreement from relevant service owners.	Test realistic service-finding tasks.	Agree a review date.

Roadmap Template

Priority	Improvement	Expected outcome	Owner	Dependencies	Delivery horizon	Success measure
Agree priority.	Describe a specific change.	State the user or service outcome.	Assign accountability.	List prerequisites.	Set a credible phase or date.	Define observable evidence.

Reflection

Before moving to the final presentation, discuss:

Are our priorities supported by evidence?
Have we considered accessibility and serious barriers affecting smaller user groups?
Do the quick wins address meaningful problems?
Have we included the full delivery and maintenance effort?
Are dependencies and ownership clear?
How will we know whether users find the correct service more successfully?

The roadmap will support next module: Final UX Audit and Service Design Presentation, where participants will explain the connection between evidence, problems, proposed changes, delivery priorities and expected outcomes.

Future-State Journey And Experience Redesign

Module 10 — Future-State Journey & Experience Redesign

UIUX • Government Digital Services

Future-State Journey & Experience Redesign

Turn evidence and solution concepts into a clearer service journey with less effort, better information and reliable recovery.

13 learning sectionsJourney stage explorer75-minute workshop

A current-state journey map shows how users experience a service today. Problem framing and ideation help us identify what needs to improve and explore possible solutions.

This module brings those ideas together into a future-state journey: a proposed experience that helps users achieve their goals with less effort, clearer information and better support.

Participants will redesign a service scenario and compare the current and proposed experiences. The service may serve citizens, businesses, internal staff or officers from other government agencies.

Learning Outcomes

By the end of this module, participants will be able to:

Translate problem statements and solution concepts into a proposed service journey.
Identify opportunities to reduce user effort and simplify service steps.
Improve information flow across digital and non-digital touchpoints.
Redesign content, navigation and interactions around user tasks.
Compare the current and future experiences.
Identify assumptions, dependencies and measures for validating the proposed journey.

1 What Is a Future State Journey

A future-state journey map describes how a user could experience a service after improvements are introduced. It should explain:

What the user is trying to achieve.
How the journey begins.
The stages and actions involved.
The information needed at each stage.
The channels and touchpoints used.
The support available when difficulties occur.
The intended outcomes and expected experience.

The future-state map is a proposal to validate, rather than a prediction of how users will behave.

Keep the Scenario Consistent

Use the same user group, goal and scenario as the current-state map so that the comparison is meaningful.

Example scenario: A requesting officer from another government agency needs to submit a complete technical assistance request and understand its progress until a decision is received.

Do not compare a complex current journey with a future journey that quietly excludes difficult steps, exceptions or users.

2 Move from Problems to Journey Changes

Each proposed change should connect to an identified problem and a desired outcome.

Identified problem	Proposed journey change	Intended benefit
Officers cannot identify the required documents.	Show requirements based on the selected request type before the form begins.	Help officers prepare complete submissions.
Users enter the same information several times.	Reuse verified information where appropriate and allow users to confirm it.	Reduce repeated entry and inconsistency.
Users do not understand form errors.	Explain the issue beside the relevant field and describe how to correct it.	Help users recover and continue.
Users cannot tell what happens after submission.	Provide a reference number, next steps and status information.	Reduce uncertainty and avoidable follow-up.
Users receive conflicting instructions across channels.	Align portal guidance, email templates and helpdesk information.	Support consistent service delivery.

For every change, ask: Which problem does this address, and how will it help the user achieve the goal?

A proposed feature without a clear connection to a user problem needs further examination.

3 Reduce User Effort

User effort includes more than the number of clicks or screens. People may need to:

Search for information.
Interpret unfamiliar terminology.
Collect documents.
Re-enter information.
Contact several departments.
Travel to a service counter.
Correct mistakes.
Wait without knowing what is happening.

Types of Effort

Type	Example	Improvement opportunity
Cognitive effort	Interpreting agency terminology.	Use familiar language and explain necessary technical terms.
Interaction effort	Repeatedly entering the same details.	Reuse information appropriately and simplify entry.
Preparation effort	Discovering documents halfway through a form.	Explain requirements before users begin.
Coordination effort	Contacting several teams to find the owner.	Provide clear responsibility and handoff guidance.
Recovery effort	Restarting after a validation error.	Preserve entered information and explain corrections.
Time and travel effort	Visiting a counter for a clarification.	Provide clear guidance and suitable remote support.

Fewer steps do not automatically mean less effort. A short journey can still be difficult if each step is confusing or demanding.

4 Simplify the Journey

Review each step and decide whether to retain, improve, combine or remove it.

Questions to Ask+

What purpose does this step serve?
Does the user need to perform it?
Is the same information collected elsewhere?
Can the service handle the task internally?
Can users complete related actions together?
Is the sequence logical from the user’s perspective?
Does the step support a legitimate policy, operational or accountability requirement?

Example Repeated Information+

Current experience: An officer enters agency details in the portal, downloads a form containing the same fields, completes it and uploads it again.

Proposed experience: The officer confirms agency details once. If a separate document is still required, the service generates it using the confirmed information.

The team must check whether signatures, authorisation or other requirements affect this proposal.

Avoid Moving the Burden+

A redesign should reduce total effort across the service.

For example, removing a required-information field may make submission easier but cause staff to request the information later. The journey becomes longer even though the form becomes shorter.

5 Clarify Information Flow

Users need the right information at the point where they make a decision or take an action. A useful sequence is:

Point in the journey	Information users need
Before starting	Purpose, eligibility, requirements, expected time and available support.
During preparation	Relevant documents, accepted formats and examples.
During completion	Clear labels, instructions, progress and correction guidance.
Before submission	A review of entered information and an explanation of any declaration.
After submission	Confirmation, reference number, next steps and processing information.
During processing	Current status, outstanding actions and meaningful updates.
At completion	Decision, explanation and any available next action.

Use Progressive Disclosure

Show essential information first and reveal additional detail when relevant.

For example, document guidance can change according to the selected request type. Users should still be able to understand the overall requirements before committing to the process.

Avoid hiding essential conditions, costs or requirements until late in the journey.

6 Improve Touchpoints Content Navigation and Interaction

A touchpoint is any point where the user interacts with the service. It may include a website, form, email, phone call, counter visit or conversation with an officer.

Content+

Content should help users understand and act. Improvements may include:

Task-based headings.
Plain-language instructions.
Clear eligibility explanations.
Specific document requirements.
Examples where requirements are difficult to interpret.
Actionable confirmation and error messages.

Less helpful: “Submission unsuccessful due to invalid input.”

More helpful: “Enter the request reference number in the format shown below, then submit again.”

Navigation+

Navigation should reflect what users are trying to do.

For example, “Request technical assistance” is more useful to a requesting officer than a menu label that only names the receiving division.

Provide clear routes to requirements, the application, saved drafts and request status.

Interaction+

Interactions should help users complete tasks and recover from difficulties. Consider:

Clear labels and visible primary actions.
Appropriate input controls.
Guidance beside unfamiliar fields.
Useful validation messages.
Preservation of entered information.
Save-and-resume for longer tasks.
A review step before submission.
Clear feedback after important actions.

Across Channels+

Check that digital and non-digital touchpoints support the same journey.

An officer who calls the helpdesk should receive guidance consistent with the portal. A counter visit should not require users to repeat information already provided unless there is a valid reason.

7 Design for Exceptions and Recovery

The future-state journey should include more than the ideal path. Consider what happens when:

A required document is unavailable.
A user submits incorrect information.
A request needs clarification.
A system becomes unavailable.
An application is rejected.
A user needs accessibility or assisted support.
Responsibility passes to another team or agency.

For each exception, identify:

1. How the user learns about the issue.

2. What action the user can take.

3. What information is preserved.

4. Who provides support.

5. How the journey continues or ends.

Example: If a supporting document is unsuitable, the officer receives a message naming the document, explaining the issue and providing a route to replace it without resubmitting the entire request.

8 Build the Future State Journey Map

Begin with the scenario and selected concepts from Module 9. Use the following structure:

Map element	What to record
Stage	A meaningful phase of the journey.
User goal	What the user needs to achieve at that stage.
User actions	What the user does.
Channels and touchpoints	Where interactions occur.
Information and feedback	What the service explains or confirms.
Expected experience	Intended thoughts, confidence or emotions; validate these later.
Service response	What staff or systems must do to support the experience.
Exception and recovery	How difficulties are handled.
Evidence or assumption	What supports the proposal and what needs testing.

Example Inter Agency Technical Assistance Request

Stage	Proposed user experience	Supporting service change
Discover	The officer finds the service using a task-based label and checks whether it meets the need.	Clear service description, scope and navigation.
Prepare	The officer selects a request type and sees the relevant requirements.	Request-specific checklist and document examples.
Complete	The officer enters information, saves progress and receives clear correction guidance.	Suitable controls, save-and-resume and useful validation.
Review and submit	The officer checks the details and receives confirmation with a reference number.	Review screen and reliable submission acknowledgement.
Track and respond	The officer sees progress and responds to specific clarification requests.	Consistent statuses, notifications and a route to provide additional information.
Receive outcome	The officer receives the decision and understands any next action.	Clear outcome communication and follow-up guidance.

Keep the map at a level that explains the experience. Detailed screen designs can follow when the proposed journey is sufficiently clear.

Journey stage explorer

Select a stage to see the intended experience and service support.

9 Compare the Before and After Experience

A before–after experience map makes the proposed changes visible and explains their value. Use the same stages and user goal for both versions.

Experience area	Current state	Proposed future state	Expected improvement
Find the service	Service appears under an unfamiliar division name.	Service appears under a clear task label.	Easier identification of the correct service.
Prepare documents	One general list covers several request types.	Requirements reflect the selected request type.	Less uncertainty and preparation rework.
Complete the request	Information is repeated in a form and attachment.	Information is confirmed once and reused where appropriate.	Less repeated entry.
Correct errors	A general message appears after submission.	Specific guidance appears beside the relevant field.	Easier recovery.
Understand progress	Officers call for updates.	Status and next-action information are available.	Less uncertainty and avoidable follow-up.
Respond to clarification	Officers resubmit the full request.	Officers provide the requested correction through a clear route.	Less recovery effort.

These improvements are expected benefits. Confirm them through testing and service measurement.

10 Validate the Proposed Experience

A future-state map provides a basis for discussion and testing.

Walk Through the Scenario+

Ask a participant to explain the journey from the user’s perspective:

Can the user identify where to start?
Is preparation information available early enough?
Does each action lead to a clear response?
Are handoffs understandable?
Can the user recover from a problem?
Is the final outcome clear?

Test Critical Touchpoints+

Use simple prototypes or sample content to test important assumptions.

For example: Can requesting officers use the proposed checklist to identify the correct supporting documents without help?

Review Operational Dependencies+

Discuss the proposal with people responsible for delivery. Check whether it depends on:

Updated guidance or service rules.
Changes to staff responsibilities.
Consistent status definitions.
Information sharing between teams.
System integration.
Staff training.
Accessibility and assisted-service arrangements.

Record unresolved dependencies for prioritisation in Module 11.

Identify Measures+

Possible measures include:

Task completion rate.
Accuracy of document selection.
Time taken to prepare or submit a request.
Returned requests caused by missing information.
Number of avoidable status enquiries.
User understanding of the next step.
Staff time spent on clarification or rework.

Select measures that match the problem. Where possible, compare results with a current-state baseline.

11 Workshop Activity Redesign and Compare

Use the current-state journey, problem statements and selected concepts from the earlier modules.

Step	Task	Suggested time
1. Confirm the scenario	Agree on the user, goal, trigger and journey boundaries.	5 minutes
2. Review the evidence	Select the pain points and concepts to address.	10 minutes
3. Review the steps	Decide what to retain, improve, combine or remove.	10 minutes
4. Map the future state	Describe actions, touchpoints, information and service responses.	20 minutes
5. Add recovery paths	Include important exceptions and assisted support.	10 minutes
6. Compare before and after	Explain the changes and their expected benefits.	10 minutes
7. Review and share	Identify assumptions, dependencies and validation measures.	10 minutes

Expected Outputs

Each group should produce:

A future-state user journey map.
A before–after experience map.
An explanation linking changes to identified problems.
Important exception and recovery paths.
A list of assumptions, dependencies and proposed measures.

Reflection

Before moving to prioritisation, discuss:

1. Does the redesigned journey reduce total effort?

2. Have we removed unnecessary steps while retaining legitimate requirements?

3. Is information available when users need it?

4. Do digital and non-digital touchpoints work together?

5. Can users recover when something goes wrong?

6. Which expected improvements still need validation?

The proposed journey will provide the basis for Module 11: Prioritisation, Quick Wins & UX Improvement Roadmap, where participants will assess impact, effort and feasibility and plan how to deliver the improvements.