Park It!

The Problem

It is no secret that Philadelphia's parking has been a considerable pain for regular commuters. Unfortunately, due to the city's old infrastructure and the huge population density, commuters' only option is street parking unless their workplace has a dedicated parking space, or they will have to pay high prices for parking lots. But street parking comes with its share of problems.

Pain points we discovered:

• In an urban environment such as Center City Philadelphia, the supply of street parking spaces does not meet the demand.

• Bad urban planning. As Philadelphia strives to be pedestrian-friendly in accommodations and design, inefficient and frenzied parking practices can negatively impact a busy environment.

In summary, the problem is the lack of an efficient processing system to help a driver find a street parking space.

Key Insights

We managed to recruit a total of 10 people for the user interviews and observations, and through our research, we found out:

• 6 out of 10 interviewees drive every day.

• They are likely to be looking for parking spaces anywhere between 1 and 6 times per day whenever they are looking for street parking.

• The willingness to search for parking ranged from five minutes to as long as it takes.

• The interviewees were willing to pay for parking with the price range varies.

• Common pain points include aggravation of circling for parking, bad parking practices, and parking too far from one's destination.

Identify the Success Criteria

After we gather our interview and observation data, we identified the following success criteria for our design concept:

• Locating a parking space should be easy and done in a timely manner

• The parking space available is at the price the driver is willing to pay

• Traffic congestion and idling of cars is reduced

• Improved safety for both drivers and pedestrians

• The number of parking spaces on a given street is utilized to maximum potential, where one vehicle occupies one space

Explore Potential Solutions

Once our success criteria were defined, the team engaged in an ideation session to quickly produce some ideas. In the end, we came up with a total of 25 potential designs. After reviewing all 25 ideas, we realized that our ideas could be classified into the following categories:

• LED/street sensors

• smartphone app

• vehicle manufacturer navigation system

• non-technical solutions

We then further classified these ideas under three categories to narrow down our solutions:

• practical

• rational

• unexpected

The team deemed practical as easy to implement, rational as requiring a smartphone app, and unexpected as avant-grade, at least from a parking perspective.

User Flow

Once we decided to create a mobile app, we began drafting the user flow to help users achieve their main goal: finding the ideal street parking space.

To help the users achieve this goal, the team identified some information that users will need to know:

• User needs a place to enter their final destination

• User needs to know how to navigate from their current location to the parking space

• User needs to know the availability of the parking spaces

Lo-fi Wireframe

With the user flow figured out, the team began designing the lo-fi wireframes to start to get a general idea of how the app would look like. Apart from aiming to satisfy the success criteria, we also designed with safety in mind as we think it is just as if not more important than helping our users find a parking space. I was responsible for the maps navigation feature of the app while my teammates worked on other features such as the initial startup screens and the parking spot searching function.

The following are some screens we worked on using Mockplus.

User Testing

As we completed our lo-fi wireframes, we decided to do some user testing to gain some initial feedback. We consulted the original 10 interviewees plus some additional recruits to test our designs.

Here's what we've learned:

• The UI is intuitive and easy to understand

• Most of the users can walk through the whole user flow without any issues

• The user is having trouble identifying which parking he/she selected

• There was confusion as to if the handicap markers indicated a separate parking space from the standard pins or if it was part of a standard pin but provided the option for handicap parking

• The user doesn't have a way to find out the price of the parking space

Hi-fi Wireframe

After we gathered the feedback from our user testings, we proceed to make a few improvements and produced a hi-fi wireframe of the app.

During this process, we made a few design adjustments based on feedback from user testings:

• Delete the legend
  One of the feedback we received is that the legend was taking too much space and was blocking a huge part of the map, this could cause usability issues and might even cause potential danger since the driver doesn't know what's blocked behind the legend window. So we deleted the legend and let the icons do the talking.
  

• Getting rid of the volume slider at the bottom
  The volume slider shouldn't always be there as our testers think it is not an important feature that the user needs to interact with all the time; the reason for this is because we want to give as much space to the navigation map as possible.
  

• Combining the audio navigation feature (the megaphone icon and navigation text) with the address bar at the bottom
  We realized that the audio navigation text can be combined with the address bar at the bottom to provide a much cleaner look. This will give more space to the navigation map and prevent distractions to the driver.

Reflections

Throughout this case study, I learned the importance of receiving user feedback, no matter if it is positive or negative. Only by listening to your users' voices can you clearly define the path to improve the product.

Moving forward, I will take the experiences I gained here to further refine my user research skills to gain useful data in a more efficient manner.