Enrolment flow
Reducing enrolment delays by automating manual processes and designing a GDS-aligned service flow.
The Challenge: Manual processes were creating 3-week enrolment delays and unsustainable operational burden across fragmented systems.
My Role: UX Designer in a cross-functional agile squad. Led service mapping, flow design, and research collaboration.
Impact: Reduced enrolment times by ~1 week. Removed manual processing steps and improved operational clarity.
Process: 2-week sprints | Service blueprints | User flows | Discovery → Alpha → Beta
Skills used: Service design | Journey mapping | Agile delivery | Ideation | Wireframing | Research collaboration
The brief said "improve enrolment." The real problem was nobody could see it end-to-end.
The Learning team thought this was a digital service problem: enrolment was slow and frustrating users.
What we found was a web of disconnected systems and manual workarounds. Internal teams couldn't explain the full journey. Users waited up to three weeks with no visibility into why.
This wasn't a UX problem—it was service design hiding behind multiple systems.
What discovery revealed
What the Brief said: "Users are experiencing delays."
We found: Internal teams were manually re-entering data and checking eligibility for every application. The process varied by course type. Nobody had a complete view.
The constraints:
Legacy systems that didn't talk to each other
Manual checks that couldn't be automated without rebuilding logic
Inconsistent rules across different course types
Stretched teams who needed less work, not more
We needed to understand where manual effort was happening and design around the technical debt.
Flows weren't enough
Halfway through Alpha, I had elegant user flows that solved fragmentation on paper.
But developers flagged that we didn't have clarity on how eligibility logic would work across course types. The flows showed what happened, not why.
I created a logic map showing eligibility rules and dependencies. Not a traditional UX deliverable, but what the team needed.
The outcome: developers built confidently, and we avoided scope creep from discovering edge cases mid-build.
What we delivered
I translated flows into wireframes and a clickable prototype, briefed the researcher on key assumptions and risks, then worked with the UI designer through visual design and a second testing round.
Delivered:
Service blueprints (as-is and future-state)
User flows for eligibility-led enrolment
Eligibility logic maps for implementation
Tested wireframes and prototype
~1 week reduction in enrolment times
Real win: Internal teams could finally see how their work connected to user outcomes. The documentation became a reference for future improvements.
What I'd do differently
Create structured handover templates for edge cases and system behaviours
Challenge technical constraints earlier to expand automation scope
Takeaway
Good service design isn't about perfect journeys, it's about understanding where systems break, designing around constraints you can't change, and creating artefacts that help teams build with confidence.
