Integrating a standalone UBI app into a unified, trustworthy experience

TD MyAdvantage rewards safer driving with personalized discounts. With ~150,000 active users and a 40% closing ratio, the program had strong adoption — but engagement had plateaued. Users lacked confidence in what was being tracked, didn't trust the scoring system, and found it frustrating to toggle between apps.

As UX Lead, I was tasked with integrating MyAdvantage into the main TD Insurance mobile app — a full experience rethink built to address real user concerns, preserve existing functionality, and support future growth.

Three pain points driving disengagement

Five design objectives

• Unify the experience by integrating MyAdvantage into the main TDI app
• Improve transparency around data collection and scoring
• Build trust through clear UI and feedback mechanisms
• Promote deeper engagement through personalised tips and milestones
• Mitigate migration risk by maintaining continuity for existing users

Discovery, design, and migration — in that order

Discovery & Research

• Facilitated workshops with internal stakeholders and frontline support teams to map pain points
• Synthesized research from usability sessions and app store reviews to define opportunity areas
• Collaborated with legal and privacy teams to align on compliant yet user-friendly communication

Experience Design

• Reimagined onboarding to clearly explain what data is collected, how it's used, and how it benefits the user
• Designed a new driving behaviour dashboard with intuitive feedback, visualizations, and educational tips
• Simplified navigation so MyAdvantage feels like a natural extension of the broader app

Migration Strategy

• Designed flexible transition flows to preserve user progress and score history during migration
• Developed proactive communication templates to inform users ahead of the switch and reduce anxiety

Legacy experience

The original standalone MyAdvantage app — showing the score-only dashboard with no breakdown, no context, and no connection to the main TD Insurance app.

Redesigned experience

The new integrated experience — transparent score breakdown, trip progress, personalised tips, and a unified home inside the TD Insurance app.

Measurable impact post-launch

How do you redesign a government service used by millions of people when the technology behind it is decades old, the service spans multiple products, and every interaction has policy, operational, and accessibility constraints?

I'm part of the team transforming Ontario's driver and vehicle services, working across public-facing, counter, and internal experiences. My focus is on Driver's Licence and Ontario Photo Card services, the counter experience, and exploring how AI can make these services simpler, faster, and more efficient.

At the counter, DVIS is replacing a 40-year-old system that supports more than 75% of in-person transactions. The project is projected to reduce manual work and hotline calls while speeding up completion across services used by 10.6M drivers, 13.5M vehicles, and 60,000 bus and truck companies.

The system was making people learn the complexity

Ontario's driver and vehicle services are used by millions of people every year, both online and at ServiceOntario locations. Behind these services, however, much of the experience has been supported by technology that was designed decades ago.

For counter staff, the experience was especially difficult. The system was text-based. Staff had to remember codes and syntax, navigate using the Enter and Tab keys, and rely on their own knowledge to know which steps to take. The system didn't always guide them through the process, and important policy rules weren't necessarily built into the workflow.

When something went wrong, recovering from the mistake could be just as difficult. A payment failure, photo-capture issue, or data-entry mistake could mean backing out of the transaction, starting again, and sometimes processing a refund before trying again.

Over time, experienced staff learned how to work around these limitations. But that created another problem: a lot of the knowledge needed to use the system effectively lived in people's heads. For a new employee, getting comfortable with the system could take around a year.

That became one of the biggest things I wanted to understand. Why was the system making people learn the complexity instead of helping them through it?

Current state: the legacy text-based system, numbered menus, memorised codes, and dense record screens that staff had to navigate from memory.

Hands-on, end to end, across both sides of the service

I'm the Lead Product Designer on this work, and I stay hands-on throughout the process, from research and problem framing through design, prototyping, validation, and developer handoff. I focus primarily on the Driver's Licence and Ontario Photo Card experiences and the counter experience, as well as AI-driven opportunities across the service.

I also run research myself. That means talking to both sides of the service:

• The people using government services
• The staff delivering those services

I find that especially valuable because it gives me a view of the service from both perspectives. I'm not just looking at what happens on a screen. I'm trying to understand what happens before, during, and after the interaction.

I work closely with product owners, business analysts, engineering, policy, accessibility, and data teams, and I also coach other designers through critique, feedback, and mentorship.

The system was fighting the person using it

One of the clearest insights from research was that the system fights the person using it. Staff had developed their own ways of getting around the limitations of the technology. They knew which codes to use, which sequence to follow, where to look for information, and what to do when something went wrong.

That experience was valuable, but it wasn't scalable. It also meant that the system wasn't really helping staff do their jobs, the staff were compensating for the system.

