Just a second...
A parking mobile app screen showing spots for sale in Ann Arbor and one selected spot to see price.A parking mobile app screen showing active parking reservations and payment methods on file.
BuyMySpot is becoming the top destination to find parking 🅿️ at Big Ten university campuses. In summer 2023, I led the design of this start-up's web apps to improve search experience 🔍 and add a fresh visual style 🎨 to desktop and iOS browsers.
This complete overhaul covers primary flows, interfaces from concept to delivery, and a debut of a brand new design system.
⏰  Timeline
2 months, Jun – Aug 2023
🏋️‍♂️ Role
UX Designer, Team Lead
🧰  Tools
Figma, FigJam, Google Workspace, Miro
Adaptive design across desktop and mobile maintains one-to-one consistency
Navigating through a mobile app to find parking spots as pins on a map, and a list of corresponding parking spots
Find parking spaces closest to your destination with the map-centric display
Scrolling through a list on events on a mobile to choose an event and find parking for that event
Going to an event? 
Seek parking for that event only
Choosing payment options on the mobile app to reserve a parking spot
Reserve and easily use your payment method of choice
Finding parking is painful and time-consuming
While BuyMySpot is new on the market, our users mainly migrated from Facebook Marketplace and GroupMe. Based on interviews, I summarized key pain points in the current parking search experience.
🧐  Not enough spots listed

People often reported by the time they see a listing, there were already many comments inquiring for availability. In parking search, demand far outweighs supply, making it difficult to capture spots that suit personal needs.

😭  Effortful to message every seller

Almost every seller asks buyers to Direct Message them to get the price. But this requires a lot of futile efforts from buyers, such as DM-ing only to find out the spot is not within budget.

How Might We
create a personalized search experience that matches each buyer with spots most likely to meet their preferences?
Persona
Through interviewing potential users, I found most people fall into either 1 of 2 archetype characterized by their parking need. This archetype matters because because it is a predictor of what spots the user want to be matched with.
Oslo, the “placeholder” parker
Oslo is a student living on-campus. Oslo occasionally drives to get grocery or commute in bad weather. Most of the time, his car remains parked.
“I want a cheap parking spot to keep my car for the entire semester”
Geneva, the commuter
Geneva commutes daily from a neighboring town. Her ideal parking spot is safe, close to her office, and guaranteed on weekdays.
“I want a quick, reliable spot on the days I work”
Affinity diagram and thematic analysis
Affinity diagram from user interviews, separated into 4 main headings: "Why is parking a pain," "How I find parking," "What's important to me," "Other data."
Affinity diagram from user interviews, separated into 4 main headings: "Why is parking a pain," "How I find parking," "What's important to me," "Other data."
When asked "what do you look for in a parking spot?," every. single. person. did not fail to mention all of these 3 – price, convenience, and security – regardless of what they drive, how much income they make, etc.

Within the top 3, people prioritize each criteria differently. Some may prioritize cheap prices over closer parking spots, while others prefer to park close and pay the premium.
Rationale
01
Price is king
Many college students we talked to, who do not use their car often besides grocery, value affordability. They'd tell us:
  • “I’ll park far from campus and take the bus to class if I have to.”
  • “I’ll step through a pile of snow to get to my spot if I have to.”
  • “I love walking. I’d walk any distance 🚶”
Rationale
02
Convenience is king
Convenience means a short walk to the destination and ease of exit. Convenience-conscious parkers often tell us:
  • “I need to look professional, so I prefer not to walk far in humid or moist weather ☂️”
  • “I have a child. My ETA’s must be reliable.”
  • “Return on time is key to me. I don’t even look at prices.”
03
Security means something different...
...depending on who you are. Interestingly, when asked about 🔒 security expectations, each archetype raised a different concern:
“I’m cautious because what if something happens to my car?” e.g. stolen car, broken windows, flat tires.
“I’m cautious because what if something happens to me? I have to go get my car everyday.”
Interestingly, interviewees who are women or non-American always mention own safety as the first thing they consider before parking. But men and locals (to the area where they park) never even mention security until I bring it up.

