Creating the Airbnb of parking spots
role
impact
timeline
UX Designer on team of 2 designers, 3 devs, 1 PM
Awarded Best Design at annual demo day
October - June 2020
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”.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
With this new iteration, listers now have the ability to control when their spot would be live to the marketplace.
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.
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.
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.
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.
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.
Thanks for stopping by!
michellekou@gmail.com
