HFOJobs Portal
Designed and usability tested a three-sided job portal for HealthForceOntario — job seekers, employers, and admin.
View case studyUX/UI designer based in Toronto — 7 years designing service experiences for financial and government platforms.
Designed inclusive, accessible digital experiences that are intuitive, usable, and grounded in user needs, cognitive patterns, and inclusive design principles.
I design for financial institutions and public-sector ministries, leading discovery through post-implementation review — with a focus on accessibility (AODA/WCAG) at every step.
Wireframes through high-fidelity, AODA/WCAG-compliant prototypes.
Service blueprints and journey maps for complex, multi-party processes.
Component libraries that keep teams and platforms consistent.
Interviews, testing, and evaluations turned into workflows people can act on.
Designed and usability tested a three-sided job portal for HealthForceOntario — job seekers, employers, and admin.
View case studyA public-facing banking hub for students and parents, redesigned end-to-end and tested with real students.
View case studyA below-market housing initiative for the Region of Peel, helping residents find and apply for affordable housing options. Details coming soon.
View case studyService blueprint and journey map for WWWOCS, reducing processing drop-offs for the Ministry of Natural Resources.
View case studyA self-directed concept redesign of accessible paratransit booking — replacing a phone-only process with a digital flow designed around screen readers, motor-impairment input, and low digital confidence.
View case studyAn independent concept redesign unifying onboarding, everyday money movement, small-business banking, and fraud protection into one connected digital banking experience.
View case studyHFOJobs connects healthcare professionals with employers across Ontario — a free, government-funded platform, live today. It runs as three connected portals: Job Seeker (search, apply, message), Employer (post roles, review candidates, message), and Admin (approve employers and postings before anything goes live). I'm leading the redesign of all three, end to end.
On a platform like this, friction has a real cost — a nurse who gives up on an application is a nurse who doesn't get placed. Three portals need to work as one coherent system for three very different jobs to be done: a job seeker moving fast, an employer juggling multiple roles, an admin who can't become a bottleneck. Before redesigning any of it, I needed to understand exactly where the current product was failing the people using it — not guess.
Usability testing came last, not first — it followed three other passes that shaped what was worth testing.
The live, existing screens — not a redesign. This is the baseline I tested against and the starting point for the work ahead.
Mapped from the live product, before touching any of it.
A different job to be done than the job seeker side — posting, managing, and reviewing candidates across multiple open roles at once.
Mapped from the current product, including the decision points and loops that don't show up in a screenshot.
A mix of job seekers (nurses, physicians actively job hunting) and employers (healthcare hiring managers), with varying experience using online job portals.
Sessions ran over video conferencing on each participant's own device, in a realistic, distraction-free setting.
5 min intro & consent, 45 min task-based testing, 10 min post-task discussion and feedback.
Think-aloud protocol, screen recording and eye-tracking, observer notes, task completion metrics, 1–5 difficulty ratings, and a post-session questionnaire.
Built from what participants actually said during testing — not assumptions about how they'd feel.
"Everything is white… I need some kind of contrast so I can tell I'm going from here to here."
Expects search and filters to behave the way every other job site does — visible by default, confirmed after use.
Scrolls past hidden filters without noticing them, then restarts the search from scratch out of uncertainty.
Confident applying once messaging confirms the application went through — anxious in the moments before that confirmation.
Low-fidelity sketches for both sides of the redesign — job seeker and employer.
One walkthrough per persona, showing how each moves through the redesigned flow end to end.
All 7 sessions ran with real HFOJobs users, not proxies — healthcare professionals actively job hunting, and the employers who hire them. Feedback and findings below are summarized into two key themes per group.
Wanted a way to save a search and get notified of new postings. First-time users also needed a moment to parse terms like “posting” vs. “opportunity.” On the plus side, employer contact details weren’t hidden until after applying, which built trust early.
The new graduate needed the most guidance — unsure what belonged in her profile versus her application, and asked for inline examples or a checklist. More experienced job seekers moved faster and said the form itself was “faster than the old portal” once they found it.
Wanted a faster way to see new applicants without navigating through several screens. The approvals queue was useful once located, but wasn’t obvious from the dashboard. Occasional users also wanted clearer status labels — draft, live, and pending read too similarly at a glance.
Needed to compare candidates across departments and asked for bulk actions, like archiving multiple postings at once. Messaging was the most-used feature for daily users, who wanted unread counts to be more visible and a way to reply without leaving the candidate list.
7 real job seekers and employers, 3 realistic tasks each — run against the existing screens above.
The clearest signal: messaging — the feature I expected to be fine — scored highest at 4.7/5. Search and filters, the part I was most confident about, needed the most rework at 4.0/5, with one participant noting they "didn't see it because it was hidden." The redesign starts there.
Water and wastewater operators across Ontario are required to renew their certification periodically — a process that directly affects public health infrastructure, since uncertified operators can't legally continue running treatment systems. The existing renewal journey had a high drop-off rate, and the Ministry needed to understand why operators were abandoning the process partway through.
My role was to map that journey end to end, identify where and why people were dropping off, and redesign the flow around what operators actually needed at each stage.
Operators renewing certification are often mid-career professionals with limited time and patience for a confusing bureaucratic process — many are managing treatment facilities on top of the renewal paperwork. The existing process asked for information in an order that didn't match how operators thought about their own certification history, which meant people got stuck, gave up, and had to start over later under time pressure.
Research combined what the data already showed with direct input from the people living the process on both sides — operators submitting updates, and the Ministry staff reviewing them.
Operators recall work experience by employer and time period, not by the certification system's internal categories, so the form felt disconnected from their own history.
After submitting a renewal or profile update, operators had no way to see it moving, so many called or emailed Ministry support just to check.
A large share of updates — like new work experience — actually required manual review by ORO/Admin Support before an operator's profile reflected it, invisibly.
First-time exam registrants needed help creating a profile, while returning operators just wanted the fastest way back to their session.
Two audiences moved through this system with very different needs — a certified Operator maintaining an existing record, and an Operator-in-Training registering for their first certification exam.
Keep their certification and work-experience record current without re-entering information the Ministry already has on file.
Update requests need admin review before they show up, with no in-app signal that anything is pending — so they call to check.
Figure out which exam session applies to them and register — ideally without needing to call the Ministry to ask.
Unclear whether an account is needed first, and no confirmation that registration and payment actually went through until much later.
Mapped against the existing portal process, before the redesign — this is what the research surfaced.
Mapped the full renewal journey against real operator behavior, pinpointing exactly where drop-off was occurring and why.
Connected the operator-facing journey to the Ministry's internal review and approval process to find where delays originated.
Ran working sessions with Ministry staff to validate assumptions and align on what could realistically change.
Reordered and simplified the renewal steps to match how operators actually think about their certification timeline.
Two of the flows the redesign was built around — an Operator-in-Training registering for their first certification exam, and a certified Operator updating their work experience.
The same two journeys, taken to high fidelity — reflecting the redesigned flow, content order, and visibility improvements from the research.
Case study cover — desktop, tablet, and mobile presentation
Student Hub gives students and their parents a single home for relevant banking products, offers, and educational content, tailored to their life stage — high school, post-secondary, or arriving in Canada as an international student.
Team
Collaboration across research & testing with students, the data team, and operations — before a single screen got designed.
Users accustomed to the original Student Hub could find a sudden redirection to Advice+ Finance disorienting, risking a drop in engagement.
Ensuring all content met AODA standards meant rigorous testing and adaptation for users with disabilities, not a checkbox pass.
Integrating financial advice with product offerings risked overwhelming users trying to find one specific answer.
Moving between advice content and product information needed to feel continuous, not like two different sites stitched together.
Suite of student products available at every life stage.
Rewards, offers, and perks for the prospect.
Financial tips and advice for students.
| Feature | RBC | CIBC | TD |
|---|---|---|---|
| Student & Product Lines | ✓ | ✓ | ✓ |
| Rewards & Benefits | ✓ | ✓ | ✓ |
| Tips & Advice | ✓ | ○ | ○ |
| Scholarships | ○ | ✓ | ✓ |
| Banking Tools | ○ | ○ | ○ |
Banking tools being unclear across all three competitors was the clearest whitespace — nobody had nailed it yet.
Three design directions explored for desktop and mobile before converging on one.
Design Op-1 · Homepage
Design Op-2 · Homepage
Design Op-3 · Homepage
Click a screen to enlarge — scroll inside each frame to see the full page.
Four page types, each carrying the same structure with content tailored to that audience.
There is a section where we try to connect the user to the most-used section, which is Scene+.
There is also a section where students can find answers to the questions they come across during their banking journey.
Click the screenshot to view full size.
A short intro frames the page for high school students specifically, right under the shared tab navigation.
Products relevant to this age group. There's one to offer today, but the layout can take on more without any design changes — just additional dev work.
Steps that walk a student through opening an account. Adding icons here keeps the section visual instead of text-heavy, so it's easier to scan.
Resources written for high school students. "Read more" leads into an existing Advice+ article, where they can keep browsing related content.
Scholarships and contests for this group — more listings can be added here in future with a bit of dev work.
Frequently asked questions, tailored to what a high schooler would want to know before opening their first account.
Click the screenshot to view full size.
Overview tab — default state
Tab dropdown open — High School / Post Secondary / International
High School page — full scroll
More mobile screens can be dropped into this gallery the same way as they're shared.
After the wireframes, I built a fully high-fidelity prototype and tested it with a group of real students — not a generic panel. Tasks covered browsing every product type, finding resources international students need, gauging interest in the rewards section, scholarship discoverability, and navigation for both students and parents.
Testing changed the product. I changed CTA links to detailed, informative link text for screen reader users — the original was just an arrow icon, which read as ambiguous or meaningless out of context. One icon was unclear to multiple participants and got replaced with a more appropriate one. Loose conversation during sessions also surfaced what an ideal version of this kind of hub would look like, shaping the roadmap beyond this release.
Syndicate Book Builder supports corporate finance teams running syndicated debt deals — coordinating multiple banks, tracking investor orders in real time, and keeping compliance informed as a deal moves. I designed the interface layer for a platform that needed to serve very different users — brokers entering live order data, deal leads monitoring overall book status, and compliance teams auditing after the fact — without becoming three separate products.
The work spanned the full 2020–2022 period, from early concept through to a platform actively used by trading desks.
Each user role needed a different view of the same underlying deal data, updating in real time as orders came in. Brokers needed speed and minimal friction during active order entry; deal leads needed a high-level, always-current view of book status; compliance needed a clear audit trail without slowing anyone else down. Designing one coherent system underneath three very different use patterns — on top of a Material UI foundation shared with other internal tools — was the core constraint.
Mapped distinct user journeys for brokers, deal leads, and compliance, identifying where their needs diverged and where they could share components.
Built within Citi's Material UI-based design language, extending it where the trading context needed patterns it didn't yet have.
Designed how live order updates should surface without overwhelming users mid-task, particularly for brokers entering data under time pressure.
Worked with active trading desk users post-launch to refine flows based on real usage rather than assumptions.
The Region of Peel offers below-market housing options to residents, but the current process for discovering and applying for these units is fragmented and hard to navigate. This project focuses on redesigning that experience end to end — from finding eligible housing to completing an application — so residents can get the support they need with less friction.
Residents looking for below-market housing in the Region of Peel often struggle to find listings that match their eligibility, and the application process involves multiple disconnected steps. This creates confusion and drop-off, especially for the residents who most need this support.
Understand how residents currently search for and apply to below-market housing, and where they get stuck.
Prototype a simplified discovery and application flow based on real resident needs.
Test the redesigned flow with residents and Region of Peel staff before rollout.
Placeholder — research methods, resident interviews, and current-state findings will be added here as the discovery phase is completed.
Placeholder — a sitemap of the discovery and application flow will be added here once the structure is finalized.
Low-fidelity sketches of the core discovery flow, alongside a more detailed conceptual pass at the multi-step application — the eight-step eligibility, income, and consent flow below.
Two redesigned experiences — resident-facing Below Market Housing on the left, and the Provider Portal on the right.
This case study will be updated with real research findings, designs, and outcomes as the project progresses.
Placeholder — measurable outcomes and impact will be added here once the redesign has shipped.
Paratransit — the shared, accessible ride service that exists alongside fixed-route buses and trains for people who can't use conventional transit — is often booked entirely by phone, one day ahead, through a call center with limited hours. TransitAssist is a self-directed concept project imagining what a companion digital booking experience could look like if it were designed around the access needs of the riders who depend on it most, rather than adapted for them afterward.
This is a personal exploration, not commissioned client work — built to practice designing for accessibility from the first sketch, using publicly available guidelines and informal rider feedback rather than a funded research budget.
For many riders with mobility, vision, or cognitive disabilities, requesting a ride today means calling a booking line during limited hours, repeating personal and trip details out loud, waiting on hold, and hoping the request was captured correctly — often with no written confirmation and no way to check status until the vehicle arrives, or doesn't. Riders who use screen readers or have limited phone confidence are especially underserved by a process that assumes everyone can comfortably manage a live phone call.
Since this was a self-directed concept project rather than commissioned work, research combined published guidance with lightweight, informal input rather than a funded study — enough to ground the design in real constraints without overstating its rigor.
Booking is only possible when the phone line is staffed, which rules out late-night or early requests many riders need to make.
Riders can't confirm what was recorded until the vehicle shows up, or doesn't — described as the most stressful part of using the service.
Screen reader users who had tried similar apps described them as technically accessible but slow and effortful to operate.
Caregivers who help book rides for a family member want their own access, not a shared login.
Three composite personas, built from the informal rider and caregiver conversations above, kept the design honest about whose needs it was actually serving.
Book a ride independently, without needing someone else to make the call for her.
Long hold times, and repeating her wheelchair and lift requirements on every single call.
See her mother's upcoming and live rides without needing her mother's login or being on the phone with her.
No way to get visibility into a booked ride unless her mother calls to tell her directly.
Complete a booking with a screen reader and larger text, at his own pace, without feeling rushed.
Most apps assume comfort with small tap targets and fast-moving screens he can't reliably use.
Reviewed accessibility guidelines and rider feedback to understand real constraints before sketching anything.
Moved from rough flows to low-fidelity wireframes to a high-fidelity prototype, testing assumptions at each stage.
Checked the design against WCAG success criteria and rider feedback to document what still needs work.
Mapped around the two people who use it — the rider booking a trip, and the caregiver supporting them — rather than a single generic account.
The detailed flow the whole design was built around — get any of the three personas above from "I need a ride" to a confirmed, trackable trip, branching only where their needs actually differ.
Returning riders sign in directly. A first-time rider like Walter completes a one-time profile covering mobility, vision, and communication needs.
Home surfaces the next ride and one clear way to book another — nothing to hunt for.
Saved places and recent trips cut typing to a minimum, which matters most for a rider like Amara using a switch or voice input.
Only windows the service can actually accommodate are shown — no guessing, and no request that gets silently rejected later.
Mobility, visual, and communication needs are pulled from the profile and simply confirmed, not re-entered every time.
A plain-language summary before the request is sent, with a written confirmation after — something to point to that a phone call never gave.
If a caregiver like Priya has linked access, she sees the booking and can track it too, without her mother handing over a login.
A three-step tracker replaces waiting and wondering on the day of the ride; afterward, the trip is saved for a one-tap rebook.
Mapped against the current phone-only process, before the redesign — this is what the journey map in the research phase surfaced.
Amara, Priya, and Walter all move through the same current, phone-only process — but what breaks down for each of them at each stage is different, which is what the redesign had to account for.
Ten screens, in the order a rider (or their caregiver) actually moves through them — sign-in through to rating a completed trip — taken from rough sketch through grayscale structure to finished visual design.
Grayscale versions of the same ten screens — real copy and layout, before color, type, and branding were decided.
Same ten screens, brought to a finished visual design and checked against WCAG 2.2 AA contrast and target-size guidance — the full end-to-end portal, rider and caregiver side.
A closer look at the screen every persona relies on most, with the reasoning behind five specific decisions.
As a self-directed concept rather than shipped client work, TransitAssist doesn't have adoption numbers or support-ticket data to point to. What it does have is a design checked directly against WCAG 2.2 AA success criteria at every step, and a booking flow that — even informally, when walked through with the riders and caregiver who informed it — took a fraction of the time the phone process does.
The clearest lesson was how much of the anxiety in paratransit booking isn't about the ride itself, but about not knowing: not knowing if the call went through, not knowing if the vehicle is coming, not knowing what was actually booked. Solving for visibility mattered as much as solving for the number of taps.
Most digital banking apps are built one feature at a time — onboarding by one team, transfers by another, small-business tools bolted on later, fraud alerts handled by whichever team owns push notifications. The result is an app that works, screen by screen, but never feels like it's run by the same bank twice.
This project takes the opposite approach: pick four of the moments that matter most in a real banking relationship — opening an account, moving money day to day, running a small business, and recovering from fraud — and design them as one coherent system, for one connected set of customers, instead of four separate case studies bolted together.
Across the six banking apps audited for this project, every one of them could technically do everything a customer needed — open an account, send money, run a small business, flag fraud. What none of them did well was show up differently depending on which moment a customer was actually in.
A first-time customer opening an account was handed the same dense, transaction-heavy home screen as someone who'd banked there for a decade. A small-business owner's day-to-day banking looked identical to their personal chequing, split across a separate app they had to sign into twice. And a fraud alert — the single moment a customer most needs clarity and reassurance — arrived as a bare push notification with no way to act on it beyond calling a phone number.
The question this project set out to answer: what does a digital bank look like if it's designed around the moment a customer is in, not just the feature they're trying to use?
Independent, self-directed research combining a competitive teardown, a short survey, and structured interviews across the three customer groups this project was designed for.
A heuristic teardown of onboarding, transfers, small-business tools, and fraud/dispute flows across major Canadian and U.S. digital banks, scored against Nielsen's heuristics.
A short screener survey on banking-app frustrations, sent to personal contacts and two small-business owner communities, used to prioritize which four moments to focus on.
Three interviews each with a first-time digital banking customer, a small-business owner, and someone who had personally been through a fraud dispute in the last year.
Every first-time-banking interviewee said their trust in an app was set in the first session — before they'd moved a single dollar.
Every audited app split everyday money movement across separate entry points, forcing customers to guess which one applies before they can act.
All three small-business interviewees actively avoided their bank's dedicated business app, preferring to manage everything — personal and business — in one place.
Every fraud-dispute interviewee described their first alert as frightening rather than reassuring — it told them something was wrong, not what to do about it.
Three composite personas, each mapped to a different combination of the four moments, kept the redesign honest about whose banking relationship it was actually shaping.
Run her studio's day-to-day banking — invoices, payroll, cash flow — without leaving her personal banking app.
Her bank's "business" tools live in a second app with a separate login and none of her personal account context.
Open an account and get a working card from his phone, without a branch visit or a stack of paperwork.
Every app he's tried buries account opening behind dense forms that feel built for people who already bank there.
Understand immediately whether a flagged charge is serious, and know exactly what happens next if it isn't hers.
Her only fraud alert to date was a text message with a phone number — no detail, no timeline, no way to respond in-app.
Synthesized from all nine interviews, regardless of which of the four moments each participant was speaking about.
“I don't want a business app and a personal app — it's the same money.”
Expects the bank to already know which moment they're in — new customer, business owner, or someone who just got a fraud alert — and to respond accordingly.
Screenshots fraud alerts and confirmation screens to keep a paper trail the app itself doesn't give them.
Calm and in control when a flow explains what happens next — anxious the moment it goes quiet and leaves them guessing.
Audited 6 live banking apps and ran 9 interviews to find where the four moments broke down today.
Mapped a single information architecture — Home, Move Money, Business, Cards, More — that every persona shares, rather than separate apps per need.
Sketched, then built to full visual fidelity, the twelve screens that carry a customer through all four moments.
Four connected chapters, each following one of Meridian's real customers through the moment that matters most to them — opening an account, sending and paying, running a business, and recovering from fraud — all inside the same app and the same account.
Mapped across a full banking relationship — before this redesign — from opening an account through the first time something goes wrong.
Each flow was mapped independently, then checked against the same navigation shell — Home, Move Money, Business, Cards, More — to make sure none of them needed their own separate entry point.
Sixteen screens, four per moment, in the order a customer actually moves through them — from opening an account through resolving a fraud dispute — taken from hand-drawn sketch to finished visual detail.
Full visual detail across all four moments — from a first-time customer's welcome screen to a resolved fraud dispute.
Choose Account Type — Personal, business, or both selected in one tap, before any other question.
Welcome — One flow for personal, business, or both, no branch visit required.
Approved — A working digital card issued the moment identity is verified.
Identity Check — A guided camera scan replaces a branch visit to verify ID.
Enter Amount — A numeric keypad built for speed, recipient already confirmed above.
Move Money — Send, request, pay, and transfer treated as one equal set of actions.
Review & Send — Fee, timing, and recipient shown plainly before the customer confirms.
Payment Sent — A plain confirmation with amount, recipient, and a receipt link.
Create Invoice — Bill-to, amount, due date, and items on one uncluttered form.
Business Overview — Cash flow and a low-balance warning surfaced before anything else.
Transactions — Spend tagged for tax as it happens, not batched at year end.
Invoice Sent — Confirms delivery and shows when the client last viewed it.
Card Frozen — Confirms the card is frozen and a temporary credit is already issued.
Fraud Alert — A specific charge and a single clear question, not a vague warning.
Dispute Timeline — A visible status trail from report through resolution.
Resolved — Closes the loop plainly once the disputed charge is reversed.
Click a screen to enlarge.
Every screen above sits on the same five-tab shell — Home, Move Money, Business, Cards, More — so switching between a personal errand and a business one never means switching apps.
The Business tab only appears for customers who opened a business account — everyone else sees the same four remaining tabs, so the shell scales down for a personal-only customer like Malik without ever feeling incomplete.
A closer look at the screen every persona touches most often, with the reasoning behind four specific decisions.
Click the screenshot to view full size.
As a self-directed concept project, these are design targets informed by the research above, not measured production results.
The clearest lesson was that "unifying" four moments doesn't mean making them look the same — it means making sure they share one underlying model of the customer. Farah, Malik, and Diane needed very different screens, but all three needed the app to already know which of them they were before they had to explain it. That's a navigation and data problem as much as a visual one, and it reshaped how I thought about the app shell as much as any individual flow.