The "dinosaur" comment from our research captured it perfectly. It wasn't really about how the interface looked, it was about how much effort staff had to put into making the system work.

Move the complexity from people into the product

At first glance, the problem could have been framed as: "How do we modernize the old counter application?" But that felt too narrow. The real opportunity was to rethink how the service supported staff.

Instead of asking staff to remember codes, policies, and recovery steps, what if the system could carry more of that complexity for them? That became the foundation of our approach. We focused on three things:

Deciding where the complexity should live

There was an interesting tension here. Experienced staff had become very efficient with the old system because they knew all the shortcuts. A more guided experience could potentially feel slower for someone who had been using the system for years.

We had to decide what mattered more. We chose to prioritize making the correct path easier and reducing costly mistakes, even if that meant adding some guidance for experienced users.

For me, this was an important design decision because it wasn't about making the interface look better. It was about deciding where the complexity should live. The old system put much of the complexity on the staff. The new experience puts more of it into the product.

Designing around what the person is trying to accomplish

Another thing we changed was how staff think about a customer's request. The old experience treated services more like separate transactions.

We introduced a shopping-cart approach so staff can add multiple products and complete them together. This means they don't have to repeatedly enter the same information or start a completely separate process for every service.

It's a small example of a bigger shift: we're designing around what the person is trying to accomplish, rather than how the old system happened to structure the transaction.

People will make mistakes, the product should help them recover

One of the simplest but most important improvements is what happens when something goes wrong. In the old experience, an error could mean backing out of the entire transaction and starting again. That's frustrating for staff, but it also affects the person standing at the counter.

We designed the new experience so staff can correct errors within the transaction instead of throwing everything away and starting over. The principle is simple: people will make mistakes, and the product should help them recover.

Reduce cognitive load without taking the decision away

Another challenge was that staff shouldn't have to remember every policy rule themselves. We started bringing those rules closer to the point where staff make decisions.

For example, the system can help ensure that a pickup truck is registered appropriately as a commercial vehicle based on the information being entered. Instead of expecting someone to remember the rule or look it up separately, the system can help guide the decision.

This is one of the areas where I think good product design can make a real difference in government services: the product can reduce cognitive load without taking the decision away from the person.

Three products, one connected service

The counter experience is only one part of the service. The broader transformation includes three connected products:

I don't see these as three separate products. I see them as three parts of the same service. A person might start online, continue at a ServiceOntario location, and have their information ultimately managed through the internal system.

That means a problem in one part of the service can create problems somewhere else. Looking across all three experiences helps us design for the whole journey rather than optimizing one interface in isolation.

A human-in-the-loop approach to AI

AI is another part of my role on this work. I'm interested in AI beyond simply adding a chatbot to an existing service. The more interesting question is: where can AI actually reduce the amount of work people have to do?

That could mean helping staff understand complex information, reducing repetitive work, supporting decision-making, or helping people navigate a complicated service.

But government services also come with a high level of responsibility. People need to understand what is happening, know when a decision is being made, and be able to trust the system. So I'm thinking about AI through a human-in-the-loop approach:

• What should the system do automatically?
• Where should it assist?
• Where should a person remain in control?

Research is continuous, not a one-time phase

I work in three-week design sprints and bring research into the process continuously. I don't treat research as something that happens once at the beginning of a project.

At the start of a sprint, I talk to users and staff to understand what's happening and challenge our assumptions. Then I use what I learn to shape the next design direction. I prototype early so the team can react to something tangible rather than debating abstract ideas. I test the designs, learn what isn't working, and bring those findings back into the next iteration.

It's a continuous loop rather than a straight line.

Helping many perspectives make decisions together

This work involves a lot of different perspectives. I work closely with:

• Product owners
• Business analysts
• Engineering
• Policy
• Accessibility
• Data science
• Other designers

A big part of my role is helping these groups make decisions together. Sometimes that means facilitating a workshop. Sometimes it means challenging an assumption. Sometimes it means taking a complex policy or technical constraint and finding a way to translate it into something people can actually use. And sometimes it means helping the team understand that the problem we're trying to solve isn't the problem we started with.

Validated direction, phased rollout

The new experience isn't live yet, so I'm deliberately not presenting projected numbers as results. We have defined success around:

• Reducing the time it takes new staff to become comfortable with the system
• Reducing errors and transaction back-outs
• Reducing manual work
• Making policy easier to apply correctly
• Helping staff complete transactions more efficiently

Good design puts complexity in the right place

This project has reinforced something I've learned throughout my career: complex products don't become simple just because you give them a cleaner interface.

