Steve Fox UX Services

Designing a retraining service to help people move into more secure work

ROLE: Lead UX Designer

DATE: May 2019 – March 2020

SUMMARY

I worked on Get Help to Retrain, part of the Department for Education’s national retraining scheme. The service was designed to help people recognise the skills they already had, explore related roles based on transferable skills, and take practical steps towards more secure work in a changing labour market.

This was a citizen-facing government service with a demanding delivery context. The team needed to stand up a useful Alpha quickly, while working within the constraints of reused data sources, designing for a lower digital literacy cohort, and paying close attention to GOV.UK service standards ahead of GDS assessment.

END-TO-END-JOURNEY

From skills assessment to personalised action plan

These screens show the high level user journey: helping users identify their existing skills, explore related roles, understand new opportunities, choose relevant training, and build a personalised plan towards more secure work.

END-TO-END-JOURNEY

From skills assessment to personalised action plan

WHAT I DID

Designed the service as part of DfE’s Get Help to Retrain programme.
Helped shape a service to support job seekers in building on existing skills and moving into more secure work.
Delivered a usable Alpha service within a tight 4-week timeframe.
Worked through the challenge of reusing existing data sources.
Designed patterns and information architecture for a lower digital literacy cohort.
Produced complex prototypes using the GDS prototyping toolkit.
Rigorously tested prototypes and iterated the service based on feedback and learning.
Designed the phased rollout of the service, producing both future-state prototypes for testing and phase-specific prototypes that gave developers a clear specification to build against.
Used prototype code to help communicate logic, styles and component behaviour to developers.
Paid close attention to GOV.UK service standards to help the service meet the level required for GDS assessment.
Took the project through GDS assessment.

PHASED ROLLOUT
Evolving the service through Alpha
The service changed significantly across Alpha. Each phase introduced new functionality, simplified the journey, and responded to user research findings about navigation, clarity and next-step confidence.
The service was intentionally designed in phases so the team could launch quickly, test with users, and add capability in manageable steps. Each phase acted as a learning loop, helping the journey become clearer, more useful, and easier to build.
PHASE 1 V1
Phase 1: testing an early task-based structure
The first version assumed users would move in and out of the service over multiple visits, returning to a task list after completing each section. This reflected an early hypothesis that users might not complete the journey in one sitting.
User research insight
Research showed this model created confusion. Users felt they were repeatedly being taken back to the start rather than progressing through a clear journey.
Decision point
This highlighted the need for a stronger sense of progression and led to a rethink of the journey structure in later phases.
PHASE 1 V2
Phase 1 iteration: moving towards a clearer linear journey
Based on research findings from the earlier version, the service moved towards a more linear structure. This helped users better understand where they were in the journey and what they needed to do next.
User research insight
Users found the journey straightforward and easy to use, but many still stopped early because there was not yet enough indication that further steps remained.
Decision point
The next phase needed to preserve the simplicity of the linear journey while making onward progression, next steps, and broader support options more visible.
PHASE 2
Phase 2: expanding the journey with training and next steps
Phase 2 introduced the training hub and online course routes, giving the service more breadth and making it more useful beyond role exploration alone.
User research insight
Users liked the simplicity of the service flow, but some missed the route into ‘Find out what you can do next’. The right-hand-column link was useful when prompted, but was not always seen as part of the main journey.
Decision point
This showed that adding more capability was not enough on its own — the service also needed clearer primary calls to action and stronger hierarchy around next-step decisions.
PHASE 4
Phase 4: bringing the journey together around action planning
By Phase 4, the service had evolved into a more complete and joined-up journey. New information architecture supported action planning, training choices, and help with getting a job, bringing the experience closer to a practical end-to-end service.
User research insight
Users responded positively to the action plan and the practical steps it offered, especially as it helped break down what they needed to do in order.
Decision point
This phase showed the value of simplifying the journey while making outcomes more tangible. The action plan became a stronger endpoint that connected role exploration, training and next steps into something users found useful.

