Sound Transit • 2026 • in production
Helping 500k+ public transit riders find information online in Seattle.
The Problem
The legacy website was built to market Sound Transit. Deep navigations and unhelpful search results were making it hard for users to find the right information.
Deep Navigation that does not match users' mental models.
Long search results list with no way to identify the right link without clicking.
how might we
How might we help riders find the information they need quickly while also making content easy for LLMs to surface, as more people search outside the website?
Solution
We rebuilt search to show riders where they are going before they click. Research revealed looping behaviour on the website since users could not figure out where information lived.
01
Search available on every page + popular searches
Made search prominent on all pages. Users often searched for the same information often, so those pages easy to access through pre-populating a list that keeps updating based on analytics data.
02
Results grouped by popularity and recency
Context aware grouping of search results either by popularity or recency.
03
Detailed results, recognizable at a glance
Since the site is information dense, providing enough detail for recognition in the search results was key to get users to the right information efficiently.
04
New navigation organized by rider tasks
To make the navigation more usable, we co-designed the new dual-navigation with Sound Transit SMEs. Items are organized by tasks each user group would need to do.
05
For all of the above to work - Content rules for search and LLM discoverability
For all of the above to work, content on the website needed to be organized differently. We gave them a guide on how to organize content so soundtransit.org would serve as the single source of truth for search results, the new navigation and most importantly LLMs, as information discovery changes.
Research
Before redesigning anything, we needed to know who visits the website and what they come to do.
First, behavior analysis, content gap analysis, usability tests, and stakeholder interviews gave us the answers.
primary users
Riders were the primary users yet they were the most dissatisfied.
"I don't even bother with the search on the site. I just Google 'Sound Transit' plus whatever I'm looking for and hope one of the links gets me to the right page."
Finding 1 → Looping behaviour
Riders looped between pages instead of finding answers
This made discoverability the problem to solve.
Finding 2 → Mental models
Riders mental models involved task based goals. The menu and content did not match that.
“Navigation is very confusing, I don’t know what to expect under each menu item.”
-User interview quote
Finding 3 → Search reliance
Search was already the wayfinding
People often defaulted to search when the navigation was unhelpful. Top queries were parking, schedules, fares - all core rider tasks.
This informed a 56-participant card sort and a workshop with Sound Transit SMEs. We co-designed a new IA before we designed any screens.
Information Architecture workshop with the Sound Transit dev, content, and passenger experience team.
The IA that we were co-designing with Sound Transit.
design principles
Research showed riders had low trust in the website's ability to help them find anything. Most skipped it entirely and went to Google instead. Three principles guided everything we designed.
Earn trust with every search result
Every search should return something recognizably right, so riders learn the site can be relied on.
Proactive search results discovery
Riders should know where a link will take them before they commit .
Discovery beyond the website
Content structured to surface well wherever riders look - Google, LLMs, or the site's own search.
iterations using lovable prototypes
Our first instinct was an AI assistant. But, a public transit agency cannot afford to run one.
A chatbot could answer riders directly but it would mean ongoing token costs and dev resources a public agency doesn't have. Any always-on AI layer was off the table. So we set a harder constraint for ourselves: deliver the guided, in-context experience of an assistant without any AI running underneath.
Reflection
The most valuable thing we did was tell the client the problem wasn't the one they hired us to fix.
The brief was a navigation redesign. The data said the real cost was findability and that the fix had to survive on a public agency's budget. Reframing the problem, and designing within a hard no-AI constraint, is what made the solution both usable and sustainable.
side project - google maps
Our research also showed that users overwhelmingly relied on Google Maps for route finding, and Sound Transit mainly for information they could not find anywhere else.
Since route finding already lived in Google Maps. We asked: what if it got proactive too?
Mid-way through our Sound Transit project, right as Google introduced Gemini in Maps in March, our research surfaced a hard truth: people didn't trust public transit's reliability. Delays made them anxious, and walking to an alt stop at night felt unsafe. So they gave up and called a cab which was pricier, land they felt like they were making a less environment friendly choice. That gap became the opportunity.
We explored a concept where Maps could conversationally surface real-time alt routes, or last-mile options like Lime, the moment a delay hit. No more defaulting to a cab just because the bus was late.
↩