The hard part is understanding where the complexity comes from and deciding what the product should take on versus what the user should have to manage. In this case, the old system made staff carry a lot of that complexity. Our job is to move more of it into the system.

And for me, that's what good product design is about: making difficult things easier without hiding the things people need to understand or control.

A look at the new counter: Renew Photo Card

So far I've designed 12 transactions in the new Driver and Vehicle Internal Solution (DVIS). The screens below are just a few from a single transaction, for consistency, every transaction follows the same pattern.

Some screens, project details, technical information, and internal artifacts have been intentionally omitted because the project is still in progress and subject to confidentiality restrictions.

Role

Lead Product Designer

Organization

Ontario Government / ServiceOntario

Focus

Driver's Licence, Ontario Photo Card, Counter, AI experiences

Scope

Public, staff, and internal service experiences

Methods

User research, service design, journey mapping, interaction design, prototyping, usability testing

Collaboration

Product, Engineering, Policy, Accessibility, Business Analysis, Data Science

Delivery

Three-week design sprints · Research through implementation

Online services exist, but getting something done is still hard

Online government services already exist, with 1.5M monthly views, but getting something done online can still be surprisingly difficult. People often have to figure out which service they need, whether they're eligible, and what information they need before they can even start.

Once they begin, they may move through several separate workflows, each with its own steps and requirements. And after they're done, they're often left to remember when they need to renew something or take another action.

The result is friction for everyone. People abandon applications, call for help, or visit a ServiceOntario location for something they could potentially have completed online. For the government, those unfinished applications and unnecessary visits also create additional cost and operational pressure.

So the opportunity wasn't simply "How do we make the forms better?"

It was: "How can we help people from the moment they have a need, all the way through to getting it done?"

A proactive, AI-powered assistant, not a collection of transactions

We started thinking about the online experience as more than a collection of government transactions. The goal was to create a proactive, AI-powered assistant that could help people:

Instead of making people navigate government based on how the organization is structured, we wanted the experience to start with what the person is trying to accomplish.

Designing for different relationships with the service

Not everyone using the service has the same relationship with the platform. We designed around three levels:

The principle was simple: the more we know about you, the more useful the service can become. But personalization also creates responsibility. The more information we use, the more people need to understand what we're doing with it and why. That became especially important when we started exploring AI-powered identity verification.

Not a technical problem, but a trust problem

One of my clearest findings from our public research was also one of the most important:

That changed the conversation. This wasn't primarily a technical problem. It was a trust problem. People wanted to know:

• Why do you need my face?
• What exactly are you doing with it?
• What happens to my photo?
• Who can see it?
• Can I opt out?
• What happens if the AI gets it wrong?

We couldn't expect people to trust the technology simply because we told them it was secure. We had to design an experience that earned that trust.

Three approaches, one hard choice

To complete certain services online, we need to establish that the person is who they say they are. We explored three approaches.

I chose passive liveness. It was the harder option. But we believed it gave us the best opportunity to create an experience that was both secure and inclusive.

In government, everyone is the user

This was one of the biggest differences between designing this and designing a typical commercial product. A commercial product can sometimes define its target audience. Government can't. Everyone is the user. That includes:

• Older people
• People with disabilities
• People with lower digital literacy
• People using older phones
• People in poor lighting conditions
• People with limited English proficiency
• People who may simply be uncomfortable with new technology

If the identity check doesn't work for one of these groups, they don't just have a bad experience; they may lose access to a public service. So inclusion wasn't something we could add later. It had to be part of the design decision itself.

Why we don't ask people to blink or turn

Many identity verification experiences ask people to perform an action: blink, turn your head, follow the dot. These interactions may work well for many people, but they introduce unnecessary barriers for others.

I chose a single guided capture instead. There is nothing to perform. The person simply positions themselves in front of the camera and follows the guidance.

There was a genuine trade-off here. Active checks can provide a stronger signal. But we chose to prioritize an experience that more people could successfully complete. For the cases where the system isn't confident, we designed a human fallback.

Don't let the camera fail silently

One of the most important design decisions came from thinking about what happens when the capture doesn't work. A generic error message like "Verification failed." doesn't help anyone. It doesn't tell the person what went wrong or what they should do next.

So instead, I designed the experience to coach people while they're capturing their image:

• Move a little closer.
• Find a brighter place.
• Hold still.
• Make sure your face is inside the frame.

Most first attempts don't necessarily fail because the person did something wrong; lighting and framing can make a huge difference. So rather than waiting until the end to tell someone they failed, we help them while they're doing it. Even something as simple as showing "Step 2 of 3" helps communicate that they're making progress and are almost done.