PHASED ROLLOUT
Evolving the service through Alpha
The service changed significantly across Alpha. Each phase introduced new functionality, simplified the journey, and responded to user research findings about navigation, clarity and next-step confidence.
The service was intentionally designed in phases so the team could launch quickly, test with users, and add capability in manageable steps. Each phase acted as a learning loop, helping the journey become clearer, more useful, and easier to build.
PHASE 1 V1
Phase 1: testing an early task-based structure
The first version assumed users would move in and out of the service over multiple visits, returning to a task list after completing each section. This reflected an early hypothesis that users might not complete the journey in one sitting.
User research insight
Research showed this model created confusion. Users felt they were repeatedly being taken back to the start rather than progressing through a clear journey.
Decision point
This highlighted the need for a stronger sense of progression and led to a rethink of the journey structure in later phases.
PHASE 1 V2
Phase 1 iteration: moving towards a clearer linear journey
Based on research findings from the earlier version, the service moved towards a more linear structure. This helped users better understand where they were in the journey and what they needed to do next.
User research insight
Users found the journey straightforward and easy to use, but many still stopped early because there was not yet enough indication that further steps remained.
Decision point
The next phase needed to preserve the simplicity of the linear journey while making onward progression, next steps, and broader support options more visible.
PHASE 2
Phase 2: expanding the journey with training and next steps
Phase 2 introduced the training hub and online course routes, giving the service more breadth and making it more useful beyond role exploration alone.
User research insight
Users liked the simplicity of the service flow, but some missed the route into ‘Find out what you can do next’. The right-hand-column link was useful when prompted, but was not always seen as part of the main journey.
Decision point
This showed that adding more capability was not enough on its own — the service also needed clearer primary calls to action and stronger hierarchy around next-step decisions.
PHASE 4
Phase 4: bringing the journey together around action planning
By Phase 4, the service had evolved into a more complete and joined-up journey. New information architecture supported action planning, training choices, and help with getting a job, bringing the experience closer to a practical end-to-end service.
User research insight
Users responded positively to the action plan and the practical steps it offered, especially as it helped break down what they needed to do in order.
Decision point
This phase showed the value of simplifying the journey while making outcomes more tangible. The action plan became a stronger endpoint that connected role exploration, training and next steps into something users found useful.

PHASED ROLLOUT
Evolving the service through Alpha
The service changed significantly across Alpha. Each phase introduced new functionality, simplified the journey, and responded to user research findings about navigation, clarity and next-step confidence.
The service was intentionally designed in phases so the team could launch quickly, test with users, and add capability in manageable steps. Each phase acted as a learning loop, helping the journey become clearer, more useful, and easier to build.
PHASE 1 V1
Phase 1: testing an early task-based structure
The first version assumed users would move in and out of the service over multiple visits, returning to a task list after completing each section. This reflected an early hypothesis that users might not complete the journey in one sitting.
User research insight
Research showed this model created confusion. Users felt they were repeatedly being taken back to the start rather than progressing through a clear journey.
Decision point
This highlighted the need for a stronger sense of progression and led to a rethink of the journey structure in later phases.
PHASE 1 V2
Phase 1 iteration: moving towards a clearer linear journey
Based on research findings from the earlier version, the service moved towards a more linear structure. This helped users better understand where they were in the journey and what they needed to do next.
User research insight
Users found the journey straightforward and easy to use, but many still stopped early because there was not yet enough indication that further steps remained.
Decision point
The next phase needed to preserve the simplicity of the linear journey while making onward progression, next steps, and broader support options more visible.
PHASE 2
Phase 2: expanding the journey with training and next steps
Phase 2 introduced the training hub and online course routes, giving the service more breadth and making it more useful beyond role exploration alone.
User research insight
Users liked the simplicity of the service flow, but some missed the route into ‘Find out what you can do next’. The right-hand-column link was useful when prompted, but was not always seen as part of the main journey.
Decision point
This showed that adding more capability was not enough on its own — the service also needed clearer primary calls to action and stronger hierarchy around next-step decisions.
PHASE 4
Phase 4: bringing the journey together around action planning
By Phase 4, the service had evolved into a more complete and joined-up journey. New information architecture supported action planning, training choices, and help with getting a job, bringing the experience closer to a practical end-to-end service.
User research insight
Users responded positively to the action plan and the practical steps it offered, especially as it helped break down what they needed to do in order.
Decision point
This phase showed the value of simplifying the journey while making outcomes more tangible. The action plan became a stronger endpoint that connected role exploration, training and next steps into something users found useful.

