People were using paper forms, fax machines, and regular mail to get certified.
To run a water treatment plant in Ontario, workers legally need a certificate. But the old setup for managing these certificates was painfully slow. Everything relied on physical paper. Workers had to print documents, mail physical checks, or send faxes just to submit an application. The result? Major delays, missing files, and no way for anyone to see what was happening.
Reconstructed from interview notes. Some operators waited over 4 months with no meaningful update.
We spent weeks asking workers exactly where the system failed them.
We didn't guess how to fix the software from our office. We sat down with the people who actually use it every day, including people on late-night shifts at water plants and the clerks who process the mail. We watched them work and took notes on what made them frustrated.
The research revealed eight recurring themes across every group we spoke to.
After organizing hundreds of notes from operators, training providers, and government staff, the same frustrations kept surfacing across every role and every region.
Operator records lived in three separate systems that couldn't talk to each other. Staff had to manually re-enter the same name, address, and employment history every time someone applied for a new certificate or renewal.
Once an operator mailed their form, they received no updates. They were left completely in the dark until a physical letter arrived weeks later. Many called the ministry repeatedly just to confirm their paperwork had arrived.
Applications, payments, exam registrations, and course approvals all required physical forms sent by mail or fax. A single missing document could stall a file for weeks, with no way to know it was missing until someone called.
The backend system could not be updated when provincial regulations changed. Staff worked around it by maintaining unofficial spreadsheets and Word documents, creating a shadow system that was inconsistent and error-prone.
Forms and instructions were written in dense legal terminology. Many operators, especially those for whom English is a second language, misunderstood requirements and submitted incomplete applications, triggering back-and-forth delays.
Training organizations submitted course approval requests and then heard nothing for months. Without any status portal, they couldn't tell if their application was under review, rejected, or simply lost in the queue.
Operators had to register for licensing exams through a completely separate process disconnected from their certificate application. Missing an exam deadline often meant starting the entire application cycle over again.
Ministry staff, operators, and training providers all held different versions of the same information. Discrepancies between what each party believed to be true caused disputes, delays, and eroded trust in the overall system.
Mapping out what a better experience could look like.
The research told us what was broken. The journey maps defined what “fixed” should feel like for each person who touched the system. We mapped three journeys: a water worker applying for the first time, a training school submitting a course for approval, and a government employee reviewing an application. These maps became the brief for the design phase.
Five sprints. Each one tested with real operators before moving forward.
We did not design everything at once and hand it over. We worked in short cycles: sketch, build a rough version, put it in front of users, learn, and repeat. This kept the work grounded in what operators actually needed rather than what we assumed they did.
A single place for operators to see all certificates, expiry dates, and renewal steps.
Rewrote every form field in plain language, cutting the application error rate from 60% to under 12%.
Operators could track exactly where their file sat, reducing ministry phone calls by over 40%.
Training organizations could submit courses for approval and track review status without calling in.
A review queue with filters and bulk actions. Staff estimated twice the throughput vs. the old system.
Three dashboards, each designed for a different person in the system.
The future service would consist of multiple interconnected platforms. We designed concept prototypes for each user type and tested them before moving into the sprint phase.
Track experience, training, and applications in one place
Operators could see their full certification journey: work experience, training hours, upcoming renewals, and active application status, all without a phone call.
Submit and manage courses without the back-and-forth
Training organizations could submit courses for approval, track review status, manage sessions, and handle their course portfolio in a dedicated workspace.
A prioritized review queue for the internal team
Analysts got a smart queue with filtering, exam scheduling tools, and application tracking so they could process files faster and with fewer errors.
We tested with 28 users across five sprints. Not everything landed.
In the Alpha phase, we ran five design sprints, developing and testing prototypes with 8 internal and 20 external users. Here is what we heard directly from participants.
Goal-setting was not a priority for operators
Users did not want to set career goals inside the system. They simply wanted to log on, update their work experience, and leave. We removed the goals feature and focused on making profile updates faster.
“I just need to update my hours, not plan my career.”
Work experience tracking caused duplication anxiety
Operators worried about entering work experience data that their employer might also be submitting. We redesigned the flow to show what was already on file and let operators add only what was missing.
“My employer already sends this in. Am I doing it twice?”
The step-by-step application was clearly understood
Users appreciated the structured, linear application flow. Having contextual help text at each step meant they could complete the form without needing to call the ministry for guidance.
“This actually tells me what to put. The old one just had a blank box.”
The biggest lessons came from the moments things did not go as planned.
Government projects move slowly and involve a lot of stakeholders with competing priorities. Here is what we took away from six months of working inside that environment.
Test early, even when it feels too early
The roughest sketches generated the most honest feedback. Participants focused on the concept rather than the visual finish — something polished mockups always prevent.
Plain language is a design decision
Rewriting form labels and help text had a bigger measurable impact on error rates than any visual change we made. Copy is part of the design and deserved the same iteration process.
Build trust with small wins first
Ministry stakeholders were skeptical of change. We made progress by showing small, working improvements early. Each small win earned enough trust to unlock the next phase.
Two shifts that shaped everything we built.
After research, testing, and five design sprints, everything pointed back to two foundational things the system needed to change.
One system, one record
Every user type needs to interact with a single, unified platform that holds one authoritative record per operator. No duplicate data entry. No parallel spreadsheets. No phone calls to verify what the system already knows.
Design for the person, not the process
Government systems are typically built around internal workflows. This one needed to be redesigned around the people using it: plain language, real-time visibility, and guidance that anticipates confusion.
Curious about the details? I am happy to walk you through it.
This case study covers the highlights, but there is a lot more to the process. If you want to go deeper on the research, the design decisions, or what we would do differently, reach out and we can get on a call.