Helping Ontarians navigate newly optional auto insurance coverages
Context
Starting July 1, 2024, the Province of Ontario changed several mandatory auto insurance coverages — defined under the Statutory Accident Benefit Schedule (SABS) — to optional. Coverages like income replacement and medical benefits, which were previously automatic inclusions on every policy, became choices customers had to actively make.
This regulation applied to both how insurance is sold and how existing customers manage their policies. As a result, our digital experience across both the sales funnel and the self-serve policy portal needed to be updated before the deadline — in a way that genuinely served customers, not just satisfied the letter of the law.
Private case study
This case study is under NDA
The detailed process, design decisions, and outcomes are available to recruiters and hiring managers.
No password? Request access →
Goal
Meet the regulatory deadline and allow customers to transact on the new optional coverages — while genuinely helping them understand what changed, what it means for them, and feel confident in their decision.
Results
Initial problem statement
How might we help more customers understand the changes coming to their insurance?
Known user problems
1. Customers don't know what's already on their insurance
The biggest hurdle for a coverage transitioning from mandatory to optional is that customers first need to know it exists. Discovery interviews (n=12) revealed a near-zero baseline awareness of accident benefit coverages as a named, discrete thing on their policy.
- 8 of 12 participants could not name a single coverage on their policy
- 10 of 12 assumed accident benefits were just "part of insurance," not something that could change
- Several believed OHIP or their employer's benefits would cover them — unaware their auto policy included income replacement
High-level implication
Before we could present a choice, we had to establish that something was changing. Before we could explain the change, we had to explain what existed. The UX had to do more work than a standard disclosure.
2. Customers don't trust insurance companies
Research and prior brand sentiment studies consistently flagged deep skepticism toward insurance providers. Common refrains included: "they make the rules complicated so you can't figure out what you're paying for" and "if something changes, it usually means they're getting more money and I'm getting less."
This meant a purely transactional experience — "here are your new options, choose one" — risked feeling like a bait-and-switch, even if technically compliant. Any perception that the company was quietly reducing coverage would erode exactly the trust we needed to earn.
High-level implication
The experience had to be visibly neutral and transparent — designed to look out for the customer, not just satisfy a checkbox.
Constraints
As I dug into the problem with my team, three realities shaped our approach:
- Legal oversight — Because this project was tied to regulatory changes, every piece of customer-facing copy required review and approval from the legal team before it could ship. This added review cycles to an already compressed timeline.
- Cross-platform alignment — This was the first time we were designing together across two distinct platforms: the sales funnel and the servicing portal. Different design patterns, different component libraries, different teams — but the same regulation applied to both.
- Timeline — The July 1 deadline was fixed. With two designers and shared engineering resources across two product squads, scope decisions had to be made deliberately and early.
Reframed problem statement
How might we help customers build enough understanding of what's currently on their policy — and why it matters — so they can make a confident, informed decision about whether to keep it? Working with legal stakeholders, aligning two platforms for the first time, and with a fixed regulatory deadline.
Approach
After aligning with the product owner, it became clear that the real challenge wasn't building a feature — it was sequencing the problem correctly. We couldn't ask customers to make a decision about something they didn't know they had. So rather than designing disclosure UI first, we designed an awareness-first experience.
Ideal state vision
A fully integrated coverage education hub within the policy portal — a dedicated section explaining each coverage, its real-world implications, and a direct path to adjust. This version offered the richest experience but required significant content design, engineering, and legal lift.
Near future
A partially optimized experience that embedded the awareness and education layers into the renewal flow, with a simplified decision step. Addressed the core trust concern but required an additional round of legal sign-off on plain-language content.
Minimum Viable Product
A pragmatic version embedded directly in the renewal flow: a progressive disclosure pattern surfacing a high-level summary of the change by default, with expandable detail for customers who wanted more before deciding. Minimal engineering lift, maximum reach — the renewal flow had the highest natural engagement of any touchpoint.
Key insight
One of the earliest directions explored was a modal disclosure — the fastest-to-build option, surfacing the coverage change as an acknowledgement screen at login or renewal.
We prototyped and tested it. Users clicked through in under 10 seconds without reading. One participant described it as "the kind of thing you just agree to to get it out of the way."
This was a critical signal. Compliance-first design was producing exactly the kind of experience that would deepen distrust, not resolve it. If we shipped a modal, we'd meet the legal requirement — but customers still wouldn't understand what they'd agreed to, and call volume would spike.
This realization shifted our focus. Instead of asking "how do we present the options," we reframed around "how do we earn the right to present the options." The awareness and trust layers weren't optional — they were the whole point. This shaped every subsequent design decision, including how we approached the legal copy conversations.
Solution overview
The MVP delivered an awareness-first coverage change experience, embedded directly into the renewal flow where customer motivation to engage was highest. A progressive disclosure pattern showed a clear, plain-language summary of what was changing and why — with expandable detail for customers who wanted to understand more before acting.
Rather than isolating the change behind a disclosure screen, we integrated it into the moment customers were already reviewing their policy — making the decision feel like a natural part of renewal, not an interruption.
In parallel, we established a shared coverage language guide across sales and servicing — the first time both platforms had agreed on consistent terminology, visual hierarchy, and treatment of optional vs. included coverages. This became the foundation for a broader design language initiative in Q3.
We also used evidence from user copy testing — verbatim quotes from sessions showing where legal-approved language caused confusion — to move copy decisions faster than any design argument could. Legal review rounds dropped from an average of 3 to 1.4 in the final phase of the project.
Results
The experience shipped on June 18, 2024 — 13 days ahead of the regulatory deadline — across both the sales and servicing platforms.
Post-launch moderated sessions (n=8) showed all participants could correctly describe what had changed on their policy. 7 of 8 said the experience "treated them like an adult" — a direct echo of the trust concern identified in discovery.