THE CHALLENGE

The challenge was to design a service that was genuinely useful under Alpha timelines, without assuming high digital confidence from users. The audience needed clarity, familiar patterns and simple decision-making, while the service itself had to work within the limits of existing data and delivery constraints.

There was also a wider strategic challenge. The service needed to prove enough value to move forward, while still aligning with the expectations of a citizen-facing GOV.UK service. That meant balancing user needs, policy intent, feasibility and service-standard thinking throughout the design process.

RESEARCH-LED ITERATION
Improving how users confirm their existing skills
Research showed that a fixed list of role-based skills felt too rigid and sometimes inaccurate. Iteration focused on giving users more control, reducing frustration, and improving how future roles were matched.
This interaction was central to the quality of the service. The more accurately users could confirm their existing skills, the better the service could suggest relevant future roles and training options. Research made it clear that relying on job title alone was too blunt, so the pattern evolved to give users a more active role in shaping their profile.
VERSION 1
Version 1: a fixed list of skills created friction
The first version showed a static list of skills associated with the user’s current role. In research, this caused frustration because job titles alone did not always reflect the reality of what users actually did in different workplaces.
User research insight
An admin assistant in one organisation might not have exactly the same responsibilities or skills as an admin assistant in another.
Design implication
This meant the pattern felt too rigid, reduced confidence in the results, and risked matching users to future roles using an inaccurate picture of their skills.
VERSION 2
Version 2: giving users control improved accuracy and confidence
The revised version introduced checkboxes so users could deselect any skills they did not feel applied to them. This made the journey feel more natural, lowered frustration, and better matched what users expected to be able to do.
User research insight
Users wanted the opportunity to correct the system’s assumptions rather than accept a fixed skills profile.
Design outcome
Allowing users to refine their skills list created a more accurate view of their experience, which in turn improved how closely the service could match them to potential future roles.

RESEARCH-LED ITERATION
Improving how users confirm their existing skills
Research showed that a fixed list of role-based skills felt too rigid and sometimes inaccurate. Iteration focused on giving users more control, reducing frustration, and improving how future roles were matched.
This interaction was central to the quality of the service. The more accurately users could confirm their existing skills, the better the service could suggest relevant future roles and training options. Research made it clear that relying on job title alone was too blunt, so the pattern evolved to give users a more active role in shaping their profile.
VERSION1
Version 1: a fixed list of skills created friction
The first version showed a static list of skills associated with the user’s current role. In research, this caused frustration because job titles alone did not always reflect the reality of what users actually did in different workplaces.
User research insight
An admin assistant in one organisation might not have exactly the same responsibilities or skills as an admin assistant in another.
Design implication
This meant the pattern felt too rigid, reduced confidence in the results, and risked matching users to future roles using an inaccurate picture of their skills.
VERSION 2
Version 2: giving users control improved accuracy and confidence
The revised version introduced checkboxes so users could deselect any skills they did not feel applied to them. This made the journey feel more natural, lowered frustration, and better matched what users expected to be able to do.
User research insight
Users wanted the opportunity to correct the system’s assumptions rather than accept a fixed skills profile.
Design outcome
Allowing users to refine their skills list created a more accurate view of their experience, which in turn improved how closely the service could match them to potential future roles.

