Accessible Spaces Database

Set draft: false at the top of this file when it's ready to publish.

01Overview

Students with invisible disabilities often can’t tell if a campus space will work for them until they get there.

St. George spans 122 buildings, and a room that’s too loud, bright or crowded can be exhausting. The U of T Innovation Hub asked six of us to design a database that students could check before they go.

02Solution

Two database options, designed to explore which approach better fits U of T students.

Some students know exactly what they need, while others want to look around first. Instead of guessing, we designed for both, so the Innovation Hub can test which approach helps students decide faster.

A closer look at Option B, the prototype I led.

Because I led Option B, these are the decisions I can speak to best. Each one came from something we learned in research or testing.

Decision 1

Spotlight building photos so students can decide at a glance.

In testing of the previous prototype, people preferred browsing a visual site with clear icons and text, and they skipped long lists of tags. So each building card leads with a photo and the few facts that decide a visit: whether it’s open, how far away it is and how much other students like it.

Decision 2

Show sensory conditions as a scale, not a tag.

“Quiet” means different things to different people. We had recorded noise and lighting at every space we visited, so we showed them as meters. That way, each student can judge a space against their own threshold instead of trusting someone else’s label.

Decision 3

Let students tell each other what to expect.

Some things only other students know: when a space gets busy, whether the elevator is working or which floor stays quiet. A discussion board replaces star ratings, and Know Before You Go turns recent posts into short, AI-generated heads-ups. Testers questioned how current and trustworthy reviews would be, so posts add context; they don’t replace verified hours or access details.

What should an accessible database prioritize? The information, not the entry point.

Both options run on the same needs-based details. Next, I’d A/B test them with students who have invisible disabilities to see which approach helps them decide faster.

03Design system

Built on U of T’s brand, extended for product UI.

Two teammates and I designed this system from scratch in Figma, following U of T’s brand guidelines. Colours and type are Figma variables, and every component includes its states, so three of us could design Option B’s 21 screens in parallel without them drifting apart.

Before publishing, fix in Figma and I'll re-export: the "Closed" red (#DC4633) is 4.23:1 on white, under AA's 4.5:1 (use #DA3A26 or darker). The type table lists Heading 3 and 4 as 32px. The grid page says 30px gutters, but screens use 24px.

04Research

Our opportunity: keep the strong discovery tools, and make information simpler, more scannable and easier to decide with.

Our inspiration was a prototype built by a previous team of master’s students. Rather than starting over, we studied what already worked and where current students still got stuck.

Search by need, not diagnosis.

Three findings from the Innovation Hub’s Signals of Hope report shaped what we prioritized.

After testing our checklist on the first day of visits, we found some questions too vague: teammates answered the same question in different ways. So we met to define each quality clearly, which made our data consistent and comparable across all 72 spaces.

We also removed temperature, since almost every building has heating and AC was hard to confirm, and added missing seating options. Filters are only as clear as the data behind them: these set categories became the Study, Socialize, Rest and Eat shortcuts in Option A and the quick tags in Option B.

05Process

From 44 ideas to 2 prototypes.

Affinity mapping and prioritization grid

We sorted every idea by impact and feasibility, then did it again.

In 30 minutes, we wrote 44 ideas on sticky notes and grouped similar ones. Each of us then had five impact votes and five feasibility votes. Voting twice helped us drop ideas that sounded exciting but couldn’t be built in two months, and focus on what students needed most.

Crazy 8s

Six of us, six takes on every idea.

My contributionI facilitated Crazy 8s on the 13 ideas from our first round, with two minutes per sketch. Seeing six versions of each idea side by side helped us spot the strongest layouts before anyone committed to one.

One lesson: we all sketched from the same grid, so our six lo-fi concepts came out too similar.

Next time, I’d have everyone sketch once before seeing the shortlist, so our early concepts stay more varied.

06Testing

Feedback made it simpler.

Walkthroughs with Innovation Hub members and a review from our supervisor led to four changes. Each one made the prototype easier to scan or easier to trust.

Add one before-and-after pair here, e.g. the building page before and after it was simplified.

07Outcome

The Innovation Hub is pitching our prototypes to U of T leadership.

Their honest feedback: Option B drifted toward students in general and away from students with invisible disabilities.

Looking back, I’d fix this in three ways. I’d check every screen against our need statements during design reviews, so drift gets caught early. I’d lead the home page with access information, like quiet, low-light and seating categories. And I’d recruit testers who identify with invisible disabilities, for example through Accessibility Services, since none of ours were screened.

Check "U of T leadership" matches what the Innovation Hub said.

08Reflection

What I learned