Ontario Electricity Support Program
Turning a web-standards mandate into a clickable prototype — and fixing the experience along the way.
Snapshot
Role: Designer and front-end developer of the prototype — UX, visual design, and code
Context: Ontario Electricity Support Program (OESP), an Ontario government program [confirm how you want to credit the engagement — via ICF, or the agency directly]
Design system: Ontario Design System (ODS)
Built with: Eleventy (11ty), HTML / CSS — deployed live on Netlify
Scope: A full applicant journey — eligibility, application, and an authenticated dashboard
Year: 2025
The short version
The team had to bring their site in line with the Ontario Design System, and they were stuck — not on whether to comply, but on seeing what compliance would mean for their actual pages. I built them a working prototype in code, so the standard became something they could click through instead of interpret. While I was in there, I fixed the user-experience problems they'd been carrying. The prototype became the decision: the artifact everyone could point to, and the reference the developers built production from.
Context
The Ontario Electricity Support Program helps lower-income households across the province with the cost of electricity. Like every Ontario government property, the site had to conform to the Ontario Design System — the province's standards for layout, components, type, color, and accessibility.
The challenge
A design system is a document until someone applies it. The team could read the Ontario Design System, but they couldn't see how its rules would land on their content — their eligibility logic, their application flow, their account pages. So the conversation kept circling in the abstract: what a guideline meant, whether a given page "counted" as compliant, how a component should behave in their particular case.
Static mockups wouldn't settle it, because the open questions were about behavior and flow, not just appearance. Further, because there had been a lot of friction in the project, they wanted a senior designer who they could trust to now only understand the guiding principles of User Experience, but who could understand the design system specs and implement a solution quickly.
My approach
I built the answer instead of describing it.
Using Eleventy and the Ontario Design System, I stood up a working prototype of their real experience — not a marketing page, but the actual journey an applicant moves through. Every style, component, and interaction rendered exactly as the ODS intends, in the browser, on their own content. Stakeholders could click through it, follow the flow, and react to something concrete.
And because I was rebuilding the experience to apply the system, I treated it as the moment to fix what wasn't working — for instance creating a dashboard for citizens where they could see where they were in the application process. Compliance and a better experience arrived in the same pass, rather than as two separate projects.
What I built
A complete applicant journey, coded and live:
Program-information and eligibility pages that explain a benefit program in plain terms
New and renewal application flows
An authenticated dashboard that changes with the applicant's status — a "pending" state that tells someone their application is in process and what to do next, versus a "not yet submitted" state that points them to the right next action
Ontario Design System components throughout — notices and alerts, in-page navigation, forms, account screens.
The authenticated, state-driven dashboard was the part that mattered most. Most prototypes stop at static pages; this one modeled what an applicant actually sees once they're inside the system, in different states — which is exactly where the real usability questions live.
Why a coded prototype
The code was the decision artifact. It moved the room from "what does this guideline mean?" to "here's how it works on your site." It gave the developers a working reference to build production from, instead of a spec to interpret — so the design intent survived the handoff. And it let me prove the experience worked before anyone committed engineering time to the heavier production build.
This is how I tend to work when the ambiguity or the stakes are high: design proven in code first, production build second. The separation is deliberate. A prototype in real code answers questions a mockup can't — about behavior, state, accessibility, and how a system actually feels under the hand.
Outcome
The client team was able to make real decisions about the requirements of the site, allowing the ICF development team to finally move forward to implementation.
What it shows
I implement established design systems in working code — not just comps.
I use prototypes as a communication tool — a way to make abstract requirements concrete and move a room to a decision.
I improve the experience while I'm in there, instead of treating compliance and usability as two separate jobs.
take a peak @