Ontario Roadside Inspection

Client Ontario Ministry of Transportation (Digital Garage)
Role UX lead; all early research, user interviews, and the working prototype.
Timeline 2018 to 2019
Stack AxureRP interactive prototypes (just before Figma), Responsive for desktop and tablet (iPad), Ontario Design System

MTO's roadside truck-inspection process lived on a fixed paper ticketing/review sheet that couldn't change. I led the research and built a working prototype that turned it into a digital workflow officers could start from any edge, save and resume across the roadside, their vehicle, and the inspection office, with role-aware access for officers, managers, and third-party viewers, all designed to actually be buildable.

The problem: a regulated paper sheet that had to be matched exactly

The digital tool had to mirror a fixed form, work in any order, survive weak connectivity, and respect several roles.

• The paper ticketing/review sheet was fixed by regulation; the digital version had to match it exactly.
• Inspections don't happen in one place or one order: an officer might start at the owner/licence side, the truck, or the trailer, and move between the roadside, their vehicle, and the scale/inspection office.
• Connectivity in remote northern Ontario is unreliable, so save-and-resume across devices was essential.
• Different roles needed different rights: officers, managers, and third-party viewers (some able to modify data trackably, others just receiving printouts or derived reports).

It had to match the paper sheet exactly, and still let an officer start from any edge of the inspection and pick it up later from another machine.

Research: remote sprints with officers across the province

Research was fully remote by necessity, officers were spread across Ontario regions. I led Google Ventures design sprints with officers from multiple regions to capture the current state, which became the inputs for the redesign and for user testing. A core team of SMEs then validated and refined the prototype iteratively until we had a fully working version that matched the paper sheet. It was built in AxureRP as interactive prototypes responsive to desktop and tablet; officers tested it on an iPad in mock inspection scenarios.

1. Start from any edge

Officers could begin at the licence/owner side, the truck, or the trailer, and the workflow still held together.

2. Save state at every phase, resume anywhere

A simple UI widget showed connectivity and last-saved state (the dev team built the code behind it). This mattered most up north: pull over a truck, run the roadside inspection, capture data and photos tied to the report, then finish and search/insert the operator and licence info back at the scale facility.

3. Role-aware rights

Officers, managers, and third-party viewers each got the right access, some could modify entered data trackably, others received printouts or derived reports.

4. Design for how it would actually be built

My banking background gave me the states-and-stages thinking, and my dev knowledge of PWA and model-view concepts meant I designed something the developers could build fast, instead of handing over an experience that wouldn't survive the technical constraints.

Built on the Ontario Design System

The Ontario Design System made it easy to a-la-carte interface elements and preset the functionality requirements for components and super-components, so the build inherited consistency.

Results

• Shipped and moved to the dev team (contract ended at handover)
• Banner project for the team (reported after launch)
• Any edge start and resume anywhere (save-state across roadside, vehicle, and office)

The product shipped.

My contract ended when it moved to the dev team.

I was later told it became one of the team's banner projects and measurably improved the quality of work in the inspection process.

Reflection

Not the prototype, the people. I was handed a group of roadside inspectors from across Ontario who I'd been told were disengaged and not interested in being involved. I ran the Google Ventures design sprints fully remote on Miro, deliberately broken into shorter two-to-three-hour sessions across several days instead of marathon full-days, and through careful facilitation and active listening those same officers showed up engaged, spoke with real interest, and pushed hard to make the platform better. That engagement is what made the product good.