RESEARCH-LED ITERATION
Improving how users confirm their existing skills
Research showed that a fixed list of role-based skills felt too rigid and sometimes inaccurate. Iteration focused on giving users more control, reducing frustration, and improving how future roles were matched.
This interaction was central to the quality of the service. The more accurately users could confirm their existing skills, the better the service could suggest relevant future roles and training options. Research made it clear that relying on job title alone was too blunt, so the pattern evolved to give users a more active role in shaping their profile.
VERSION 1
Version 1: a fixed list of skills created friction
The first version showed a static list of skills associated with the user’s current role. In research, this caused frustration because job titles alone did not always reflect the reality of what users actually did in different workplaces.
User research insight
An admin assistant in one organisation might not have exactly the same responsibilities or skills as an admin assistant in another.
Design implication
This meant the pattern felt too rigid, reduced confidence in the results, and risked matching users to future roles using an inaccurate picture of their skills.
VERSION 2
Version 2: giving users control improved accuracy and confidence
The revised version introduced checkboxes so users could deselect any skills they did not feel applied to them. This made the journey feel more natural, lowered frustration, and better matched what users expected to be able to do.
User research insight
Users wanted the opportunity to correct the system’s assumptions rather than accept a fixed skills profile.
Design outcome
Allowing users to refine their skills list created a more accurate view of their experience, which in turn improved how closely the service could match them to potential future roles.

PHASED ROLLOUT
Evolving the service through Alpha
The service changed significantly across Alpha. Each phase introduced new functionality, simplified the journey, and responded to user research findings about navigation, clarity and next-step confidence.
The service was intentionally designed in phases so the team could launch quickly, test with users, and add capability in manageable steps. Each phase acted as a learning loop, helping the journey become clearer, more useful, and easier to build.
PHASE 1 V1
Phase 1: testing an early task-based structure
The first version assumed users would move in and out of the service over multiple visits, returning to a task list after completing each section. This reflected an early hypothesis that users might not complete the journey in one sitting.
User research insight
Research showed this model created confusion. Users felt they were repeatedly being taken back to the start rather than progressing through a clear journey.
Decision point
This highlighted the need for a stronger sense of progression and led to a rethink of the journey structure in later phases.
PHASE 1 V2
Phase 1 iteration: moving towards a clearer linear journey
Based on research findings from the earlier version, the service moved towards a more linear structure. This helped users better understand where they were in the journey and what they needed to do next.
User research insight
Users found the journey straightforward and easy to use, but many still stopped early because there was not yet enough indication that further steps remained.
Decision point
The next phase needed to preserve the simplicity of the linear journey while making onward progression, next steps, and broader support options more visible.
PHASE 2
Phase 2: expanding the journey with training and next steps
Phase 2 introduced the training hub and online course routes, giving the service more breadth and making it more useful beyond role exploration alone.
User research insight
Users liked the simplicity of the service flow, but some missed the route into ‘Find out what you can do next’. The right-hand-column link was useful when prompted, but was not always seen as part of the main journey.
Decision point
This showed that adding more capability was not enough on its own — the service also needed clearer primary calls to action and stronger hierarchy around next-step decisions.
PHASE 4
Phase 4: bringing the journey together around action planning
By Phase 4, the service had evolved into a more complete and joined-up journey. New information architecture supported action planning, training choices, and help with getting a job, bringing the experience closer to a practical end-to-end service.
User research insight
Users responded positively to the action plan and the practical steps it offered, especially as it helped break down what they needed to do in order.
Decision point
This phase showed the value of simplifying the journey while making outcomes more tangible. The action plan became a stronger endpoint that connected role exploration, training and next steps into something users found useful.

APPROACH

I focused on getting the service into a form that was understandable and usable early. That meant using the GDS prototyping toolkit to move quickly, while paying close attention to information architecture, task flow, content structure and the order in which information was introduced.

Prototype testing and iteration improved each major part of the service over time. I refined how users found their current role, how they selected transferable skills, how they explored related roles, and how they built a personalised action plan. Different patterns were tested to find the most intuitive way of helping users make progress without overwhelming them.