Hence, while parking spots need not have air-tight security to attract purchase, they must still be transparent on security level to help out safety-conscious buyers.
In conclusion, different people are drawn to different spots. For the best experience, the search interface must enable parkers to scan spots by the strongest selling points, while careful not to show too much information to avoid decision paralysis.
Ranking search criteria by survey
To answer what are some strong selling spots that get people to purchase a parking spot, we asked 35 people to rank what they value in a parking spot. The averaged ranking echoed our interviews’ findings: Price is the top priority for most, followed by convenience and security.
Most important 👑
I don’t care 🤷
👑
🤷
1
Price
2
Walkable to destination
3
Duration to park
4
General area around
5
Security camera on site
6
In & out allowed
7
Other people see where I park
8
12 others
Card sorting, survey, and ranking matrix
Besides the averaged ranking, I also skimmed responses for variance. For example, there is not variance across responses in the case of criteria ranked first and second (Price and Proximity). People almost unanimously put those as Most Important. So, in general, information on price and proximity are most critical to spot selection.
In 3rd to 7th, I see people's desire for either convenience or security.

From 8th onwards, most people ranked them low, with an exception of 1-2 responses indicating strong desire for them. These criteria can live in a collapsible menu, where people can either choose to look for them or not be bothered at all.
Iterations
In the lo-fi stages, our efforts were divided into 2 big buckets: defining steps within the search flow (which search options need to be chosen first before progressing to others) and figuring out what pertinent information goes on Spot listing screen.
The end experience is a 3-step parking search process. By applying progressive disclosure, the task of scoping out spots that aligns with your needs is broken into smaller steps, simplifying decision-making. When tested, this new experience cut down users' search time by half, taking them to check-out faster.
☝️  Step 1: Basic requirements

A parker begins scoping by the most fundamental criteria: the location of the parking spot and the desired parking duration.

Entering 'Ann Arbor' as location in a search bar and date picking
✌️  Optional step 2: Non-negotiables

Here, the parker have choose to narrow down their selections by setting a hard upper bound on price and proximity to destination.

Initially, our proximity filter was based on miles. But after testing with non-American users, we incorporated 'minutes' as an additional measurement unit.

Changing price ranges and distance perimeter of the search area in a search menu
👌  Optional step 3: Preferences

This step includes all other filters, covering a wide range of preferences and amenities. These filters are conveniently grouped under the 'All Filters' expansion menu, allowing for a more in-depth personalized search as the user progresses in the experience.

🎉  Successfully retrieve spots that check all the boxes

UI-wise, our team opted for a split view of the list of spots retrieved (right) and a map of those spots (left). This way, parkers can easily scan for spots by price or by proximity.

After many sketches and rapid low-fidelity prototypes, we began refining high-fidelity. The diagram below is a simplified user flow to show the web-app’s core capabilities.
Diagram of screens showcasing core screens in the productDiagram of screens showcasing core screens in the product
In small viewports on mobile browsers, search results appear in a half-list, half-map default. Users may swipe up ⬆️ to expand list + hide map, or swipe down ⬇️ for the reverse.
Diagram of screens showcasing core screens in the productDiagram of screens showcasing core screens in the productDiagram of screens showcasing core screens in the product
Design system 🟣
In adapting desktop interfaces to a mobile equivalent, I found that creating a design system (e.g. color scales, component library) is huge in maintaining cross-platform consistency and avoiding unnecessary design decision.

I built this system on best UI practices including the 8-point spacing grid, WCAG-compliant 10-step color scales, and tokenization.
A design system was not part of the initial design brief. But the founders loved what I made, and it has become the first guideline used to standardize company materials, including product screens across desktop and mobile, website, and pitch decks.
Key Takeaways
🧭  It's users who build the product

I interviewed parkers every week in the duration of this project, and these interviews inspired more ideas than I could ever come up myself. It's important to allow consumers to tell us designers what to build.

🧱  Align design with implementation

My design system initiative prepared my interfaces for a smooth hand-off to devs. Leaning into spacing conventions and setting up tokens for color variables bridged the gap between my design work and implementation. Taking one extra step can make other product teams' lives much easier.


🚠  Validate fast and early on

Having to deliver in just two short months forced me to quickly adapt to continuous stakeholder and user feedback. Validating hypothesis fast and early on helped me not have to make as many revisions later on.