CASE STUDY – EMPLOYMENT INSURANCE (EI) APPLICATION MODERNIZATION
Designing for people in crisis, inside a system built for policy.
CLIENT
Employment and Social Development Canada (ESDC)
TYPE
Mobile-first, Web Responsive
DURATION
Ongoing (Year 2)
TOOLS
Figma, Miro, Mural, Azure DevOps
ROLE
Senior Product Designer — IC across multiple pods
TEAM
Cross-functional — designers, BAs, content, product, SMEs, developers
OVERVIEW
A national program. Complex by design. No room for ambiguity.
Canada's Employment Insurance program processes millions of claims a year, but the application experience hadn't meaningfully changed in decades. Aging legacy systems, policy-driven architecture, and a government-wide push to modernize digital services created the conditions for a significant overhaul. This is one of the largest digital transformation efforts in the Canadian federal government.
The existing experience was dense, jargon-heavy, and built around policy logic rather than human behaviour. High drop-off rates and error-driven rejections weren't just a content problem. They were a structural one affecting Canadians during some of the most vulnerable moments of their lives: job loss, illness, caregiving, etc.
I've been embedded across this program for over two years, moving through multiple pods. All the way from hands-on flow design to systems thinking, and most recently stepping into a service design role on the planning team to guide the work for future releases (working directly with program leadership).
THE PROBLEM
Users weren't failing because the policy was hard. They were failing because the experience gave them no tools to succeed.
The application dumped critical information all at once, with no indication of what mattered now versus later. There was no progress visibility, no preparation, and no way to catch errors before submission. Users were making high-stakes decisions (tax elections, income declarations), without context or guidance. The question wasn't how to simplify a complex system. It was how to design structure that builds confidence, without touching policy or legal constraints.
THE WORK
Four interconnected pieces and why each one mattered.
01
UX audit and heuristic evaluation
Before designing anything, I mapped the end-to-end application to find recurring patterns of confusion versus individual screens. This shifted the work from fixing UI to fixing structure and reorganizing the application through a series of card sorting workshops..
02
Application homepage and wayfinding
A central hub that gave users a clear entry point, visible section statuses, and a realistic time expectation upfront. If users knew where they were and what was coming, early drop-off would decrease. User testing validated this and participants moved through flows with significantly less hesitation.
03
Section checklists
A lightweight pattern introduced before each section begins. Not instructions, but preparation information. Users arrived at each section knowing exactly what they'd need, reducing backtracking and mid-flow errors.
04
Review pages
Allowing users to see a clear summary of their inputs before advancing, with the ability to edit without restarting. This was designed to reduce rejection rates driven by entry errors, not intent.
In policy-driven systems, clarity doesn't come from simplification. It comes from structure and from design decisions that hold up under constraint.
SYSTEMS & SCALE
Consistency doesn't happen by accident at a program scale.
As the work expanded across pods and benefit types, I co-initiated a shared component library. This became a single source of truth for interaction patterns, component states, and question variants. It became an active tool that let multiple design pods ship consistently without constant coordination overhead.
I also introduced Design QA checkpoints as the work shipped. This is involved auditing screens in build (and in context) to catch drift early and surface systemic gaps before they compounded.
OUTCOME
Structure builds confidence. Confidence reduces errors.
User testing showed participants moving through modernized flows with little to no guidance. They began naturally reusing patterns, encountering fewer moments of hesitation, and expressing more confidence before submitting. The homepage, checklists, and review pages worked together, not in isolation.
As the program has scaled, so has my role within it. Moving from delivery into the planning team meant shifting focus. I started with designing features for Canadians navigating EI, to designing the processes and flows that help our designers, business analysts, content designers, and user researchers do their best work. Working directly alongside program leadership, I'm now focused on streamlining how design and delivery actually function on the ground, turning two years of iterations, learnings, and incoming data into a foundation the whole team can build from.
LEARNING
In policy-driven systems, clarity doesn't come from simplification. It comes from structure, reusable patterns, and design decisions that hold up under constraint. But the deeper learning was about adaptability. It was learning to become water and to take the shape of whatever container I was given, whether that was a delivery pod, a systems problem, or a seat at the planning table with program leadership. This project taught me that the best designers aren't the ones with the most polished process, they're the ones who stay curious, stay malleable, and keep showing up in the mess.
NDA NOTICE
This work is under NDA. Detailed flows, design decisions, and validation findings are available to discuss in conversation.