Turn a civic portal into a more direct service gateway.
Durham residents needed a more direct way to reach high-demand services without parsing a heavy government website.
Public sector · myDurham 311
Durham Region
Three ways in, before a single search box.
A redesign of the myDurham 311 portal so residents can submit a request, track it and pay from the first screen instead of parsing a municipal website.
- Role
- UX/UI Designer
- Scope
- 311 homepage, service-request entry points, payment paths, mobile patterns
- Focus
- Findability, accessibility, task-first navigation
- Focus
- 311 services
- Help residents submit requests, find alerts, make payments, and track service status faster.
- Scale
- 600K+ residents
- The population the Region's 311 portal serves — the audience, not a result of the redesign.
- Year
- 2024 – 2025
- Aug 2024 to Mar 2025 with the Region of Durham municipal team.
- Duration
- 8 months
- Homepage, request entry points, payment paths, mobile behaviour, and reusable UI patterns.
- Accessibility
- WCAG AA target
- Contrast, target sizes and focus states designed to the AA standard the Region requires.
Project arc8 months - Before / after, completed
- Anatomy, completed
- UX cases, completed
- Journeys, completed
- Responsive, completed
- UI kit, completed
I reorganized priority actions around resident intent.
The work focused on homepage hierarchy, service request entry points, payment paths, mobile behaviour, and reusable UI patterns.
Before and after
A more direct way into civic services.
The redesign shifted the page from a search-heavy municipal landing page into a resident task hub with three obvious starting points.
Homepage anatomy
Five zones, five resident questions.
Scroll the cards, or tap a marker on the page.
myDurham 311Homepage, top to bottom
01 / 05Four links and a sign-in.
Where can I go from any page?
Four links and a sign-in.
Four destinations stay in view on every page. Language and Sign in sit apart on the right.
- Recognition over recall
- Consistent navigation
I came to do one thing. Where is it?
Three tasks before anything else.
Submit, Track and Pay are three equal cards with verb-first labels. The first choice is a job, not a search box.
- Task-first entry
- Equal weight for equal tasks
- Large targets
Is something happening I should know about?
Announcements get one quiet row.
One bordered row under the tasks, with a link to the full list. Notices never push the tasks down.
- Status visibility
- Progressive disclosure
Which service does my problem belong to?
Categories named the way residents talk.
Sixteen cards with a photo and a short label. Residents pick by topic, not by department.
- Match the real world
- Recognition over recall
What if I would rather call?
The phone numbers close every page.
The 311 line, the toll-free number and the TTY line are printed in full at the bottom of every page.
- A clear way out
- Accessible alternatives
UX cases
What a resident asks, and how the portal answers.
Pick a question. See the screen that answers it.
Concepts · not shipped
Three I would design next. Try them.
- Missed Waste PickupResidential Waste Management
- Waste ComplaintResidential Waste Management
- Green Bin Kit RequestResidential Waste Management
- Bag Tag Exemption RequestResidential Waste Management
Search the catalogue as you type.
Type in itWork is under way.
Show the request as a timeline.
Tap a stepWaste, roads, transit, water.
Help people pick the right line.
Pick a number
Information architecture
Navigation mapped around resident intent.
The sitemap clarified how broad civic categories could connect to high-demand request paths without making users understand internal departments first.
High-frequency categories like transit, water, garbage, and regional inquiries sit behind a task-led service request model.
Put resident tasks before organization structure.
Residents arrive with jobs to finish, not a department chart. The entry points lead with submit, track, and pay before the site asks users to choose a civic category.
Use accessible contrast and large, readable action targets.
Large targets and high-contrast states make the interface usable in rushed, mobile, or low-vision contexts.
Keep service status, alerts, and payment paths easy to recover.
Requests, payments, and alerts are recoverable from multiple moments, so users can return to the task instead of restarting.
Make responsive behaviour feel like the same civic product, not a separate mobile site.
The same service model carries from desktop to mobile, preserving labels, priority actions, and content order across breakpoints.
Service journeys
Core paths became easier to scan.
The page system treats requests, tracking, and payment as sibling journeys, each with a direct entry point and supporting explanation.
Three equal cards, no search required. Submit, track, and pay sit on the hero as equal cards, so residents act before they read.
Tracking sits above the catalogue. A reference-number tracker leads the requests page; categories are grouped by what residents need, not by department.
Help is a page, not a search result. Popular topics and guidance are organized so the answer is one scan away, with the same header actions in reach.
The answer comes before the form. Each category explains its service and links the common answers, then lists its request types as buttons.
Common questions, one line each. What 311 is, who can use it and how it differs from 211 and 911 open in place, one question per row.
Every channel on one page. Online, phone, TTY, email and in person are listed together with hours, so residents choose the channel that suits them.
Responsive system
Same civic product, smaller canvas.
Mobile and compact desktop states preserved the same service hierarchy, reducing the chance that residents would lose their place between devices.
Same hierarchy, narrower canvas. The three actions and the announcements keep their order at tablet width.
Actions stay first on a phone. Hero actions become three tall tiles; announcements and requests follow in the same sequence.
Categories reflow without renaming. The tracker stays first; category groups collapse to two columns with the same labels.
The tracker remains one tap away. Categories stack into a single column; the reference-number search keeps the top position.
Help topics stack, guidance stays scannable. The same topics as desktop, one column, no separate mobile site.
Design system
UI parts were treated as civic infrastructure.
Explore the interactive library of civic tokens, components, service journeys, and accessible patterns. The original board sits alongside the expanded system.
Outcome
Residents now start with a task, not a search box.
What shipped, what was and wasn't measured, and the decision I would push on next.
What shipped
- myDurham 311 homepage with Submit, Track and Pay as the first three actions
- Requests page with a reference-number tracker above categories grouped by resident need
- Learn & Help section organized by topic instead of by department
- Tablet and phone layouts that keep the same order and labels as desktop
- A UI kit — buttons, navigation states, footer and service modules — for the Region's team
What was measured
No performance numbers are quoted for this work — I'd rather show what shipped, which you can check on the live portal, than borrow a metric I didn't measure.
The call I’d revisit
I'd push harder on the request catalogue.
The homepage now leads with three tasks, but the moment a resident picks “Submit a request” they still face a long catalogue of categories. Grouping it by resident need instead of by department helps; the honest next step is search-as-you-type over the catalogue with the five most common requests pinned — a change that needs the platform team’s roadmap, not another design round.
What I’d instrument next
- Share of visits that reach Submit, Track or Pay in one click
- Time to first service request on a phone
- Search usage before and after launch — a drop would suggest the tasks are findable without it