Coursework
Interaction Design x University of Michigan
SpotUp:
Parking Made Easy
for campus drivers
Role
Product Designer
Team
4 Members
Timeline
~3 Months
ONE APP. EVERY PARKING SITUATION ON CAMPUS
A mobile parking companion for Ann Arbor drivers: search, pay, and manage sessions across street, private lots, and university parking.
PROBLEM WASN'T FINDING A SPOT. IT WAS LACK OF INFORMATION
Fragmented rules, late cost visibility, and unclear eligibility forced drivers into guesswork under time pressure.
PARK ANYWAY YOU WANT. THE APP ADAPTS TO YOU
Whether you paid at a kiosk, have a university pass, or just want to track your time, one app that works with how you already park, not against it.
01
The problem wasn't availability. it was uncertainty
Drivers were choosing between options without clear information on rules, pricing, time limits, or eligibility. The unknowns — not the lack of spots — caused stress, inefficiency, and avoidance.
02
Parking wasn't broken. The information around it was
8 interviews with campus drivers were conducted: students, commuters, and a visitor. We weren't collecting feature requests. We were mapping where decisions broke down.
I used to avoid parking in street parking spots because I was unsure about the rules.
FREE WINDOWS > PRICE
Users restructured their day around after-6pm free parking, not price comparisons
FRAGMENTED TOOLS
Payment, maps, and eligibility lived in separate apps with no unified path
ONBOARDING FAILURE
Newcomers learned rules by trial and error, often after getting fined
03
We were designing screens before agreeing on what situations they needed to handle
I mapped every distinct parking scenario: street, private lot, university pass, pay-on-entry, pay-on-exit, session extension and walked the team through each one. It exposed contradictions in our flows early, before they became visual debt.
04
Uncertainty doesn't just frustrate users. It makes them avoid the system entirely.
Three system-level decisions shaped the product.
SURFACE COST BEFORE COMMITMENT
Rules, pricing, and pass eligibility appear on the lot detail screen, before the user taps Begin Parking.
SESSION AS A PERSISTENT OBJECT
Once parked, the session lives on the dashboard and is recoverable from anywhere in the app.
DESIGNING FOR THE OFFLINE PAYMENT
Users who paid at a kiosk can still log and track their session. Designing only for in-app payment would have excluded this.
Pricing and parking type are visible beofre users commit to a session
Availability indicators help users evaluate trade-offs quickly
Parking is treated as an ongoing session users can monitor overtime.
Quick actions reduce the need to return to physical meters
The system supports multiple payment behaviors instead of assuming app-first payment
05
Language, layout, and cost visibility — all broke in testing.
5 moderated usability tests across 3 core flows were conducted.
06
The system, built.
This section highlights the transition from wireframes to final designs.
07
Three things I'd do differently.
1
More interviews with a tighter user scope.
The people most affected by Ann Arbor's parking complexity — daily commuters and first-semester students — were underrepresented. More time with them would have sharpened the problem definition earlier.
2
Start with competitor analysis, not from scratch.
We spent too long building foundational logic that existing parking apps had already solved. Starting with what competitors do well — and where they fall short — would have freed us to focus on the genuinely novel problems sooner.
3
Run a second usability test.
We made significant changes after testing but never validated them. That's an open loop. A second round would have confirmed the fixes held up and surfaced edge cases we didn't design for.
Spot Up was a collaborative effort shaped through constant discussion, critique, & iteration
