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

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.