Failure can't be a dead end

This became one of our strongest principles: a face check can never lock someone out of a service they're entitled to.

I designed failure to be gentle. The language doesn't blame the person. I limit retries rather than allowing someone to get stuck indefinitely. And when the system can't complete the verification, we provide another path to complete the transaction.

Consent as part of the experience, not a checkbox

The research told us people were concerned about the AI. So we addressed that concern directly. I worked closely with Legal and Privacy to make consent part of the experience rather than treating it as a checkbox. Before the capture begins, people need to understand:

• What is about to happen
• Why we need it
• What happens to their information
• What we retain
• What happens after processing

We also deliberately avoid exposing security details that could make the system easier to circumvent. The goal is to be transparent about what people need to know without revealing information that could compromise the security of the experience.

When accuracy differences become access issues

Trust isn't only about explaining the technology. It's also about making sure the technology works for people. Face-matching and AI systems can perform differently across factors such as age, skin tone, and gender. In a commercial product, that might be treated as a product quality issue. In a government service, it can become an access issue.

That's why I am testing with diverse groups intentionally rather than assuming that a system that works well for the average user will work well for everyone. I am looking at:

• Completion rates
• Failure rates
• Differences between user groups
• Device and environmental conditions
• How often people need human assistance

And if one group is struggling more than another, the answer isn't "those users need to try harder." It's "we need to fix the experience."

Use AI where it helps, and fail responsibly

At a high level, the identity verification journey is intentionally simple:

But there is another layer running through every step: a path to a human. That's important because AI doesn't have to be perfect to be useful. But it does need to fail responsibly.

From disconnected transactions to one continuous relationship

The identity experience is only one part of the larger online transformation. We're designing the online service so that people don't have to understand how government is organized in order to get something done. The long-term experience should help people:

The goal is to move from a collection of disconnected transactions toward a service that feels more like one continuous relationship with government.

Research at the center, across many disciplines

I led the product design work from research through prototyping and validation, working across product, engineering, AI/ML, Legal, Privacy, accessibility, and policy.

Research played a central role. I used conversations with the public to understand trust, expectations, and barriers. I also looked at the staff side of the service to understand what happens when an online journey eventually reaches a ServiceOntario location. That helped me think about the experience as a service rather than simply an online interface.

Success defined, not yet claimed

The experience isn't live yet, so I don't want to claim outcomes we haven't measured. Instead, we've defined what success should look like. We want to see:

• More people completing renewals online
• High completion rates
• Fewer people abandoning the identity verification process
• Consistent completion across different user groups
• A manageable rate of human fallback

The last point is especially important. If one group needs human support significantly more often than another, that's something we need to investigate. We shouldn't measure success only by the average user.

A phased rollout that learns from real usage

Useful enough to help, transparent enough to trust, inclusive enough for everyone

This project has pushed me to think about AI product design differently. It's easy to focus on what AI can technically do. The harder question is: should we use it here, and what does the experience need to look like for people to trust it?

In government, that question becomes even more important because you don't get to choose your users. Everyone is your user. That means accessibility isn't an edge case. Trust isn't a nice-to-have. And when AI makes a mistake, there needs to be a way for a person to step in.

That's the kind of AI experience I want to design: useful enough to help, transparent enough to trust, and inclusive enough that everyone can use it.

A look at the redesigned ServiceOntario

Some screens, technical details, model information, internal artifacts, and implementation details have been intentionally omitted because the project is still in progress and subject to confidentiality restrictions.

Role

Lead Product Designer

Organization

Ontario Government / ServiceOntario

Focus

Proactive online service & AI-powered identity verification

Scope

Public online experience, consent, capture, and human fallback

Methods

User research, service design, interaction design, prototyping, usability testing, inclusive testing

Collaboration

Product, Engineering, AI/ML, Legal, Privacy, Accessibility, Policy

Status

Soft-launch planned Sept 2026 · phased rollout

Transforming how 3M+ customers manage their insurance

As Lead Experience Designer, I led the transformation of TD Insurance's mobile and web experiences — elevating how over 3 million customers interact with their home and auto policies. Historically, the app served as a basic gateway to a responsive web view, lacking native interactions and personalization.

I partnered closely with product and engineering to identify user pain points, leverage the new design system, and deliver modern self-serve features that enabled customers to confidently manage policies, submit claims, and handle billing — all from their devices.

Redesigning a broken claims experience

The auto claim process was confusing and disconnected. Users had to re-enter information they'd already provided, navigate a fragmented flow, and deal with poor visibility into claim status — leading to frustrated customers and a spike in call center dependency.

