Natural language search for PayByPhone
Describe the parking you need and get the spots that fit, instead of guessing at rows of identical pins. An AI search layer for PayByPhone's map, researched, designed, and prototyped, now heading to development.
Role
· Design lead
Team
· 1 PM, engineering partners
Scope
· Research, design, working prototype
Status
· In progress, heading to development
Add image
Suggestion_chips.png
Add image
Video frame: pills forming (0:19)
Add image
Video frame: priced pins on the map (0:27)
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
2.4×
what the cheaper-looking spot really cost for the same 3-hour stay ($8.91 vs $3.75)
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.
Add image
Amplitude funnel chart: map viewed vs. location selected
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.
Add image
Today's map: a dense cluster of identical pins
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 cheaper-looking spot cost more than twice as much
Most of my arguments for AI were about convenience. This one is about correctness, so it became the lead.
Flat rate, $2.97/hr
$8.91
for 3 hours. Looks cheaper per hour, costs more for the stay.
Tiered, $1.02/hr for 2 hours, then $1.71/hr
$3.75
for the same 3 hours. AI search ranks this one first.
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
Add image
Team filter concept
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
Add image
Unified_search_bar.png
One bar for both
✗ Is "Denman" an address or an AI request? Guessing caused layout jumps
Add image
After_clean_map_AI_prompt.png
AI prompt above search
✗ A floating prompt adds noise for people who just want to type an address or code
Add image
AI_suggestion_chips.png
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
Add image
Collapsed_search_bar.png
Ask AI button
✗ Splits search into two competing actions, and AI feels bolted on
Add image
Collapsed_AI_search_sheet.png
AI drawer, collapsed
✗ Puts standard search behind an AI-first layer, slowing the most frequent task
Add image
Expanded_AI_search_sheet.png
AI drawer, expanded
✗ Asks people to decode a conversational layout in a 30 to 60 second window
Add image
Bottom_search_mode_switcher.png
Mode switcher
✓ Selected · intent is clear before typing, and routine search stays fast
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
They update as you type, so a misread is visible right away.
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
Add image
Suggestion_chips.png
Suggestions lead with multi-constraint examples
Add image
Video frame 0:14, typing
Typing a request
Add image
Video frame 0:15, first pill
The first pill appears
Add image
Video frame 0:19, all pills
Each part of the request, removable
2 · Check the rules people can't see
Add image
Cross_zone.png
Within a 15 min walk, along real streets
Add image
Overnight.png
Overnight rules checked for every spot
Add image
permit_aware.png
Permit zones only when you have one
Add image
Max_stay.png
Totals for the stay, not just hourly rates
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, so there's no mental math between views.
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.
Permit zones left out by default
A small tag is easy to miss when scanning fast. Showing a spot someone can't legally use is worse than a shorter list.
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.
In motion
The working prototype, end to end
I built it with Claude Code so I could test real scenarios end to end. Watch the pills form as the request is typed, then the results appear on the map with prices. Tapping a spot opens the park flow people already know.
Add video
Prototype_AI_search_PBP.mov
Validation · Usability testing
Moderated sessions with the working 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 the working 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
Draft findings. Replace with real results before publishing.
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.
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 [Draft]
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 [Draft]
We reviewed the working 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.
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.
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.
Add image