Drivers switch between payment, reservation, towing, and city-ticket systems.
Recruiter quick scan
The project in 30 seconds
Research, synthesis, IA, wireframes, visual design, prototyping, and testing.
A self-directed concept developed from discovery through high fidelity.
Interviews, online discussions, app reviews, and a competitive audit.
Think-aloud tasks with urban drivers and mixed technology comfort.
Testing added Reserve and simplified Pay for a Friend and session controls.
Executive summary
One product for the full parking lifecycle
Park Pal explores what happens when a parking product supports the whole journey—not only the moment a driver pays a meter.
Urban parking is split across apps and city systems. Drivers can pay, but they still struggle with unclear restrictions, expiring sessions, disputes, and towing information.
A unified mobile experience that helps users find, verify, pay, monitor, reserve, prepare a dispute, and locate tow information from one navigation system.
I owned discovery research, synthesis, personas, journey mapping, information architecture, wireframes, visual design, prototyping, and moderated usability testing.
The product architecture changed after testing. Reserve became a dedicated tab, and Pay for a Friend was reduced to two unmistakable paths.
The final concept documents six core flows and demonstrates how research and testing changed both interaction details and navigation structure.
This is an interactive concept prototype. Real launch would require parking-provider, city, payment, towing, and regulation-data integrations.
01
Empathize
Understanding real parking frustrations before designing anything.
Research
Research combined secondary sources with real conversations, not just one or the other.
| Source | Finding | Problem identified |
|---|---|---|
| Contesting tickets is time-consuming | Long, frustrating dispute process | |
| Parking regulations poorly marked or confusing | Unclear signage → accidental violations | |
| App Store | Enforcement photo showed a different sign than what driver saw | Inaccurate or misleading enforcement evidence |
| X threads | Frustration at needing multiple parking apps | Fragmentation across apps, zones, services |
| Quora | "The app didn't notify me my time was up" | No real-time tracking or expiration alerts |
| Real conversations | People pay for a family member's parking by screenshotting a receipt or Venmo-ing them | No way to pay on someone else's behalf |
The sharpest finding came from talking to real people, not forums: the parking products reviewed did not provide a clear, guided way to prepare a ticket dispute. Participants described the existing process as fragmented across city websites, phone calls, or in-person offices. That gap justified treating the dispute flow as a core journey rather than a minor add-on.
A conversation with a San Francisco Uber driver added another real edge: he was ticketed despite believing he'd parked legally, because his block had multiple overlapping zone signs. That shaped the Parking Allowed / Not Allowed status check that appears before payment in the final flow.
User Interviews
To validate insights beyond online research, I conducted semi-structured interviews with drivers who regularly park in urban areas. The conversations focused on parking habits, frustrations, ticket experiences, and expectations for a better digital experience.
Research Methods
| Method | Purpose | Outcome |
|---|---|---|
| User Interviews | Understand real parking experiences and pain points | Identified recurring frustrations and unmet needs |
| Online Research | Review Reddit, X, Quora, and App Store discussions | Validated common user complaints |
| Competitive Audit | Analyze existing parking apps | Found opportunities for differentiation |
Interview Questions
- Tell me about the last time parking was frustrating.
- How do you currently find and pay for parking?
- Have you ever received a parking ticket?
- Have you ever disputed a parking ticket?
- What features would make parking easier?
Key Insights
"Sometimes there are three different signs on one pole, and I still don't know if I'm allowed to park."
Design Response: Added a Parking Allowed / Not Allowed verification before payment.
"Every city seems to have a different parking app."
Design Response: Combined payment, reservations, towing information, and ticket management into one experience.
"I had no idea how to dispute my ticket."
Design Response: Designed a guided dispute workflow with clear steps and evidence upload.
"I usually remember my parking time after it expires."
Design Response: Added live timers, reminders, and parking extensions.
Research → Design Decisions
| User Need | Design Solution |
|---|---|
| Confusing parking regulations | Parking Allowed / Not Allowed verification |
| Multiple parking apps | Unified parking platform |
| Difficult ticket disputes | Guided dispute workflow |
| Forgotten parking expiration | Live timer and smart reminders |
| Finding a towed vehicle | Tow lookup feature |
Synthesis
Research translated into product decisions
Each core feature had to trace back to a repeated behavior, pain point, or gap—not simply make the product feel bigger.
Confusing street restrictions
Parking-status verification
Surface an allowed/not-allowed state before payment, pending reliable city data.
Too many parking services
Unified dashboard
Keep parking, activity, reservations, disputes, and towing in one system.
Missed meter expiration
Live timer and reminders
Make remaining time visible and keep Extend one tap away.
Unclear ticket process
Guided dispute preparation
Separate details, evidence, review, and confirmation to lower cognitive load.
Unknown tow destination
Tow lookup concept
Provide a dedicated path for vehicle and next-step information.
Manual remote payment workarounds
Pay for a Friend
Turn screenshot, code, and money-transfer workarounds into a guided flow.
Competitive analysis
Audited one direct and one indirect competitor across UX fundamentals, not just feature lists.
| ParkMobile — direct | ParkWhiz — indirect | |
|---|---|---|
| Focus | Zone-based street & event parking | Pre-booked lots & garages |
| First impressions | clean layout, clear CTA | simple "where are you going" search |
| Interaction | helpful visuals, but zone-heavy | not built for street parking |
| User flow | short: enter zone, pay, park — but no fail-safe for invalid zones | fast booking, no support after booking |
| Accessibility | no dedicated accessibility mode was evident in the reviewed flow | no simplified mode was evident in the reviewed flow |
| Biggest gap | No dispute or towing support; "zone" system never explained | No street parking, alerts, or extensions |
Shared gaps across both: neither supports real-time expiration alerts, in-app ticket disputes, or towing information — and both rely on confusing zone or booking jargon instead of a map or address. These three gaps, directly mapped, became core Park Pal features: live status checks, the in-app dispute flow, and the Tow tab.
Personas
Two personas anchored every decision — a confident daily user, and a less tech-confident occasional one.
Jamie Rodriguez
34 · Office Manager · Los Angeles
"I just want to park and go — without worrying about a $60 surprise on my windshield."
Goals
- Pay for parking quickly
- Avoid tickets through better awareness
- Dispute unfair tickets easily
- Help family pay remotely
Frustrations
- Signage is confusing or hidden
- Doesn't trust the appeals system
- No alerts before time runs out
Linda Chen
61 · Retired Nurse · San Francisco
"I just want to park and go about my day without dealing with five different apps."
Goals
- Find parking without walking far
- Pay without downloading multiple apps
- Get reminders before expiration
Frustrations
- Doesn't trust app-based systems
- Was towed once, didn't know who to call
- Paid a late fine — didn't know how to appeal
Journey mapping
Mapping Jamie's full parking day — not just the happy path — showed where emotion dropped lowest.
| Stage | Opportunity |
|---|---|
| Arrives, tries to read signage | Auto-detect rules via GPS |
| Pays for parking | Scan zone, one-tap pay |
| Goes to work, forgets meter | Expiration reminder + one-tap extend |
| Returns to a ticket | In-app proof of payment |
| Disputes the ticket | Guided appeal form with photo evidence |
02
Define
Turning research into one clear problem to solve.
Problem statement & goal
Problem statement: Urban drivers need an easier way to manage parking because current systems are fragmented, confusing, and difficult to use — especially the moments things go wrong: a ticket, a tow, an expiring meter.
Design challenge: Design an app and responsive website that helps people find parking, pay for parking, dispute parking tickets, reserve parking, and locate towed vehicles — all in one place.
Goal: reduce the effort and uncertainty involved in common urban parking tasks. For a real launch, success would be evaluated through payment completion, time to start a session, reminder use, extension success, dispute-flow completion, tow-lookup success, and post-task confidence.
Product strategy
The differentiator is the lifecycle, not the feature count
Park Pal is organized around what a driver experiences before, during, and after parking.
1FindSearch, scan, or use location
2VerifySurface restrictions and status
3PayChoose duration and payment
4MonitorTrack time, remind, extend
5ResolveDispute, reserve, or find tow info
03
Ideate
Turning findings into structure, features, and a visual direction.
From gaps to features
Ideas were generated broadly, then narrowed to the ones that mapped directly to a research or competitive finding — not every idea made it in.
- Scan meter or sign — replaces confusing zone codes with a camera
- Live status check — surfaces an allowed/not-allowed state before payment when reliable regulation data is available
- Expiration reminders & one-tap extend — closes the "forgot the meter" gap
- Auto-saved parking location — closes the "forgot where I parked" gap
- Pay for a friend — formalizes a workaround people already do manually
- In-app guided dispute — organizes the information and evidence required by a city or parking authority
- Tow tab — concept for roadside-assistance status and a towed-vehicle database search
- Find and pay
- Parking-status concept
- Live session and reminders
- Pay for a Friend
- Reserve
- Dispute preparation
- Tow lookup
- Real payment processing
- City regulation feeds
- Parking-provider integrations
- Municipal submission APIs
- Tow-database access
- Push notifications
- Language and accessibility testing
Information architecture
Six persistent tabs, mapped directly to the pain points above — including one added after testing.
The Reserve tab didn't exist in the original IA — see the Test phase below for why it was added.
Colors & visual theme
A calm, trustworthy palette — parking is stressful enough without a loud interface.
Primary blue
#0074D9 — CTAs, icons, trust
Secondary teal
#00A88E — success, "allowed" status
Deep navy
#002B45 — text, structure
Headings — Space Grotesk
Space Grotesk
A geometric sans with a bit of character — used for titles, numbers, and anything that needs to feel confident at a glance.
Body text — Inter
Inter
Optimized for legibility at small mobile sizes — matters for a persona like Linda who needs to read status text at a glance, fast.
04
Prototype
Building the app from rough sketches to a fully interactive high-fidelity design.
Low-fidelity wireframes
Structure and flow first, before any visual design existed. These are the original wireframes, checked informally with a few people before any time went into high-fidelity design.
High-fidelity mobile design
Selected final screens shown at their original aspect ratio inside responsive mobile mockups. Open any screen to inspect it at full resolution.
User flow
Redrawn from the original FigJam flow map — same content and connections, new layout, to read cleanly at case-study scale.
Menu by menu: what I built and why
Not every screen — the ones that best show the reasoning, including what I turned down.
1Park now
Scan meter
Enter zone manually
Set duration
Pay
Why these decisions
Scan is the default because it removes reading and re-typing a zone number — the exact task where the Uber driver's story showed people misread overlapping signage.
Duration and payment stay as two screens, not one: testing showed combining them made the total price harder to verify before committing, so the cost of an extra tap was worth it for the confidence it bought.
An auto-selected default duration was on the table early — it would save a step for most sessions. I didn't build it, because Jamie and an occasional parker like Linda have different enough typical session lengths that a smart guess would be wrong often enough to cost more trust than the tap saves. That's a call I'd want real usage data to check, not just five testers — five people can't tell you the actual spread of session lengths across a real user base.
2Reserve ahead of time — added after testing, see Test phase
Search reserved parking
Compare garages
Book & confirm
Why these decisions
Results show as a comparison list first — rate, access hours, live spot count side by side — because the decision here is "which garage," not "where on a map," and a list compares faster than pins do. Reusing Park's map-first layout here would have kept the two flows visually consistent, but consistency isn't automatically the right call — on-demand parking and advance booking are different decisions with different priorities, and matching layouts just to match them would have optimized for a tidy design system over how people actually decide.
3Managing an active session
No active session
Active + dispute status
Upcoming session
Why these decisions
Active, Upcoming, and Past live as tabs on one screen so Extend and End Session are one tap away without navigation — directly targeting the "forgot the meter was timed" moment from the journey map.
A dispute's status surfaces at the top of Active rather than inside Settings, because it's the single highest-anxiety item a returning user might have — burying it would have optimized for a tidy IA over what the user is actually anxious about.
4Let a friend pay — the hardest task in testing
Generate or enter a code
Share the code
Friend enters the code
Why these decisions
Rebuilt after testing showed participants unsure how the code should be generated, shared, or redeemed. The fix was reducing the entry point to two big, clearly labeled buttons instead of one ambiguous action, so each side of the interaction has its own obvious next step.
A shareable link instead of a manual code is a real alternative worth building alongside this, not instead of it — for a recipient who already has Park Pal installed, a link is faster than typing a code. The code stays useful specifically because it doesn't assume the other person has the app at all, which matters for a feature meant to help less tech-confident users too. Shipping only one of these was a scope call for this round, not a final answer.
5Towing
Roadside assist or search database
Describe the situation
Live driver search
Why these decisions
Two entry points because they're two emotional states: requesting a tow is planning ahead, searching for a missing car is already panicking. Splitting them means each path asks only what's relevant to that situation, instead of a single form trying to serve both moods at once. The trade-off is that it asks a stressed user to self-diagnose which path they're in before they can act — and none of the five testers were in a genuinely panicked state during a session, so that assumption is untested, not confirmed.
Designing for a high-stress task
Details and evidence are separated so users can focus on one decision at a time.
The prototype avoids automatically generating a legal-adjacent statement.
A reference number, status, and expected review window reduce uncertainty after submission.
A launch would need jurisdiction-specific requirements, disclaimers, and secure evidence handling.
6Dispute a ticket — a high-stress, city-dependent process
Enter dispute details
Upload evidence & explain
Submitted & tracked
Why these decisions
This flow organizes information users may need when working through a city or parking-authority dispute process. It is split into contact and ticket details, then evidence and explanation, so the task feels sequential rather than like one long legal form.
The confirmation screen gives a ticket number, a status, and a 5–7 business day expectation up front — because the worst outcome for an anxious user isn't a slow review, it's silence.
I considered an AI-assisted explanation draft, but did not include it. A dispute is a legal-adjacent statement, and automatic wording could introduce details the user did not intend to claim. The safer concept keeps the user in control and could offer neutral prompts instead of generated testimony.
Inclusive design
Accessibility: demonstrated versus planned
The prototype demonstrates some inclusive interaction choices. Other features require implementation and formal testing before they should be claimed as accessible.
- Plain-language labels and status messages
- Consistent confirmation before irreversible actions
- Large primary actions and repeated navigation patterns
- Errors placed next to the field or action that needs attention
- High-priority controls kept close to the active task
- Dynamic text sizing and reflow
- Screen-reader and switch-control testing
- Reduced-motion behavior inside the product
- High-contrast theme validation
- Voice input where it improves—not complicates—the task
- Translated content reviewed by native speakers
05
Test
Putting the prototype in front of real people — and changing the design based on what happened.
Usability testing
| Method | Moderated remote sessions via Zoom, using a Figma prototype, ~30 min each, think-aloud protocol |
| Participants | 5 people, ages 30–50, mostly urban California (SF / LA), low-to-moderate tech comfort, including an Uber driver who parks daily for work |
| Tasks tested | Pay for parking · set a reminder · dispute a ticket · find a towed vehicle |
| Signals reviewed | Task completion, errors, hesitation, navigation choices, and participant comments. Exact SUS scores were not documented in this case study, so they are not reported as an outcome. |
Where the Reserve tab came from: one tester said it plainly — "If I'm going to an event, how do I reserve parking? Like at a private lot?" That question, raised independently by more than one participant, was enough on its own to justify a dedicated Reserve tab rather than bolting the feature onto Park.
- "Pay for a friend" was the hardest task. Simplified to two clear buttons instead of one ambiguous action.
- Reserve tab added after repeated requests to book parking ahead of an event or in a private lot.
- Extend and End Session refined to be one tap from Activity, with no extra navigation — testers were losing time hunting for these controls.
- Reminders confirmed as essential, not optional — every tester who missed a step in testing said a reminder would have prevented it.
Before and after
Testing changed more than visual polish
Before
Remote payment began with one ambiguous action.
After
Two explicit paths: generate a code or enter a code.
Before
Reservation was not a persistent destination.
After
Reserve became a dedicated tab after repeated requests.
Before
Extend and End Session required extra navigation.
After
Both actions moved directly into the active-session card.
Outcome: testing changed the product architecture and reduced ambiguity in the most difficult tasks. The evidence reported here is qualitative: what participants struggled with, what changed, and why. A future round should document comparable task metrics and a consistent usability scale before making numerical improvement claims.
Implementation thinking
What it would take to launch
The prototype demonstrates the experience. A trustworthy product would depend on accurate integrations, clear responsibility boundaries, and careful handling of location, payment, and evidence data.
Municipal regulation feeds, meter and zone data, parking-provider inventory, towing databases, and city-specific dispute requirements.
Secure payments, consent-based location access, evidence retention rules, account recovery, and clear data-deletion controls.
Jurisdiction-specific disclaimers, accurate submission instructions, and no promise that Park Pal can override or guarantee a city decision.
Screen-reader testing, dynamic type, translated-content review, low-connectivity states, and testing with older and less tech-confident drivers.
Proposed post-launch metrics
Payment completionTime to start sessionReminder activationExtension successDispute completionTow-lookup successReservation conversionPost-task confidence
Reflection
What I learned
Designing one understandable system across services that are normally controlled by different providers and city agencies.
The Reserve tab proved that usability testing can reshape product architecture, not only button labels and spacing.
Park Pal covers a broad lifecycle. The next round should go deeper on fewer high-risk flows—especially dispute and towing—before expanding further.
Drivers with recent ticket disputes, older adults, commercial drivers, and people using assistive technology or limited cellular data.
Explore the final interaction
View prototype ↗
Open the official Figma prototype to test the key flows.