Claim Submission

Claim Status Tracker

Going native to build trust and completion

The embedded web iframe used for billing created a disjointed, slow, non-native payment experience — leading to drop-offs, payment errors, and diminished trust.

A personalized home for insurance management

The original dashboard lacked personalization and wasn't aligned with the new design system. It offered limited navigation and failed to surface relevant entry points tailored to individual user needs.

Legacy Version

New Design

Rescuing a mid-stream project — and winning Project of the Year

I led the end-to-end redesign of TD's Canadian Commercial Banking platform, focusing on simplifying complex workflows and aligning the experience with the evolving needs of over 1 million business clients. Our mandate was to modernize core digital banking experiences across money movement, account activity, and user management — and design a scalable future-state vision for ongoing business innovation.

Why this mattered

• Streamline high-frequency workflows like transactions, account review, and user authorization
• Reduce friction and error risk in key tasks
• Deliver long-term customer retention by improving control, visibility, and personalization
• Align with TD's digital-first innovation roadmap for business banking

What we heard from clients

Money Movement & Account Activity

User Authorization & Access Control

Dashboard Personalization

Lasting results

One adaptive flow for all business loan products

I led the redesign of the digital loan application experience for TD's U.S. small business customers — supporting multiple loan products within a single, scalable interface. By rethinking the end-to-end flow, we significantly reduced friction and elevated digital adoption, enabling business clients to apply confidently without branch support.

What was breaking the experience

Four experience transformations

Selected screens — web & mobile

Digitizing a paper-based compliance process

Imagine a small mom and pop shop with five employees. They're not sure of Ontario's employee regulations, so for the past four statutory holidays they haven't paid overtime. This is a violation.

The Ministry of Labour has Officers who investigate companies to ensure they're abiding by Ontario regulations. Sometimes Officers request a company complete a "Self Audit" — reviewing their own records to get up to compliance standards. Before this project, Self Audits were done manually on Excel, paper, or even napkins.

I set out to digitize the Self Audit — allowing Officers to request audits digitally, employers to enter data online, and the system to automatically calculate whether they're meeting compliance standards.

Designing for opposite mental models

Aligning on shared goals early

I led the Goals exercise as early as possible to gain a shared understanding of high-level goals and surface competing priorities. This helped the team decide where to focus time and effort throughout the project.

Proactively surfacing project risks

I led a session that gave the team a forum to share fears and concerns openly and proactively mitigate issues — producing a prioritized list of action items to get ahead of risks before they became blockers.

Building empathy for both users

I led the team in building two personas — an Employment Standards Officer and an Ontario Employer — to give everyone a clear vision of the people using this software and build genuine empathy for their very different needs.

Defining the highest value for each user

Starting as a sketching activity to generate moments of delight, then turning into a writing activity, I led the team in defining the highest value this product could deliver for both the Officer and the Employer.

Mapping the full self-audit journey

I led the team in mapping all steps of a self-audit from the Officer's and Employer's perspective. Yellow post-its = current experience. Purple post-its = future digital experience. This gave the whole team a shared understanding of the audit process complexity and a document to reference throughout delivery.

Interview prep with 6 Employment Standards Officers

Instead of a rigid questionnaire, I organized interview questions into a topic map — clusters of related themes so conversations felt natural. I then led 6 exploratory interviews with Officers from across Ontario.

Synthesizing 6 Officer interviews

After completing interviews with Officers from across Ontario, I led the synthesis — color-coding each interview and grouping insights by key themes to surface patterns and design priorities.

Full-team sketching before going digital

I ran a sketching workshop where the entire team — not just designers — sketched basic wireframes to express ideas visually. This aligned the team on direction before investing time in digital wireframes, reducing rework significantly.

Selected screens

I designed a guided, step-by-step digital self-audit experience — from the Officer's letter request through to the employer completing the audit and the system calculating compliance automatically.

Digitizing 17,000 annual claims end to end

A claim is a complaint by an individual alleging a violation of the Employment Standards Act. With an average of 17,000 claims filed per year, the Ministry needed a digital system to handle intake, processing, officer review, and resolution — replacing a largely manual, paper-based process.

I focused the work on two key user groups: the Claimant (Clancy) — the person filing the claim — and the ERO (Melissa) — the Early Resolution Officer who investigates and resolves claims.

Kickoff workshop — April 2019

I ran the kickoff to align stakeholders and the team. Through a series of workshops I led, the team learned about the business, stakeholder goals, and the claims process before any design began.

Who is involved in the claims process?

