the problem

Parking sucks.

Westwood, the home of UCLA, historic Hollywood theaters, and also terrible parking. With almost 50,000 students enrolled at UCLA, the surrounding neighborhood of Westwood has become insanely overpopulated. With my team at UCLA DevX, we sought to tackle this problem head on and create the “Airbnb of parking”.

pain point

Restrictions and lack of space prevent students from parking both long and short term.

The streets are filled with “No Parking” signs or strict hourly rules that prevent students from parking. Even if I wanted to stop by a friend’s apartment for just a few minutes, I often struggle to find a spot anywhere close to their place.

Westwood parking restrictions

Yet, many spots sit unused in garages.

For every person who does bring a car to campus, there’s someone who chooses not to: for example, out of state and international students. When these students have a spot included in their lease, it usually sits unused for the year, while they still pay rent towards the spot.

Example of Facebook postings for parking spotsExample of Facebook postings for parking spots
pain point

There’s no organized platform to exchange spots.

Being the resourceful people we are, many UCLA students have taken to groups and forums like Facebook or Reddit for their parking spot needs. However, these platforms are limited in their functionality for parking purposes. It’s really hard to search for spots close to you or find a suitable price and time frame.

How might we alleviate the parking pressure in the Westwood area?

Research & explore

What are we dealing with here?

sparke user interviews

To get a better grasp on who our users were and what their needs could be, I sent out a survey to fellow UCLA students.

Aside from the quantitative data, I also wanted to talk one on one with various users to get a better idea of what they are looking for in an app like Sparke. Alongside my PM Amy, we asked participants questions about their motivations for parking and the problems they currently face with parking.

Key Insights

Price, type of parking, and time frame

These were the top features that were most important to users.

Variable use cases

Some users just need a spot for an hour or two, while others want to park their car in a spot for the entire quarter

Variable use cases

Some users just need a spot for an hour or two, while others want to park their car in a spot for the entire quarter


Reserving a Spot

Design Exploration

Sparke lo-fidelity reservation designs

I drafted up some designs based on the research and came up with multiple versions of the same design. Most notable differences include: barrel scroller vs slider for time selection, calendar vs drop-down for date selection, and entry points into reservation details.


When should users select their time frame?

Moving time selection to the beginning

I moved forward with the calendar UI after A/B testing, but a problem soon came to the surface: how do we show unavailable time frames? After taking a step back, the team realized this was a larger issue at hand.

Why should time selection even be at the last step?

Bubble of person being frustrated with finding a parking spot with a time that's not good for them

However, our PM had a vision of the app opening up directly to the map and allowing for users to browse for spots immediately, without the barrier of time selection. In order to convince her to move time selection to the first step, I used the research gathered from the A/B testing to prove how necessary this change was, and we were able to overcome this issue through user research.


Sparke reservation mid-fidelity

Another Challenge

Access Feature
Sparke key access versions

Due to the complex nature of Sparke, the team and I were running into logistical issues. Just like AirBnb, buyers need a way to access their parking spots, especially ones locked behind a gate or garage.

To combat this issue, I created a new feature: Access Type.

Buyers would be able to quickly see what information would be needed to access a spot. Whether a spot needs a remote, key, or code, buyers could now take control over what spot works best for them.


Listing a Spot

Sparke listing designs, lo-fidelity

Whilst iterating on the booking flow, I also had to design the Lister’s POV. I opted for a step-by-step process as to not overwhelm any potential users.

Along the way, I tested the designs with various participants and received lots of helpful feedback. First, many brought up concerns about specific spot access. How would buyers know where to park, what spot number in the garage, how to access?

Second, I learned that many listers have busy schedules that could prevent them from meeting up with buyers. The strict time frames in the lo-fidelity listing flow restricts listers from working around things like their class schedule.

Sparke listing improvements

With this new iteration, listers now have the ability to control when their spot would be live to the marketplace.

Sparke title

A seamless reservation process

In my final designs, I was able to compromise with the PM and still allow for the map first experience. Users now click on the time frame button when they are ready to browse spots.

For the variable use cases, there are also two tracks a buyer can choose: hourly or monthly.

With “key” information (pun intended) at the top of the listing, users can easily glance over whether the spot is right for them.

Listing with ease

Sellers have full control over their listing to accommodate their flexible schedules.​

Information bubbles guide any newbies through unknown parking terms, which was a concern raised during user interviews.


Learnings & Improvements

Throughout this year-long project, I learned an insane amount about basic design thinking and skills. I’m really proud of myself, especially when just a few months before this project started, I didn’t even know what UX design was.

Design system

To be completely honest, at this point in my career, I didn’t even know what a design system was. I just knew that things needed to generally fit the same “vibe”. If I were to redo Sparke now, I would definitely incorporate a standardized design system.

More specifically, I would utilize Figma components and styles more—with consistent buttons, icons, and font sizes, I think the end product of Sparke would be much cleaner. This also would have improved the accessibility of the app by miles: some fonts I used were too small to be considered WCAG-compliant.

Additional features

Due to the engineering bandwidth mentioned earlier, I had to table features that users expressed desire for. Some examples include a mutual/friend system, in-app messages, and safety measures woven throughout the app.