UrbanPark
A peer-to-peer marketplace for unused driveways.
Challenge
Drivers spend an average of 17 minutes searching for parking per trip in dense urban areas. That circling accounts for roughly 30% of downtown traffic - and generates an estimated 900,000 tons of CO₂ annually across U.S. cities.
UrbanPark starts with the other side of that equation: the empty driveway. Most homeowners who commute by transit or work from home have a concrete pad sitting unused from 8 AM to 6 PM. The opportunity is a two-sided marketplace connecting the two - drivers who need a reliable, reserved spot, and homeowners with idle space and no friction-free way to monetize it.
The product challenge isn’t matching supply to demand. That part is a database query. The real challenge is building trust between strangers over something as personal as their car and their home - in real time, under time pressure, with money changing hands.
Research
16 interviews. Two completely different definitions of safety.
We ran 16 interviews split evenly between daily commuters and homeowners in neighborhoods with known parking pressure. The motivations were immediately asymmetric.
Drivers: predictability was the core need, not price. “I don’t mind paying more if I know the spot will be there.” Drivers who’d used existing apps cited photos that didn’t match reality as the primary trust failure.
Homeowners: the barrier wasn’t platform trust - it was stranger trust. “What if they block my garage?” “What if something happens to my property?” Insurance, accountability, and cancellation policies surfaced in 7 of 8 homeowner interviews before we asked about them.
Six apps. None solved the trust handoff.
We mapped SpotHero, ParkWhiz, Neighbor, JustPark, Parkopedia, and Rover (as an analogous trust model). The pattern: apps that aggregated parking lots (B2B supply) handled search well but didn’t need to solve person-to-person trust. Apps with P2P supply (JustPark, Neighbor) had the right model but shallow verification and no in-app handoff communication. Rover’s trust architecture - background checks, review systems, in-app messaging, and structured meet & greet flows - was the closest analogue to what UrbanPark needed.
Two users. Opposite anxieties.
Maya, 31 - software engineer, commutes to campus three days a week. She’s used parking apps before and abandoned spots that didn’t match their photos. Core need: reliability. Willing to pay a premium for a guaranteed, confirmed spot.
David, 55 - homeowner, car in the shop two days a week, interested in passive income. His driveway sits empty. Core barrier: liability and damage. Needs to feel in control of who accesses his property and what recourse he has if something goes wrong.
The trust gap lives at the handoff moment.
Mapping the full journey for both users surfaced a critical insight: the highest-anxiety moment for both sides wasn’t payment - it was arrival. When a renter shows up and the driveway is blocked, or when an owner hears someone on their property without warning, neither party has a reliable channel to resolve it. That single insight shaped the entire verification and communication design.
Design System
Before designing screens, I built the component library. This isn’t how academic projects typically work - students usually skip straight to high-fidelity. I did it first because I’d learned from a previous project that designing without a system produces inconsistent work that’s painful to maintain and impossible to hand off. The system has six component categories, documented with all states, interaction behavior, and edge cases, built in Figma with auto-layout, component properties, and a token-based color and type system.
I built a similar enterprise-grade design system at ZingHR for their B2B HR platform serving 500,000+ daily transactions - but that work is under NDA. UrbanPark demonstrates the same methodology: component-level thinking, systematic state documentation, and token-based design - applied to a consumer product I can show.
Solution
Three distinct flows - homeowner onboarding, renter search and booking, and the verification layer that sits beneath both - each designed as a standalone journey that shares a common trust architecture.
Homeowner: List your driveway
Onboarding is structured as building a listing, not filling a form. Four steps: add your address and photos, set your available hours (weekly repeating schedule by default, with override by date), set your price (with a suggested range derived from nearby verified listings), and complete identity verification. The listing goes live only after ID verification clears - a gate that reduced fraudulent listings in our prototype testing to zero.
The pricing step shows a suggested range before asking the owner to enter a number. Anchoring against real data from nearby listings increased confidence and reduced “analysis paralysis” in testing - owners who saw the range set a price 40% faster than owners shown a blank input.
Renter: Search, book, and navigate
Search is map-first. The filter panel surfaces the three criteria our research identified as primary: price range, walking distance from destination, and verification status. Ratings and amenities are secondary filters collapsed by default. The booking confirmation screen is the longest in the app - it deliberately surfaces every relevant detail (cancellation policy, check-in instructions, owner contact) before payment commits, because that’s when both sides need the most clarity.
Navigation on the booking confirmation screen opens the renter’s default maps app, not an in-app map. This was a deliberate reduction in scope. Renters already trust their maps app. Building a navigation layer would have added complexity without adding trust, and our research showed that renters switch to their maps app at arrival regardless.
Verification: Building trust in layers
Verification has three layers: identity (government ID upload, face match), vehicle (plate number, make and model), and property (address confirmation via Street View match). None of these are novel individually. The design challenge was sequencing them so they didn’t feel like interrogation - and communicating to both sides exactly what the other party has verified. A renter seeing a “3-layer verified” badge on a listing knows specifically what that means.
The verification badge is broken into three visible tiers on the listing page - not a single binary “Verified” checkmark. Transparency about what each layer verifies increased renter confidence in testing more than the verification itself did. People trust what they understand.
Reflection
What I learned
Designing for two user types simultaneously teaches you that personas are constraints, not portraits.Every feature decision had to hold for both sides. A cancellation policy that’s generous for renters creates anxiety for homeowners. A verification step that builds trust for renters feels invasive to homeowners if it’s not framed carefully. The tension between the two sides was the actual design problem - not the individual screens.
Building the design system before the screens fundamentally changed the quality of the work.Working from components produces designs that cohere. Working free-form produces screens that look fine individually but don’t read as a product. This was the most transferable lesson from the project.
What I’d change
The in-app messaging feature was designed but not prototyped.That was a mistake. In testing, the highest-anxiety moment for both sides was the physical handoff - the renter arriving, the owner not sure what car to expect. A simple message thread with vehicle photo confirmation would have addressed this directly. I ran out of time to build it properly and shipped the conceptual spec without the interaction design. I’d go back and do that first.
I’d test with actual strangers earlier.Our usability participants were recruited from the university community - people who know each other, share campus, and have an implicit baseline of trust. The trust barriers for true strangers in a dense city are higher. I suspect the verification flow would have looked different if we’d tested with participants who had no social overlap.
How this informed my professional work
UrbanPark was the first time I built a design system from the ground up. At ZingHR, I applied the same methodology at enterprise scale - systematic tokens, exhaustive state documentation, and edge case coverage for a platform handling 500,000+ HR transactions daily. That system is under NDA, but the thinking is the same. Consumer and enterprise design systems differ in scope, not philosophy: both require you to think in states, not screens.
The two-sided marketplace research also shaped how I approach stakeholder alignment. Enterprise HR tools are two-sided products: HR admins configure them, employees use them. The same tension exists. The Rewards & Recognition project at ZingHR required the same discipline - designing for the person filling in the catalog and the person browsing it simultaneously, with genuinely different needs and opposite anxieties.