I led a stakeholder-mapping session where the team wrote names, roles, and key project interests on sticky notes, grouped teams together, and used arrows to show connections. Key groups: LTC Cluster, ITS, SDC Project Team, MOL Execs, Employment Standards, Legal, Privacy, and Data Management.

Identifying and ranking project risks

I hosted a risk workshop where each team member listed their top 5 risks, then guided the team in ranking them on a 2×2 grid: Y-axis (high vs. low risk) and X-axis (easy vs. hard to mitigate).

Meet Clancy and Melissa

I guided a personas workshop that created real people the team could relate to and build empathy for. Claimant Clancy and ERO Melissa shaped every design decision throughout the project.

What does each user need most?

Understanding our two key users

I chose to focus on Claimants and EROs — the two groups most involved in the claims process that we knew the least about.

Mapping the full claims journey

I mapped the current paper process from claim submission to closure — highlighting all key players, stages, and average time in each queue. This service blueprint became our north star throughout the project.

Interview prep & topic mapping

I led interviews with 5 EROs across a full day. Beforehand, I organized a session where each team member wrote potential questions, then consolidated the top ones into a topic map — clustering by themes: a day in the life of an ERO, the current system (ESIS), the claims form, claims process, and employers/claimants/documents.

Synthesizing insights from 5 ERO interviews

I ran a synthesis session where each interview was color-coded and key insights grouped by theme. This affinity mapping surfaced the patterns that drove our design priorities.

Mapping assumptions on a risk/validation grid

I guided the team in mapping assumptions on a 2×2 grid: Y-axis (high vs. low risk) and X-axis (hard vs. easy to validate) — to prioritize what needed research before we could make decisions.

MLTSD 360 Claims Investigation Assignment Algorithm

Ranking violations and industries by complexity

I partnered with MOL Subject Matter Experts to rank employment standards on a 2×2 grid — most contravened vs. least contravened on Y-axis, and most complex vs. least complex on X-axis. We did the same for industries.

Finding our skateboard

I led the team to our "golden nugget" — inspired by the Agile skateboard analogy — the portion of the future service blueprint where we chose to start. We focused on collecting better data and guiding Claimants through the claims process as the highest-value starting point for both Claimants and EROs.

From insights to first sketches

I broke the intake form into scenarios, wrote goals for each, and created a real-life scenario for Claimant Clancy. I then ran a sketching-and-critique workshop where the team sketched solutions and critiqued them digitally using Zeplin.io.

Selected screens

Expanding a permit system into a full land development review platform

The Ministry of Transportation implemented HCMS in 2017 — a web platform where clients submit permit applications, connect with MTO staff, track reviews, pay fees, and receive permits entirely online. MTO then sought to expand HCMS to support the full land development review process: from pre-consultation through to permit issuance.

A system that couldn't connect stakeholders

Understanding who uses the system

I facilitated a sprint to map out the key user personas — land developers, municipalities, and MTO staff — capturing their goals, frustrations, and workflows before touching any design.

Mapping the problem space

I facilitated the workshops where the team documented the full problem statement — mapping all the gaps, pain points, and missing capabilities that needed to be addressed in HCMS 2.0.

Mapping the full land development journey

I facilitated the mapping of the complete end-to-end user journey — from initial pre-consultation through land development review to final permit issuance — identifying every touchpoint, handoff, and gap in the current process.

Final screens

The final high-fidelity designs delivered a connected, end-to-end platform — from main menu navigation through submission, review, search, and permit management.

Enabling flexible government workspaces during COVID-19 recovery

With a growing number of Ontario Public Service employees working from home, the government wanted to explore "regional hubs" — allowing employees to work from an office near their home rather than their assigned ministry. The goal was to support COVID-19 recovery by reducing transit pressure and enabling flexible working environments.

To achieve this, employees needed the ability to share desks by reserving them at different times at locations nearest to their home.

Four organizational goals

Goals workshop

Risk & mitigation mapping

Roles & permissions mapping

Value proposition

Work from GOV Office — Employee journey

Market scan & competitive landscape

Final screens

Designing a drag-and-drop widget system for club websites

I joined the Jonas Software team to design various widgets for their platform — enabling users to easily build their custom websites by dragging and dropping components. Jonas serves golf clubs, hospitality venues, and recreational facilities across North America.

The work involved designing wireframes for each widget type and then refining into final visual designs that could be customized by clients to match their brand.

From wireframe to polished widget

Each widget was designed starting from low-fidelity wireframes that the full team could critique and align on — before moving to high-fidelity final designs flexible enough to accommodate different club brands.

Customized website previews

