Context
Self-directed · External brief
Role
Sole designer
Duration
6 months, part-time
Scope
Research · IA · UI · Framer build
Designing trust into peer‑to‑peer parking
In dense San Francisco neighborhoods, drivers circle for up to an hour while driveways on the same blocks sit empty most of the day. "Airbnb for driveways" was the obvious framing, and the wrong one. Testing the competing platforms hands-on showed their trust machinery is largely decorative: "verified" badges that never say what was checked or how to earn one, nonsense listings that go live unchecked, ownership checks a passport can pass. And in user reviews, renters lose confidence at arrival — wrong map pins, unclear instructions, nobody to call.
So I designed for trust and coordination rather than discovery. Three decisions shaped the product:
Request-only booking. Slower by design: a new marketplace has no reputation history, so every booking passes through the host.
Photo-guided arrival in MVP; turn-by-turn navigation deferred. Photos solve the last hundred meters at a fraction of the engineering cost.
Switching roles changes one tab, not the whole app. The platforms I tested put hosting in a separate mode, in extra menu items, or on their website. I kept one navigation for both roles.
The Problem
San Francisco parking is a design problem rather than a supply problem because the driveways are already there: private, secure, within walking distance, and off the street. The brief came from an SF-based contact who sat for one scoping interview; from there the project was mine end to end. With no client, engineer or other stakeholder to push back, every trade-off was argued against the research instead.
Street parking
Dense urban neighborhoods
Up to 1 hour searching
Red curbs, permits, construction
Fines and towing
Break-in and theft risk
Private driveways
Same neighborhoods
Empty 8+ hours per day
Walking distance from the destination
Secure, private, off-street
Already built, already paid for
Same blocks, opposite problems — and no way to connect the two sides.
One owner can sit on both sides. Beyond the research's two roles — a commuting renter and a homeowner host — the model implies a third no participant described: an owner who drives to work, leaving their driveway empty while they need a space elsewhere. I didn't validate it, but it's cheap to design for, and it's why renting and hosting share one account.
Out of scope: regulation. Renting out a private driveway in San Francisco is contested legal territory. I scoped this project to the experience layer; in a real product, compliance would be a gating dependency.
Two Users, Two Failure Modes
Review and forum observations were clustered into themes and split by side of the marketplace. Each side fails at a different moment: hosts before they ever list, renters on arrival.
Hosts
Sandra Collins and similar
FINANCIAL
Earn reliable passive income with minimal administrative effort
Unclear platform fees and hidden deductions make actual earnings hard to predict
CONVENIENCE
Automation — payment, calendar, booking — removes friction and manual management
Advance bookings let hosts retain control over their space and schedule
SAFETY & SCAM ISSUES
Fear of fraud — driveways listed without homeowner permission, poor enforcement
Most hosts report little property damage concern when using vetted, trusted apps
TRUST & COMMUNICATION
Verified renter profiles and responsive support build host confidence
Misunderstandings over parking rules lead to low ratings and stress
Regulatory clarity and transparent policies significantly reduce host anxiety
Renters
David Nguyen and similar
FINANCIAL STRAIN
Constant fines from tickets, towing, and unexpected costs — even when following the rules
Neighborhood reporting and confusing regulations trigger fines unpredictably
STRESS & LOST TIME
Up to an hour circling for a spot in dense or event-heavy areas
Unclear and conflicting regulations — especially for driveway and street cleaning rules
CAR SAFETY
Persistent worry about break-ins and theft, especially in popular or free parking areas
No fully safe option — even paid lots are viewed as unpredictable and insecure
TRUST & NEGATIVE EXPERIENCES
Inaccurate listings, unresponsive hosts, and apps that do not match reality erode trust
Booking in advance through an app significantly reduces stress and uncertainty
Hard to find the exact driveway entrance — unclear instructions and wrong map pins
Green marks what already works in existing platforms — the parts worth keeping.
Two people carry those themes through the rest of the case study. David, a commuter without assigned parking: when I need to get to work on time, I want my parking confirmed before I leave home, so I don't lose 45 minutes circling. Sandra, a homeowner with a double driveway half-used on weekdays: when only half our driveway is in use, I want to earn from the empty half without managing it manually.
Research
Three sources: one semi-structured interview with the SF-based contact who brought the brief (the reason the scope is San Francisco), netnography across app store reviews and owner/driver forums, and a hands-on competitive audit of 19 parking platforms.
Of the 19, 14 were commercial lots and city apps; they set the baseline for plate entry, vehicle size and access codes. The other 5 let anyone list their own space, the model this project is built on: ParkingMate, Prked, PRK'n, JustPark and YourParkingSpace. I signed up, searched, listed where the flow allowed it, and booked up to the payment screen. They differ widely in maturity — JustPark has dense London supply, PRK'n had almost no US inventory — so a bug in one isn't always a pattern across the category.
Why these methods. I couldn't recruit drivers or owners in a city I don't live in, so I went to the drivers and owners already describing their problems in reviews and forums. Netnography shows where users feel the product fail; the audit shows where the interface breaks. The findings below come from the audit. It stops at payment, so every arrival claim comes from netnography.
finding 1
The badge is not attached to anything
On ParkingMate, a listing with a nonsense description and a New York address I have no connection to went live immediately — on a platform that shows Verified host badges, yet nowhere in the app could I find how to become one. The others check little more. JustPark held my PO Box listing back, but for a foreign phone number, an address Maps couldn't find and a profile name — nothing about who owns the space. YourParkingSpace reviews listings without saying what it checks, and Prked asks for a document only after the listing is created, accepting a passport as proof of ownership. So the Spare host badge names what was checked: ID and ownership verified.
ParkingMate shows verified hosts and published a nonsense listing; Prked accepts a passport as proof of ownership.
finding 2
No shared answer to where the host side lives
The five platforms put the host side in three different places. Prked and PRK'n switch into a separate host mode that replaces most of the navigation. ParkingMate and JustPark add host items to the profile menu. YourParkingSpace sends hosts to its website. Where the mode swaps, a host who also rents has to leave one side of their day to check the other. Spare keeps one navigation and changes only the first tab.
Three platforms, three places for the host side: a separate mode, a menu, a website.
From Journey to Product Decision
Three sources: one semi-structured interview with the SF-based contact who brought the brief (the reason the scope is San Francisco), netnography across app store reviews and owner/driver forums, and a hands-on competitive audit of 19 parking platforms.
Of the 19, 14 were commercial lots and city apps; they set the baseline for plate entry, vehicle size and access codes. The other 5 let anyone list their own space, the model this project is built on: ParkingMate, Prked, PRK'n, JustPark and YourParkingSpace. I signed up, searched, listed where the flow allowed it, and booked up to the payment screen.
Why these methods. I couldn't recruit drivers or owners in a city I don't live in, so I went to the ones already talking in public. Reviews show where users feel the product fail; the audit shows where the interface breaks. The findings below come from the audit. It stops at payment, so every arrival claim comes from reviews.
Arrival instructions are unclear; wrong map pins are a recurring complaint
Help renters find the exact entrance without confusion
Photo-guided arrival — three required shots in listing setup, in the order the driver sees them
Fraud risk: scammers list driveways without owner permission
Build trust before any transaction
Verification matched to risk — ID and ownership for hosts; phone, card and plate for renters
Renters report fines even when trying to follow the rules
Take the guesswork out of where it's legal to park
A confirmed private spot instead of the street, with size limits and house rules on spot detail
Hosts fear unknown renters on their property
Give hosts control over who they accept
Request-only booking — the host sees the renter's history and vehicle before accepting
Hosts can't estimate earnings due to hidden fees
Transparent, predictable payout structure
Payout shown with rate, daily max and fee on every request
No support after booking if something goes wrong
Make post-booking support a first-class feature
"Report an issue" pinned on the active booking, never in a menu
Six observations, six product decisions. Two of them — photo-guided arrival and persistent incident reporting — went straight into MVP.
Prioritization
I placed every feature on two axes: how much it improves the experience for renters and hosts, and how much work it takes to build. The MVP is the top-left corner — high impact, low effort. Everything else waited for a later release. About 20 features made the cut.
The matrix plots the features central to the prioritization decision. Lower-impact items were assessed but left off to keep the trade-offs legible.
No instant booking. Request-only is slower and costs conversion. I chose it anyway: at launch there's no reputation history, and Sandra's blocking concern is control over who parks on her property — remove her approval and you remove her reason to list. Instant book becomes viable once reviews can carry the trust load: phase two, not cut.
Photo-guided arrival in; turn-by-turn navigation out. Both address the same friction, but photos solve the last hundred meters, where the failure actually happens, at a fraction of the build cost. Google Maps already handles the rest.
Verification matches the risk. A host is paid and lets strangers onto their property, so they verify identity and ownership. A renter only needs the spot for a few hours, so a phone number, a card and a plate are enough; full ID checks wait until there's a reported incident. Browsing needs no account and no sign-up at all.
Incident reporting stayed in MVP for the same reason arrival did: problems on site need resolution in the moment, not a support email.
Final Design
One navigation, four tabs, the same positions in both roles. Only the first slot changes — Search when renting, Dashboard when hosting — so switching roles never moves the furniture.
Bookings and Messages each hold both roles in one place, because for a commuting host both can be live at once: their own car parked somewhere, someone else's on their driveway. Both filter to All, Parking or Hosting, and on All a small label marks which side each entry belongs to. Both work the same whichever first tab is showing.
One booking, both sides: David requests Oak Street Garage for Friday; Sandra accepts it.
renter
Find a spot
David is deciding where to park before he leaves. The map carries the price, and the list is the same search seen another way.
1
The price is on the pin
A pin that only marks a location makes the renter tap each one to compare. The rate sits on the pin, so the map itself is the comparison.
2
The preview comes before the detail
Tapping a pin opens a short card — photo, walk, rating and the total for the chosen hours — not the full page. It costs one tap to dismiss and the map stays visible behind it.
3
The list is the same search, not another place
The sheet expands into the list without changing screen, and the search and filters stay where they are above it.
4
Nothing matches, something to do
When the search returns nothing, the map stays and the screen offers a way to adjust it rather than an empty page.
Scroll inside the screen
renter
Spot detail
The screen where David decides whether a stranger's garage is worth the trip.
1
The badge says what was checked
A plain "verified" label can mean anything, so this one spells it out: ID and ownership. Renters go through different checks and never get the same wording.
2
Walking distance from the destination
An address doesn't say how long the walk is. The distance is measured from David's destination and sits under the title.
3
Size limits and what they mean for your car
The listing states what fits, and the line under it answers it for the car on David's profile. Both stay, because he won't always arrive in that car.
4
Price with a ceiling
An hourly rate alone punishes a long day, so the daily max sits beside it and the worst case is visible before the calendar opens.
5
Only what the spot has
Listing every amenity with a tick or a cross would make a plain driveway look broken. Only what's there is shown; what isn't is handled by the filters.
host
Host dashboard
Hosting takes over the first tab. The rest of the app stays where it was, and both roles switch from Profile.
1
Only the first tab changes
A full host mode would give hosting more room, but a host who also rents would relearn the app on every switch.
2
The pending request is the top priority
Requests expire, so a missed one costs a booking on both sides. It gets the darkest surface on the screen; earnings and payouts are things to check, not to do.
3
Earnings to check, not to manage
Earned, bookings and rating sit in one row, and the payout row under them shows what's on its way. Sandra glances at them; nothing there asks her to act.
4
Block hours, don't delete the listing
Hosts hold back the hours when they might need the car, and they shouldn't have to delete a listing — and its reviews — to do it. Blocking hours and pausing sit on the listing card.
host
Booking request
Sandra is deciding whether to let a stranger onto her property, with a clock running.
1
A clock beside the decision
The countdown sits directly under Accept and Decline, where the decision is made. If it runs out the request declines itself and David's card is released; until Sandra decides, he can also withdraw.
2
Who, before what
Renter, history and vehicle come before dates and payout, because the trust decision has to be made before the logistical one is worth reading.
3
The payout shows its working
The rate, the daily max and the fee are all on the card, so $48.60 can be checked rather than trusted: eight hours capped at $54, minus 10%.
4
Ask before you commit
Message sits inside the renter card, so a question costs nothing before Sandra accepts or declines.
Renter
Active booking
David is a few minutes away, and the last hundred meters is where every other part of the booking can still fail.
1
Directions, not a description
Three photos from the driver's seat: the house, the keypad, the empty garage. The listing flow requires them in that order, so the host shoots a sequence, not a gallery.
2
The address hands over to Maps
Tapping the address opens the phone’s own navigation. From the curb onwards, the photos take over.
3
Help is one tap away, always
Report an issue stays pinned at the bottom, never in a menu. If the garage is taken, Sandra gets ten minutes to clear it; if she can't, David's $54 comes back and the app shows the nearest open spots.
4
Check in starts the session
After check-in the photos fold away and the time left and Check out take their place. The spot is David's from 9:00 to 5:00 either way.
Scroll inside the screen
Validation — planned, not yet run
This was a self-directed project, scoped to research and design, so the prototype hasn't been tested with users yet. Nothing on this page claims the design works better — only that it's more consistent and more explicit than what I audited.
The plan is five moderated sessions of thirty minutes on the clickable prototype, because the open questions are about comprehension, not preference. Two tasks: book a spot and arrive at it; receive a request and decide on it. Three assumptions carry the most risk. That a driver can match each arrival photo to what's in front of the windshield. That Report an issue is found without a hint when the garage is occupied. And that a host reads the payout and the countdown before deciding, not after.
What I'd Measure
This never shipped, so there are no results — only a definition of what would count as working, written before launch.
Three metrics, one per decision:
Request-to-approval rate — what request-only booking costs.
Incidents reported at arrival — whether the photos do their job.
Listing completion rate — whether hosts get through the longest flow.
If too many requests expire or get declined, request-only is costing more bookings than the trust it buys, and instant booking moves up from phase two.
Reflection
What I got wrong, and changed. My first IA put renting and hosting behind a mode switch, because I had treated renters and hosts as two different people. The audit undid that: where the whole interface swaps, anyone on both sides relearns the app with every switch (Finding 2), and the owner who drives to work is on both sides on the same day. I rebuilt the navigation around one constant structure with a single swapped slot — the one decision I reversed after the research was supposedly done.
What I'd do differently. Talk to real users early instead of leaning on secondary research: David and Sandra are reasoned, not observed. And test listing creation with actual hosts sooner — it's the most complex flow and the one forums can't reveal.
Who I didn't design for. The interview described a renter this product doesn't serve: residents without a garage spot who come home at night and park far from their building, especially on street-cleaning days. Their demand peaks in the evening, when homeowners are back and driveways are full, so the daytime supply this product is built on doesn't reach them.
How I used AI. I used AI for desk research, synthesis, first-draft wireframes, the arrival photos and drafting this write-up. Every audit claim was checked against my own screenshots, the final UI is mine, and every design decision was mine to argue, not generated.