Reimagining a $1.1B Public Service From the Inside Out
Client: Government of Alberta Program: Persons with Developmental Disabilities (PDD) Role: Service Designer Timeline: June 2023 – November 2024 Program Scale: $1.1B annual funding | ~13,000 Albertans
Caseworkers meeting clients at coffee shops and public spaces, pen and paper in hand — no way to share a form on a screen, no branching logic, the same information collected over and over because the system wasn’t built to remember.
THE PROBLEM
The Question Nobody Could Agree On
That was the reality behind Alberta’s $1.1B PDD program, a service supporting roughly 13,000 people. It wasn’t broken in any dramatic sense — it was doing its job, at real cost to the people running it and the people who needed it most. Early on, a policy question stopped the room cold: should every applicant get the full Assessment of Needs, or should the process screen people out earlier to protect stretched caseworker capacity? Leadership was genuinely split — not posturing, a real disagreement about what the program owed people. It wasn’t a UX debate. It was a values question with real operational consequences, and no wireframe was going to resolve it.
THE APPROACH
Building the Mirror
Service design, done right, doesn’t stop at the end user — it looks at the whole ecosystem, including the people delivering the service. So instead of jumping to a fix, I built a service blueprint mapping the program end-to-end: every touchpoint, every handoff, every place a policy created a downstream problem. It wasn’t a pretty document. It was a mirror — and what it reflected back to leadership was often uncomfortable: processes nobody had questioned, gaps everyone had quietly normalized. That blueprint became the foundation for every conversation after it. When we got to redesigning the Assessment of Needs form itself, we didn’t validate a prototype with caseworkers — we went to them first, to co-create the logic and flow before a form even existed. They carried the edge cases and exceptions no policy document captured. Because they helped build it, they were invested in it — and that matters more than most teams realize.
THE TURNING POINT
Five Days, One Real Question
The clearest turning point was a five-day MVP planning workshop, run across three phases — discovery with caseworkers, planning with the delivery team, alignment with leadership. We came in with a question, not an answer: what problem were we actually solving, and for whom? What came out the other side was alignment — a shared, committed scope, with clear lines around what was in, what was out, and why.
THE OUTCOME
What Changed
The MVP launched within eighteen months. Two foundational tools — a digital, branching Assessment of Needs, and CIMS, a case management system built around how caseworkers actually work — replaced two fragmented legacy systems. The roadmap stopped being a wish list and became a plan.
WHAT I’D DO AGAIN
Clarity, Not Speed
What I’d do differently: co-create earlier, and hold the line on discovery even harder. The builder is rarely the user — skip that step, and you don’t just build the wrong thing, you build it with confidence. Transformation isn’t a technology problem. It’s a clarity problem. That’s exactly what service design, done well, is built to create.
Program: Persons with Developmental Disabilities (PDD)
Role: Service Designer
Timeline: June 2023 – November 2024
Program Scale: $1.1B annual funding | ~13,000 Albertans
Understanding the ecosystem
Before I could redesign anything, I had to understand what I was dealing with.
What I found was a service that had grown, layer by layer, over decades — held together by age-old forms, manual data entry, and caseworkers meeting clients at coffee shops and public spaces because there was no other option.
Caseworkers conducting assessments in person, pen and paper in hand, no way to share a form on a screen, no branching logic to skip irrelevant questions — just the same information, collected over and over, because the system wasn’t built to remember.
This was the PDD program — a $1.1B annual initiative supporting approximately 13,000 Albertans with developmental disabilities. It wasn’t broken in the dramatic sense. It was doing its job. But it was doing so in a way that put enormous pressure on the people running it and made it even harder for those who needed it most.
My job was to help change that — not by digitizing what already existed, but by understanding why it existed.
Before I dive into the project, it’s worth naming something that shaped my approach to it.
Service design doesn’t stop at the end user. It looks at the whole ecosystem — including the people delivering the service. In this project, those people were the caseworkers — and they weren’t a support function sitting behind the scenes. They were part of creating the experience itself.
A caseworker’s broken tools aren’t an isolated problem — they show up downstream, in the experience of the person on the other end of that interaction. And when that experience improves, the experience changes for the citizen, too, even if they never see why.
This is the distinction I keep coming back to. UX design optimizes what someone sees on a screen. Service design looks at the entire landscape — every touchpoint, frontstage and backstage — because they’re connected, whether we design for that connection or not. And for a public service like this one, that connection matters beyond the program itself: trust in government is built, or worn down, by whether services work for the people who depend on them.
The Question Nobody Could Agree On
Early in the project, a policy tension surfaced that stopped the room.
By policy, every person applying for PDD support was entitled to a full Assessment of Needs — a deep, structured questionnaire designed to understand what kind of support they required. The problem? That assessment was adding significant load to already stretched caseworkers.
Leadership was split. One side argued for a more efficient eligibility filter — screen people out early before committing to a full assessment. The other side held firm: every person deserved the full assessment, regardless.
This wasn’t a UX debate. It was a values question with real operational consequences — and it couldn’t be resolved with a wireframe. What it needed was clarity about what the policy was actually trying to achieve, who it was designed to protect, and what the downstream impact of each path would look like.
That’s what service design is for.
Artifacts Before Answers
The pressure to move fast was real. The technology team wanted to get building — understandably. But I pushed back — and the service design team held that line. Not to slow things down, but to make sure what was built solved the right problem.
I’ve learned — sometimes the hard way — that jumping to solutions before a team has a shared understanding of the problem is one of the most expensive mistakes you can make in a transformation project.
The first thing I built was a service blueprint that mapped the PDD service end-to-end: every touchpoint, every system dependency, every place where a caseworker had to leave one tool and pick up another, every spot where a policy created a downstream operational problem.
It wasn’t a pretty document. It was a mirror — and what it reflected back to leadership, business teams, and the delivery team was often uncomfortable. Processes that had never been questioned. Gaps that had been normalized. Duplication that everyone assumed someone else was responsible for.
That blueprint became the foundation for every conversation that followed.
Co-Designing With the People Who Know
The Assessment of Needs redesign was where things got concrete.
The form was a product of its time — fixed, linear, no conditional logic, no way to skip irrelevant sections. Caseworkers were manually re-entering data that had already been collected elsewhere. And until recently, a digital option didn’t exist — the whole thing happened on paper, in person.
Rather than redesigning it ourselves, we went to the caseworkers — not to validate a prototype, but to co-create the logic, flow, and even contents of the form — before we even had one. We needed to understand how they thought about the questions, what sequence made sense, where the current form created confusion or unnecessary repetition, and what data fields were non-negotiable, the ones that couldn’t be skipped no matter what.
This was never just about good practice — it was the only way to get it right. Caseworkers carry the realities of this service in their heads — the edge cases, the exceptions, the human complexity that no policy document captures. They were the experts. We were there to structure what they already knew.
And because they helped build it, they were invested in it. That matters more than most teams realize when it comes to adoption.
Five Days That Changed the Direction
One of the clearest turning points was a five-day MVP planning workshop — a structured process designed to build shared understanding before anyone locked in scope.
We came in with a question rather than an answer: What problem are we actually solving, and for whom?
The work was carried out in three distinct phases. First, discovery workshops with business units and caseworkers — building a shared understanding of the service landscape, the pain points, and the gaps. Then, a five-day MVP planning workshop with the product and delivery team — working through the problem space, mapping dependencies, and separating foundational requirements from future enhancements. Finally, alignment workshops with executive leadership — confirming policy decisions before the build effort was committed.
By the end, we had something more valuable than a backlog. We had alignment — a shared reason for building what we were building, a tight scope everyone had committed to, and a clear picture of what was in, what was out, and the effort each piece would take. Scope creep doesn’t happen because teams are careless — it happens because the boundaries were never made explicit.
Eighteen Months Later
The MVP launched within 18 months — longer than originally scoped, but grounded in what the service actually needed. Two foundational capabilities replaced two legacy systems that had become fragmented and difficult to maintain: an Assessment of Needs tool — logical, branching, digital — and CIMS, the Case Information Management System, built around how caseworkers actually work rather than how the old system assumed they did.
That foundation changed how the team operated going forward. The roadmap stopped being a wish list and became a plan — we knew which problems to solve next, who needed to be in the room, and what realistic delivery would look like. That kind of clarity sounds obvious. At the start of this project, it didn’t exist.
What I’d Do Again
Co-create earlier. Hold the line on discovery even harder.
The moments where this project worked best were the moments we slowed down enough to resist the first idea — and instead asked what the people using the service needed, how they thought about it, and what their reality looked like on the ground. The builder is rarely the user. And when you skip that step, you don’t just build the wrong thing — you build it with confidence.
Transformation isn’t a technology problem. It’s a clarity problem. And that’s exactly what service design, done well, is built to create.