The final customized websites built using the Jonas widget system — demonstrating how drag-and-drop components come together into polished, branded club websites.

A shared design language for the Ministry of Labour

I designed and created the MLTSD Design Style Guide to ensure complete uniformity in style and formatting across all digital products built within the Ministry of Labour, Training and Skills Development.

Before this guide existed, each product team was making independent visual decisions — creating inconsistency across the self-audit tool, claims processing system, case management portal, and other Ministry products. The style guide became the single source of truth for colour, typography, components, spacing, and interaction patterns.

Brand colour palette

A consistent colour system ensuring all Ministry digital products share the same visual identity — meeting accessibility contrast requirements and aligning with Ontario government brand standards.

Type system

Defined heading scales, body text, labels, and helper text — with clear hierarchy rules to ensure readability and consistency across all screen sizes.

Interactive components

Form patterns and layout grid

Padding system and icon assets

Data display and navigation patterns

Designed and built from scratch for 15+ companies

At Three Point Turn I designed and developed the frontends for over 15 prominent customer-facing companies from scratch — including all graphic assets, interactions, and responsive layouts. Each project was fully custom, built to reflect the brand identity and business goals of each client.

Six featured projects

Helping Ontario workers understand what they're entitled to

A large number of employees in Ontario were not being paid what they're entitled to — and many employers simply weren't educated in the Employment Standards Act. My goal was to create a tool that fills that gap.

While building the Self-Audit application, I saw in employer interviews just how difficult it is to understand complex employment standards like Public Holiday Pay. If employers were struggling, employees likely were too — which sparked the idea to leverage our Self-Audit work and build a public-facing hybrid tool.

Designed for both sides of the employment relationship

Double diamond from day one

Every project at SDC starts with a Discovery & Framing phase — an intensive few weeks where the team sits together full-time to understand the software we're about to build. Coding is expensive and hard to change, so my goal was to reduce risk before a line of code is written.

Understanding who was involved

I kicked off a stakeholder-mapping session: everyone wrote their name, title, and a key quote describing what they cared about on a large post-it, then I grouped teams, drew connecting arrows between relationships, and added external stakeholders and key funders — giving the whole team visibility into the ecosystem around the project.

Surfacing and prioritizing project risks

I hosted an open forum for the team to share fears and concerns candidly. Top risks identified: funding deadline unknown with a new government forming, remote team members, no budget for user-testing incentives, an office relocation, and multiple stakeholder groups (LSB, CMB, EOP) creating red tape.

Building empathy for our two users

I guided the team in creating real personas — an Ontario Employee and an Ontario Employer — to give everyone a clear vision of the people using this software and build genuine empathy for their needs and anxieties.

Employment Standards web analytics

Before building anything, I dug into the existing web analytics from the Employment Standards website — pinpointing which standards users searched for most, where they dropped off, and what questions came up most often.

Preparing for exploratory interviews

Instead of a rigid list of questions, I organized interview topics into an affinity map — clusters of related themes so conversations felt natural. It became our reference guide during interviews with both employees and employers.

Synthesizing & prioritizing interview findings

After the exploratory interviews, I drove the synthesis — grouping insights by theme and prioritizing by frequency and impact. That work directly shaped the scope and design priorities for the tool.

Selected screens

I designed a fully anonymous, self-serve compliance tool that lets any Ontario worker or employer check their entitlements for Public Holiday Pay, Overtime, Minimum Wage, and non-monetary standards.

Modernizing how Ontario Officers manage thousands of cases

The Case Management system is the central tool used by Employment Standards Officers (ESOs) across Ontario to track cases, log correspondence, manage payments, generate letters, and store all data related to both inspections and claims.

I led the design of three interconnected products: the Officer case management tool, an executive dashboard for managers to assign and track cases across districts and regions, and an admin panel for Business Systems Analysts (BSAs).

Three products, one mission

Personas workshop

To gain a shared understanding of who was actually using this software, I ran a personas workshop — building empathy for users and visualizing their characteristics, motivations, and daily challenges across two core user types: Employment Standards Officers and Ministry Administrators.

Roles & permissions mapping

Before designing any screens, I led a session to map out user roles and their associated permissions — ultimately reducing the number of roles needed for the initial launch down to only those that were absolutely necessary. This exercise directly shaped the information architecture and access control model.

Interview prep & topic mapping

I organized interview questions into a topic map — clustering related questions around common themes so interviewers could have natural conversations with ESOs while covering key areas: a day in the life, the current system (ESIS), the claims process, employer interactions, and document management.

Research synthesis

