Humanizing Compliance for Vulnerable Citizens
Role: Senior Product Designer
Organization: Government of Canada
Year: 2023
Scope: Service design, product UX, accessibility, policy alignment, stakeholder management
Team: UX designer, product owner, policy advisors, engineering lead, accessibility specialist, call centre representatives
Project overview
This project started with a seemingly simple request
“Put this benefit application online.”
In reality, the service was wrapped in strict legislation and powered by a twenty year old system that could not support even basic branching or conditional logic. The application itself ran close to fifty pages of complex questions and dense legal text. The people using it were often seniors, newcomers, or citizens with low digital literacy.
​
My contribution was to reframe the brief from “build a smart online form” to “design a compliant, humane experience inside hard constraints”. I led policy translation workshops, defined a routing strategy that worked with the legacy backend, and pushed accessibility as a non negotiable requirement rather than an afterthought.
​
The result was a digital service that passed an independent WCAG 2.1 AA audit, reduced clarification calls to the contact centre, and gave vulnerable users a clearer path through a previously intimidating process, without changing a single clause of legislation.
Context and problem
The service is a federal benefit that supports citizens with limited income and complex life situations. Before this work, the application process was:
-
Text heavy and written in legal language
-
Long, repetitive, and cognitively demanding
-
Difficult for people using screen readers or keyboard navigation
-
A frequent source of “what does this mean” calls into the contact centre
On the delivery side, the project was framed by three forces that rarely work in harmony.
-
Policy and legislation
-
Policy teams needed the full legislative text present in the experience
-
Terms like “pursuant to Section 4” and “as defined in subsection” were treated as untouchable
-
-
Legacy technology
-
The core system treated the application as a fixed sequence of fields
-
There was no capacity for “if this, then show that” type logic
-
Rebuilding the system was out of scope and out of budget
-
-
Vulnerable users
-
Many applicants had limited digital skills
-
Some relied on assistive technologies
-
Most were already stressed about their financial situation
-
The net effect for citizens was a wall of dense text and questions that felt endless. For departments, it meant avoidable support load, frustrated users, and a perception that “online” did not actually improve anything.
.png)
Strategy
Designing through the constraints
1. Translating policy into human language
Rather than fighting policy in abstract meetings, I invited policy advisors into the research.
We ran a series of “translation workshops” built around three steps:
-
Observe reality
Policy advisors watched moderated sessions where citizens tried to interpret phrases like “pursuant to Section 4”. They saw how often participants guessed or gave up. -
Name the problem in their language
After each session we paused and asked
“Is this person technically eligible but blocked by wording”
This kept the discussion anchored in legislative risk and program goals, not “UX opinions”. -
Co create helpers instead of removing text
We proposed a pattern where the original legal text remained visible, but sat next to a plain language helper. The helper explained what the law meant, in everyday language, without replacing or editing the legal text.
This shifted the conversation from “legal versus UX” to “how do we preserve the law and make it understandable at the same time”. It unlocked permission for a reusable pattern that would later appear across many steps in the experience.
2. Pivoting from smart form to router
In parallel, we explored a single adaptive form that would show and hide questions based on answers. It did not survive the reality check with engineering.
When the team confirmed that the system could not support any branching, I proposed a pivot.
​
The new strategy used a router model:
-
A short pre screener at the start collected a few key details
-
Based on answers, citizens were routed into one of three static flows that matched common scenarios
-
Each flow remained linear and compatible with the backend but felt shorter and more relevant to the user
-
​
To secure buy in, I walked policy, product, and engineering through:
-
A “before” view with one generic, overwhelming form path
-
An “after” view with three shorter, scenario based paths that still wrote to the same data structure
The router model was accepted and became the backbone of the final service.
Design and execution
Building trust and access
The plain language helper pattern
Once policy accepted the idea of helpers, I turned it into a repeatable pattern instead of a one off.
Each relevant step of the application now included:
-
The full, official legal text shown in a clearly marked “Official legal content” area
-
A “What this means in plain language” helper, implemented as an accordion beneath the legal text
-
A direct relationship between the two so screen reader users could understand how they connect
Interaction wise, the helper pattern was:
-
Focusable and keyboard friendly
-
Clearly labelled when collapsed and when expanded
-
Designed to handle different lengths of helper text without breaking layout
Because it was defined as a pattern, we could reuse it across the form and across other services that faced the same legislation versus comprehension problem.
​
Design decisions and accessibility rules:
• Use directly under official legal text to provide a plain language explanation.
• Legal text stays unchanged; this component only adds context.
• Header is the single focus target; Tab + Enter or Space toggles open and closed.
• Focus ring and colours meet WCAG 2.1 AA contrast requirements.
• Designed for screen reader and keyboard users expansion state is announced clearly.
• Reusable across any form step that includes legislative content.
.png)
​Accessibility as a hard line
From day one, we treated accessibility as a core requirement, not a final checklist item.
We designed and tested for:
-
Screen reader behaviour across headings, landmarks, and labels
-
Keyboard navigation through the router, helpers, and form fields
-
Colour contrast and touch target sizes that met WCAG 2.1 AA
Two weeks before launch, an accessibility audit flagged that our custom date picker:
-
Could not be reached or controlled properly with keyboard
-
Created confusing announcements for screen readers
-
Risked failing compliance and frustrating a subset of users
I made a call that was not popular in the moment
We blocked the release in its current form and reverted date inputs to simpler text fields that passed accessibility checks.
To support that decision I:
-
Presented the audit findings and demoed the failure in a real assistive tech scenario
-
Framed the change as a compliance and equity issue, not a cosmetic preference
-
Proposed a clear alternative that engineering could implement quickly
The team accepted the change and we launched with a simpler but accessible solution.
Process at a glance
I often use a simple flow to describe how I work on complex public sector services. For this project it looked like this:
-
Discover
-
Interviewed contact centre staff
-
Reviewed existing paper and digital materials
-
Identified main risk areas from a policy perspective
-
-
Define
-
Mapped the current citizen journey
-
Documented legal and technical constraints in one shared view
-
Framed the core problem as
“How do we keep the law intact and still make the experience human and accessible”
-
-
Co design and align
-
Ran translation workshops with policy
-
Co created the helper pattern
-
Presented the router strategy and gained support from policy, product, and engineering
-
-
Design and prototype
-
Produced low fidelity flows and content first
-
Designed high fidelity screens using a simple, accessible design system
-
Defined the helper pattern as a reusable component
-
-
Test and iterate
-
Ran usability tests with seniors and newcomers
-
Observed comprehension, navigation, and emotional response
-
Refined copy, sequence, and helper content based on findings
-
-
Launch and follow up
-
Supported accessibility audits
-
Monitored contact centre feedback
-
Shared patterns and lessons with adjacent teams working on similar forms
-
Outcomes and impact
Because this is a public sector service, we measured impact across compliance, operations, and user experience.
Accessibility
-
The service passed an independent WCAG 2.1 AA audit with full compliance reported for the parts in scope
-
The helper pattern and focus states were specifically highlighted as strong practices for future projects
Contact centre and user experience
From contact centre feedback and early monitoring:
-
Staff reported a noticeable drop in “what does this section mean” calls related to the new digital service
-
Citizens were more likely to complete the application in one sitting when guided by the router and clearer copy
Where exact numbers are not available, I describe the trend honestly and avoid claiming ownership of every metric. When the data is available, this is the place to insert it.
Reuse and standardisation
-
The plain language helper pattern was adopted as a model for other services that needed to show legal content without overwhelming users
-
The router concept became a reference example for working around legacy systems without major rebuilds
What I learned
This project changed how I approach constraint heavy environments.
-
I learned to respect which constraints are truly fixed and to move creativity to where it can actually help
-
I saw how powerful it is to bring policy into user research rather than arguing from slides
-
I confirmed that accessibility needs a clear owner who is willing to delay release when basic conditions are not met
In short, my job in this project was not to fight every constraint. It was to decide which battles were worth taking on, which constraints required creative detours, and how to keep the citizen’s experience at the centre while staying within the law.
