Designing an app to help drivers find free street parking spots.
Finding parking spots in dense metropolitan cities can often be difficult and time consuming. I noticed this while living in Shanghai, LA, and SF, so I took on this personal project by myself to design an app to help people find available street parking. The project operates under the assumption that there is accurate parking detection technology available that can be implemented into the app's database.
Busy individuals who live in large metropolitan cities have a difficult time finding vacant parking spots due to the high density of cars. While there are tools that allow people to reserve private spots by paying online, paying for parking each time isn't a very sustainable option for those who drive around the city regularly. There are plenty of options for free public parking in cities, but people often don't know where to find them. I wanted to design an app that would bridge this gap by providing users with real-time information about free public parking spots around them.
Here are the main takeaways from the interviews:
1. They only pay when they feel like they have no other choice or if in a rush. Most would rather walk a significant distance instead of paying a couple of dollars to park closer. Past parking experience also plays a big factor in these decisions (i.e. allotting extra time for walking when parking several blocks away in a more residential area).
2. Curbside parking can make people nervous that they are accidentally violating the law, especially when there are multiple street signs that all say different things. They don't want to worry about receiving a ticket, getting towed, or having their car broken into.
3. The majority of the people use Google Maps, Waze, or some sort of navigation app when driving. They trust that the real-time information provided is accurate and optimal.
I created a persona to represent the target user for the app.
Marcus wants to find the cheapest parking option near him, but doesn't mind the time tradeoff. He wants to save money out of frugality, not out of necessity.
Based on the persona, I decided the app would need to accomplish these goals:
1. This is the reason why people would use the app in the first place. Paying for parking every time isn't sustainable, so users want an alternative that helps them save money.
2. The spots provided should meet the user's criteria. In addition to vacancy and pricing, users also need to know how long they can park for and how far the spot is from the original destination.
3. Users will refer to the information from the app to help navigate, but shouldn't have to be distracted from the road.
The next step was to figure out what features the app would need to accomplish the goals.
Search: Search for parking spots based on location. This enables users to plan ahead by scoping out potential spots around their target destination.
Quick Park: Scan the surrounding area for available parking spots. This would probably be the most frequent use case of the app, where users can immediately search for parking around their current location.
Preferences: Filter spot selection based on parameters. Adjusting preferences helps the app identify spots that match the user's priorities.
I created paper prototypes and tested them with 5 users to see how they navigated through the app.
Users initially thought it was a trip planner such as AirBnB, but figured maybe it had a parking function only due to the “Quick Park” button. Since there were only 3 buttons on the home screen, there was no other contextual clue to how the app functioned.
When in the preferences screen, users expected to be able tweak multiple preferences and view them simultaneously, rather than having to scroll down to see each one.
The insights I gathered from the paper prototype tests guided changes I implemented to my wireframes.
Next, I conducted 10 usability tests over 2 iterations with an interactive prototype using the high fidelity screens. Below are the changes I made to the second iteration.
Users thought red pins meant parking there was unavailable, even though it was meant to indicate medium chance of availability. For the second iteration, I changed the color to orange because it carries more of a medium universal connotation, whereas red and green are typically viewed as opposites.
The function of the Locate button was unclear to users. Some thought it was to help locate parking spots, while others thought it would highlight the location of their parked car, and some thought it would re-center the map based on the user's location. The purpose of the button was the latter, in order to provide a quick way of re-centering the navigation on the user's current location, which is helpful for avoiding distraction while driving. I renamed the button to Re-center, as it matches the Google Maps mental model.
I discovered that the order of user priority when considering a spot is availability > price > duration > distance from destination, so I reorganized the information in spot details to reflect that order. I also grouped the ETA with the parking pin to draw more attention to it, as users usually missed it when it was underneath the Go button.
All users were able to successfully perform the tasks assigned to them as part of the usability tests. The app also met the 3 goals established in the beginning:
While I thought I had successfully solved all the major issues I had come across in the first round of usability testing, I also uncovered more issues in the second round. Once I started asking users what they thought parking pins represented and what parking availability meant, I realized that I had been operating on different assumptions the whole time. Though each parking pin is supposed to represent a single parking spot, most people thought each pin represented a cluster of spots. As a result, they assumed availability meant the percentage of spots in that cluster that were vacant, even though it actually referred to the chance that the parking spot represented by the pin is open.
By going through this design process for the first time, I was able to learn how each step complements the rest to build an effective framework for design.
I learned the most from the user interview and usability testing stages. A lot of the information and feedback you receive depends on the way you ask or frame the questions. With each interview and usability test, I became better at improvising and asking probing questions that would yield more insightful answers. Since gathering information about users and their needs is a crucial part of the process (good intel informs better design), a large part of the design actually depends on effective interviewing techniques.
From the testing stage, I learned to always question your users’ assumptions. Never assume that the user knows what the designer means without asking questions about it first.