Role
UX research, interaction design, UI design
Context
Individual capstone · Winter 2026
Methods
SME interviews and two rounds of usability testing with eight participants
Deliverable
High-fidelity mobile prototype in Figma
Making accessibility barriers visible in Calgary 311
An icy sidewalk can inconvenience one person and make the route unusable for someone else. When I reviewed Calgary’s 311 app, residents could report an issue, but there was no dedicated way to flag that it made the route an accessibility issue.
For my Information Design capstone at Mount Royal University, I designed an interactive mobile prototype that lets residents report an issue, describe the barrier it creates, and follow the request after they submit it. I audited the existing app, consulted two accessibility experts, and designed, tested, and iterated an interactive Figma prototype that takes residents from filing a report to tracking what happens next.
How the Accessibility Flag fits into a 311 report
After reviewing how Penticton, NYC 311, and AccessNow handled accessibility reporting, I added an optional Accessibility Flag within the existing service categories. Residents could report the issue and describe its impact in the same request, for themselves or on someone else’s behalf.
What changed after testing: In think-aloud sessions with five Information Design peers, one participant pointed out that the dropdown limited them to one barrier type. I replaced it with checkboxes so residents could report overlapping impacts in the same request.
The revised prototype lets residents flag both a wayfinding barrier and a safety hazard in the same report.
The original dropdown accepted one answer. The revised field lets residents record overlapping impacts, such as a mobility barrier that also creates a safety hazard.
Clarifying the request confirmation
In the first usability round, one participant mistook the red border and warning icon around “Accessibility Barrier Flagged” for an error. Two participants questioned why “Submit Another Issue” was more prominent than “Track Request.”
I switched to a blue informational callout to acknowledge that the flag was recorded. I also made “Track Request” the primary action so residents could go directly to the request they had just submitted.
Showing residents where their request stands
Andrea, a disability advocate and member of Calgary’s Advisory Committee on Accessibility, told me that residents rarely hear how their reports are categorized or resolved. I designed the confirmation screen to show the request ID and explain what happens next. When residents return, a status timeline shows where their request stands and lets them revisit the barrier they reported.
In the second usability round, all three participants without a design background completed the reporting and tracking tasks without help. They brought up the next steps and timeline unprompted, and one said the timeline made the process “feel clear.” Participants also valued being able to revisit past requests, so I kept request history in the prototype.
What I would test next:
I annotated key screens with intended screen reader reading order, element roles, and text alternatives. My next step would be to test the full reporting and tracking flow with residents who use assistive technology. I’d also work with City staff to see how the proposed barrier details could fit into triage and what status information they could reliably share with residents.