Natural language AI search for parking
Describe the parking you need in your own words. An LLM interprets it, and PayByPhone's data finds the spots that fit.
Role
· Design lead, coded the prototype
Team
· 1 PM, engineering partners
Scope
· Research, design, and code
Status
· In progress
66.5%
of people who opened the map in 30 days left without choosing a spot
~11%
of map users use the search bar. The rest pan and zoom through pins
+30%
what a $3.61/hr spot really costs for a 3-hour stay ($14.08, not $10.83)
The problem
The map shows where parking is, not which spot fits
Two out of three map users leave without choosing a spot.
The insight
Hourly rates rank parking wrong
A spot listed at $3.61/hr costs $14.08 for 3 hours, not $10.83, because its rate rises after 2 hours.
What I designed
AI search on the map
Describe your needs in one sentence, see how they were understood as pills, and get spots ranked by what the stay costs.
What I built
I coded the prototype myself
It runs on real Vancouver parking zones, rates, and rules. It's now on the roadmap.
The challenge
A map that shows where, not which
PayByPhone was built for people who have already parked. More and more people now want to find the right spot before they commit.
Routine parkers arrive, type the zone code from the sign, pay, and extend from their phone later. The app serves them really well. Exploratory parkers are different. They're heading somewhere new, or they're already in an area and comparing options. For them, today's map shows where parking zones are, but it doesn't help them decide which one fits. This year, my PM and I took on fixing the existing map: clustering, pin sizing by zoom level, opening the park sheet automatically for nearby locations, and more. Alongside that work, I explored whether AI could make finding the right spot easier.
How might we
…help someone describe what they need, and get to the right spot in one step?
The problem
Two out of three map users leave without choosing a spot
In the last 30 days, about 878K people opened the map. Only a third selected a spot. Around 584K left without choosing anything.
Amplitude · Map funnel, last 30 days
People browse instead of searching
Only about 11% of map users use the search bar. Everyone else pans and zooms through pins that all look the same.
Decisions happen in seconds
People who find a spot usually do it in under 30 seconds. If nothing works within 30 to 60 seconds, they leave or go back to typing a code. That window became my biggest design constraint.
A small, focused audience
12.5% of monthly users open the map, often for unfamiliar destinations, which is exactly when comparing options is hardest.
Why it's hard
The map shows locations. Parking decisions depend on rules.
Identical pins
15 to 20 options in one busy area, all looking exactly the same.
Price three taps deep
Tap a pin, tap Park, reach the duration screen, and only then see what it costs.
No filters
No way to narrow by price, distance, or how long you can stay.
What people actually weigh
How far it is from where they're going. How long they can stay. Whether the rate is flat or goes up after two hours. Time-of-day rules, overnight parking, and permits. And the rules change by city, sometimes by block, across 1,300+ cities.
Research
Checking the idea against reality first
Before designing anything, I looked at how the market handles plain-language search, and at what PayByPhone actually has to build on.
MARKET · Competitive research
Google Maps accepts typed or spoken requests in one search box, with voice as dictation rather than a separate mode. Parky.AI and Parking Base explain parking rules and data in plain language, which shows it's a recognized need. Gemini in cars handles complex, multi-part requests, but it's built for driving. ParkMobile's map has no price or distance filters, while HonkMobile shows pin prices for a chosen duration.
INTERNAL · What PayByPhone has
Our 2021 usability research, with 20 participants, found people wanted to filter by price, distance, and availability, but it was never built. Engineering confirmed that pricing one pin on tap works today, while pricing many pins at once needs new backend work. Price and quote logic exist, max-stay rules exist but aren't surfaced, and walk-time routing doesn't exist yet.
What changed because of it
Mapping what data really exists stopped me from designing around things we couldn't build, and one engineering answer about pricing shaped how prices work in the final design.
Does this need AI?
My first prototype didn't need AI, so I set it aside
I tested every idea against one question: does this actually need AI, or would something simpler work?
Set aside
Single-constraint search
"Parking near Denman under $5/hr." A filter does this in two taps.
Set aside
Subjective requests
"Somewhere I'd feel safe walking at night." The best case for AI, but there's no data to answer it.
Set aside
A chat agent for the whole app
It would pull in billing, refunds, and support, with a much higher cost when it gets something wrong.
Set aside
Hands-free voice
No safety benefit on a phone. Voice stays as dictation into the same field, and voice-first belongs in CarPlay and Android Auto.
Selected
Multi-constraint, destination-based search
Several needs in one sentence, checked against rules the map doesn't show.
Why AI
The rate isn't the price
Most of my arguments for AI were about convenience. This one is about correctness, so it became the lead.
Same request · 3-hour stay
What the listed rate suggests, $3.61/hr
$10.83
for 3 hours, if the rate stayed the same.
Tiered, $3.61/hr for 2 hours, then $6.86/hr
$14.08
what 3 hours really costs. AI search adds it up for every spot.
The stay costs about 30% more than the listed rate suggests. A filter only sees the listed rate, so it can't rank stays correctly.
AI search ranks results by what the whole stay costs
A price filter compares hourly rates, so it can't rank these correctly. AI search looks at what the whole stay will cost. It also helps in two other ways: several needs fit into one sentence inside a 30 to 60 second window, and new rules from different cities don't need new UI each time.
What this doesn't claim
I'm not saying AI understands things filters can't. Most of these needs could be a filter. The case rests on getting the price right and saving people effort.
Explorations · Wireframes
How separate should AI be from standard search?
Once I knew what to solve, the question was where AI should live. I explored a spectrum, from AI blended into search to AI as its own surface.
Filters, or AI blended into search
My team's filter concept
Can't rank tiered pricing by the cost of a stay, and distance needs a destination it doesn't know.
One bar for both
Is "Denman" an address or an AI request? Guessing caused layout jumps.
AI prompt above search
A floating prompt adds noise for people who just want to type an address or code.
AI suggestion chips
Assumes every visit starts with price, crowding the map before intent is known.
AI as its own surface, and the middle ground
Ask AI button
Splits search into two competing actions, and AI feels bolted on.
AI drawer, collapsed
Puts standard search behind an AI-first layer, slowing the most frequent task.
AI drawer, expanded
Asks people to decode a conversational layout in a 30 to 60 second window.
Mode switcher
Selected. Intent is clear before typing, routine search stays fast, and it remembers your choice.
Trade-off: a mode switch is one more choice, but guessing someone's intent wrong costs more. Prices on idle-map wireframes are illustrative. In the final design, prices appear only after a search.
How it works
The AI understands the request. PayByPhone's data supplies the facts.
Language models are great at understanding messy sentences, but they can get facts wrong. So the model only interprets what someone asked for, and our own rules and pricing data decide which spots qualify and what they cost.
01 · You
Type or dictate
A request in plain language.
02 · Language model
Interpret
Destination, walk time, price, duration, permit, and overnight.
03 · Show
Editable pills
Pills build as you type, and one tap removes a misread.
04 · Resolve
Find the place
Landmarks become a location. Unclear ones ask before guessing.
05 · PayByPhone data
Check the rules
Max stay, overnight, and permit rules for every spot.
06 · PayByPhone data
Rank by real cost
By total cost for the stay, when a duration is given.
07 · Park
Existing park flow
Tapping a spot opens the flow people already know, which gives the binding quote.
The rule
Facts come from data, not the model
The model can never invent a price or allow a restricted spot.
Final design · Prototype screens
From a sentence to the right spot
Three moments carry the experience: teaching what to ask, showing how the request was understood, and checking the rules people can't see.
1 · Teach the use case, then show the interpretation as it forms
Suggestions lead with multi-constraint examples
The request is understood
Pills build as you type
Remove a pill, and results widen
2 · Check the rules people can't see
Within a 15 min walk, along real streets
Only spots that allow a 6-hour stay
A stated permit adds permit zones, with a neutral label
Totals for the stay, and your permit at $0
What to notice
Every part of the request becomes its own pill, so a misread is fixed with one tap instead of retyping.
A permit on your account appears as its own pill, and spots it covers show $0. A permit you only mention adds permit zones at their normal price.
With a duration in the request, every result shows the total for the stay, not an hourly rate.
Why these details
Pills, not a black box
The biggest risk in language search is a silent misread. Every part of the request is visible and fixable in one tap.
Prices only after a search
Price depends on when and how long you park, so pins show prices once the request gives that context. It also keeps pricing to a small set of results.
Totals that always match
With a duration, pins and the results list both show what the stay will cost. Tiered rates are added up for the hours requested, and a spot your permit covers counts as $0.
Walk time follows real streets
"Within 15 minutes" is measured along the walking route, not as a circle on the map, since water and parks make straight lines misleading.
Permits: verified, stated, or neither
A verified permit on your account becomes a removable pill, and spots it covers show $0. A permit you only mention adds permit zones at their normal price, never $0. With neither, permit zones stay out, so nobody is sent somewhere they could be ticketed.
Final price before you pay
Estimates are marked, taxes are added at checkout, and a short notice explains it if the final price is higher.
Prototype
I built this prototype myself, in code
It runs on real Vancouver parking zones, rates, and rules, so I could test real requests end to end. As someone types, the pills form. Then the results appear on the map with prices, and tapping a spot opens the park flow people already know.
Validation · Usability testing
Moderated sessions with my coded prototype, focused on whether people trust how the app reads their request and what it shows them.
HOW I TESTED
Who: 8 exploratory parkers who drive downtown at least monthly, a mix of PayByPhone users and non-users on iOS and Android.
How: 30-minute moderated sessions with my coded prototype, thinking aloud.
Tasks: cheap parking near English Bay for 3 hours, overnight parking nearby, parking with a residential permit, fixing a misread request, and a vague "parking" request.
Measured: task success, time to choose a spot, pill edits, and confidence in the price.
WHAT CHANGED
Totals were easier to trust than tiered rate text, so results lead with the total and mark tiered rates with "+".
A red "Permit required" tag worried people who had a permit, so it became a neutral "Permit zone" label.
People wanted to see how far each spot was, so walk time appears on every result whenever the request has a destination.
Some didn't notice AI Search at first, so an example prompt now sits inside the search field.
Caught while building
At one point, "15 min walk" was read as a 15-minute parking stay. The results looked completely reasonable, but they were wrong. AI mistakes can look right, so I review every change end to end, not screen by screen.
Collaboration
How PM and engineering shaped the design
A lot of the key decisions didn't come from me alone. Here's what I asked, what I learned, and how it changed the design.
Engineering · Pricing on the map
I asked whether we could show prices on pins. One pin on tap works today, but pricing many at once needs new backend work. That's why prices appear only after a search, on a small set of results.
Engineering · An open question
Some locations have several rate options, so which price do we show? We haven't solved it yet, and it's on our list before launch.
Design team · Building on past work
I built on my team's filter concept and our 2021 research instead of starting over. It confirmed the need, and showed exactly where filters fall short on tiered pricing.
Maps team · Distance from where?
Distance from you versus from your destination was an unsolved question for filters. AI search answers it, because the destination comes from the request itself.
PM · Scope and success
We aligned early on a focused first version: AI search on the map, alongside the map fixes, measured against the 66.5% drop-off. A general chat agent and voice-first were set aside for later phases.
PM and engineering · Getting it built
We reviewed my prototype together, walking through tiered pricing, permit, and overnight scenarios so engineering could scope the backend. That's how it got onto the roadmap.
Success metrics
How we'll know it's working, and where it could break
One main metric tied to the problem, a few quality signals, and guardrails that catch harm even when the main number looks good.
Primary
Search to session
How often AI search leads to parking, compared with regular search, against the 66.5% baseline of people leaving.
Quality
Pill edits and speed
How often people fix a pill, which tells us how well we understand them, plus time to choose a spot.
Lasting value
Repeat use
Whether people come back to AI search, not just try it once out of curiosity.
Guardrails: signs AI search is causing harm, even if conversion goes up
Wrong-spot sessions: parking started at a spot that doesn't fit the request, like a permit zone without a permit. That could mean a ticket, so the target is zero.
Price surprises: how often the final price is higher than the estimate, and price-related support tickets.
Regular search stays fast: no slowdown for people who just type an address or code.
Open risks I'm working through with engineering: backend support for pricing a result set, which rate to show when a spot has several, walk-time routing, access to restriction and permit data, and keeping interpretation instant inside a 30 to 60 second window.
Responsive web
The same search, with more room on the web
On desktop, the AI search panel sits beside the map, so the pills, results, and priced pins stay in view together. The same pills, including your permit pill, appear on every screen, and the pins quote the same totals as the list. On phones, it becomes the same list and map switch as the app.
What's next
AI helps where people explore. Agents act where the location is certain.
Why not an agent on the map
Payment has to match exactly where the car ends up. An agent shouldn't choose a spot someone hasn't seen, or pay before they're there.
Where an agent could help
Known spots, recurring parking, session lengths that follow the rules, and extending an active session. Never while someone is driving.
A result card built for deciding
A future concept to research: lead each result with the location, walk time, and total for the stay. The MVP keeps the app's existing list item for consistency.
Reflection
The work was finding where AI does something a filter can't
The easy version of this project would have been adding AI to something a filter already solves. Most of my early arguments were about convenience. The one that mattered was correctness: pricing a stay the right way. Building the prototype myself also taught me that AI mistakes look plausible, so the whole flow has to be tested, not single screens. And the split that made it trustworthy was simple: let the model understand the request, and let our data decide the answer.