After every round of research, I guided a synthesis exercise to analyze interview findings. Results were color-coded by interview and grouped by key insight — making it easy to spot recurring themes across different ESOs and regions.

Scenario writing & sketching workshop

After prioritizing the highest pain points for Officers, I moved the team into framing — starting with scenario writing to define specific user situations, then group sketching to visualize potential solutions. I got the full team sketching before going digital, so everyone was aligned before a pixel was placed.

Selected high-fidelity screens

A selection of the final high-fidelity screens, spanning three distinct but connected interfaces — the Officer case management tool, the Manager executive dashboard, and the admin panel — each tailored to the specific role and workflow it served.

Manager Executive Dashboard

Gave regional managers a real-time overview of all cases across Ontario — with assignment controls, workload distribution, and district-level tracking.

Officer Case Summary

The core Officer tool — a single view of everything on a case: dates, employer data, correspondence history, payment tracking, and quick actions for generating letters and logging notes.

ESO Dashboard & Contacts

The Officer-facing dashboard surfaced the active caseload with priority indicators — and a contacts screen gave instant access to all employer and claimant information linked to each case.

Streamlining employment standards inspections across Ontario

A digital tool designed to streamline the employment standards inspections conducted by the Ministry of Labour. The project followed a Discovery and Framing methodology — identifying challenges and shaping an MVP through workshops and user research before development began.

Five stages of an inspection

Before designing anything, I mapped the end-to-end inspection journey — from the trigger that initiates a case through to bringing an employer into compliance. These five stages framed every design decision that followed.

Discovery & Framing

Discovery — I led the workshops and user interviews that surfaced the product's potential problems and challenges, then converged them into actionable priorities.

Framing — I led the sessions where we consolidated and prioritized the proposed solutions until the requirements and approach for the MVP were decided.

Stakeholder mapping

I led an early mapping session that identified the key decision-makers, product observers, those with veto authority, and external support resources — giving the team a clear picture of who needed to be aligned and when.

Identifying risks & mitigations

I led a session where the team named the risks that could derail delivery — and planned mitigations for each: data sensitivity around cloud storage, decision-making slowed by lengthy command chains, hard deadlines and compressed timelines, scope outsized for the time available, interference with other MoL360 applications, and resource constraints.

Exploratory interviews

I led exploratory interviews to build empathy and surface recurring topics across conversations, then organized and synthesized the findings to refine the project goals and align the personas more closely with real end-user needs.

Synthesis & affinity mapping

I led the synthesis, grouping findings across all interviews to determine the primary areas of interest and pain points and building affinity maps that surfaced the clearest opportunities for the product to focus on.

Desktop walkthrough

I ran a desktop walkthrough where a former Employment Standards Officer walked the team through a complete inspection scenario, chronologically. We mapped the many locations an inspection touches — office, parking lot, even a subway restaurant — divided the board by lifecycle stage, and documented the pain points and documents produced at each step to find the critical points of friction.

Prioritizing pain points

I led the team in prioritizing pain points on a 2×2 matrix — weighing the value gained from alleviating each issue (assessed by the Product Owner) against implementation difficulty (assessed by the Inspections sub-team) — to focus effort where it mattered most.

The lean exercise — roadmap planning

Throughout Discovery and Framing, I had the team collect ideas in a "locked solution chest" to avoid committing to an approach too early. Once enough research was gathered, I led the team in validating ideas against user insights and prioritizing them into a trial roadmap — exploring direction through iterative discussion rather than guesswork.

Scenario writing & sketching

I wrote realistic scenarios describing how the tool would deliver value — intuitive enough that an officer could navigate the software without formal training. In the sketching workshop I led, team members produced storyboards in tight 10–15 minute rounds, then circulated sketches for peer review and voting. I consolidated the most popular sections and features into high-fidelity mockups.

Usability interviews

I led usability sessions and captured feedback organized by individual user (color-coded) and by sentiment — happy, sad, and opportunities — making it easy to spot patterns across every participant and feed them back into the design.

High-fidelity mockups

I designed the final screens that brought the inspection workflow to life across five connected interfaces — each tailored to a specific moment in the officer's process.

Employer Relationship — OL & LE

Configures the relationship between an operating location and legal entity — the foundation every inspection is built on.

Employment Standards Assessment (ESA)

The assessment interface where officers record findings against employment standards during the inspection.

Compliance Tools

A dashboard of the orders, notices, and actions an officer can issue to bring an employer into compliance.

Contraventions

Documentation and tracking of every contravention found, with the evidence and orders attached to each.

Appeals

A table for managing the dispute process when an employer appeals an order or penalty.