The phased rollout was a key part of the approach. It allowed the team to get the service live in a useful form quickly, while also creating clear milestones for how features and complexity would be added over time. Alongside future-state prototypes for testing, I produced phase-specific prototypes that developers could build from directly. That made the work more delivery-ready and gave the team a clearer bridge from design into implementation.

Throughout the project, I also paid close attention to GOV.UK service standards. Because this was a citizen-facing service, the design needed to align closely with GDS expectations, and the research process needed to be rigorous in how it was conducted, recorded and synthesised. That discipline was important in getting the parts of the service I controlled to the right standard for assessment.

WHY IT MATTERED

The service addressed a real need. As automation and longer working lives reshape the labour market, people need clearer ways to understand what skills they already have and how those skills could translate into more secure work.

This mattered especially for users who might otherwise struggle with digital services. In that context, good UX was not just about cleaner screens. It was about reducing friction, making options easier to understand, and helping users leave with a clearer sense of what they could do next.

OUTCOME

By the end of Alpha, the service enabled users to check their existing skills by finding their current role or something close to it, explore different roles based on transferable skills, view more information about potential new roles, and build a personalised action plan that included relevant training routes. That made the service something people could meaningfully use, not just a concept for later delivery.

Prototype testing and iteration improved each major section of the service over time. I refined how users found roles, selected transferable skills, explored opportunities and built their action plans, helping make the journey more intuitive and more usable for a lower-confidence audience.

The phased rollout was also a key outcome. It allowed the team to launch quickly, introduce complexity in manageable stages, and give developers a clear roadmap for how the service should grow. The prototypes and supporting code helped communicate not just visuals, but also logic, styles and component behaviour. For stakeholders, the service map became a focal point that made the rollout easier to understand and discuss.

The service did not ultimately pass assessment because of issues with the wider rationale for standing it up, particularly given overlap with the National Careers Service. But the parts of the service I controlled were shaped closely around GOV.UK service standards, and those elements met the required standard. That makes this project an honest example of designing well within constraints, even where the broader strategic context was imperfect.

WHAT THIS SHOWS

Turning a complex policy challenge into a usable citizen-facing service

Designing clearly and effectively under tight Alpha timelines
Building complex prototypes using the GDS prototyping toolkit
Using prototyping and iteration to improve complex journeys over time
Structuring information and interactions for a lower digital literacy audience
Designing phased delivery in a way that supports both users and developers
Translating prototypes into build-ready specifications through code, logic and component thinking
Aligning a service closely to GOV.UK service standards in preparation for GDS assessment
Creating clarity for stakeholders through service maps, rollout planning and shared delivery milestones

From skills assessment to personalised action plan

From skills assessment to personalised action plan

Evolving the service through Alpha

Phase 1: testing an early task-based structure

Phase 1 iteration: moving towards a clearer linear journey

Phase 2: expanding the journey with training and next steps

Phase 4: bringing the journey together around action planning

Evolving the service through Alpha

Phase 1: testing an early task-based structure

Phase 1 iteration: moving towards a clearer linear journey

Phase 2: expanding the journey with training and next steps

Phase 4: bringing the journey together around action planning

Evolving the service through Alpha

Phase 1: testing an early task-based structure

Phase 1 iteration: moving towards a clearer linear journey

Phase 2: expanding the journey with training and next steps

Phase 4: bringing the journey together around action planning

Improving how users confirm their existing skills

Version 1: a fixed list of skills created friction

Version 2: giving users control improved accuracy and confidence

Improving how users confirm their existing skills

Version 1: a fixed list of skills created friction

Version 2: giving users control improved accuracy and confidence

Improving how users confirm their existing skills

Version 1: a fixed list of skills created friction

Version 2: giving users control improved accuracy and confidence

Evolving the service through Alpha

Phase 1: testing an early task-based structure

Phase 1 iteration: moving towards a clearer linear journey

Phase 2: expanding the journey with training and next steps

Phase 4: bringing the journey together around action planning