Wahoo Zones

In this semester-long final project for HCI in Software Development, my team designed a mobile app prototype to tackle the problem of parking around UVA’s campus.

As the design lead, I worked to conduct user interviews, draw insights from research data, design the information architecture and wireframes, and establish a design system.

Our client for this project was UVA’s Parking and Transportation office, but the app’s target users were UVA students.

Parking around UVA is particularly difficult.

Whether it be due to constant construction, a shortage of parking spots, between-class traffic, or special events, initial research revealed that 90% of surveyed students found parking around Grounds to be more challenging than elsewhere.

To streamline the parking experience, providing users with a straightforward, digital way to determine where spots are available.

Our ultimate goals were to reduce annoyance, time spent searching for a spot, and parking fines.

We conducted an exhaustive survey of parking options available in Charlottesville. Surprisingly, we discovered lots of free or cheap parking around academic buildings that none of us or our interviewees knew about.

Why then, is it difficult for students to access this information? Why is it so hard to find parking? 

These images serve as a snapshot of the parking environment at UVA, revealing physical challenges important to understanding the problems users have with the current system.

Common barriers include poor sign visibility, inconsistent signage, constant construction, ambiguous permit labels, over-reservation of parking spots, and a lack of centralized information. 

In other words, environmental factors of a busy, dynamic college town create confusion and frustration for users, making it difficult to understand where they are allowed to park.

We took a look at ParkMobile, the predominant parking app at UVA, which had been used at least once by 100% of our initially surveyed users.

We found that ParkMobile focused on facilitating payment for parking spaces, which differs from our objective of helping drivers find parking. However, we still found value in exploring its map interface.

This audit allowed us to examine various interfaces within transportation apps, which helped guide our ideation process.

We first brainstormed all possible candidate personas – our potential types of users. We then grouped these candidates into selected personas based on shared goals of using our app, all of whom would need to be considered in our app's final design:

From this list we selected our primary persona.

We identified UVA students as our primary stakeholders, focusing on those who commute by personal vehicle and need short-term parking. Students who use alternative transportation or have long-term parking solutions are less likely to benefit from the app.

We conducted interviews across the range of our user classes, creating a set of base interview questions.
The goal of these interviews was to understand the context in which users make parking decisions, including obstacles and emotions through the process of finding parking.
‍
We found that interviewees were (1) most interested in finding free parking, (2) very unsure of where they were allowed to park on grounds, (3) found the parking process on grounds too difficult or time consuming, and (4) often parked illegally or far away for lack of better options.

Based on this initial understanding of the problem and users, we spent a week creating an initial iteration of our idea and bringing it to users to test the validity of our solution.

First, we produced a list of key requirements for the app, which I translated into features and organized into screens.

After paper sketches and picking between iterations in Figma, this was the final mid-fidelity design for this phase:

We conducted small group interviews testing this initial prototype with 20 potential users. Each person in a small group was given a specific task to complete.

This feedback showed us that potential users were interested in our app, and that live capacity information and crowdsourced reports were most beneficial to potential users. We decided that in an ideal implementation, available parking spots are identified by satellite technology and updated in real time. It also highlighted the importance of the parking lot details screen in enabling users to quickly assess lot viability.

We worked to turn specific opinions, hurdles, or suggestions from our initial interview notes and rapid spin feedback into sticky notes, and organized these notes into a physical affinity diagram.

We then translated this affinity diagram into a list of requirements that our app had to meet in addressing the needs of our users, and turned these requirements into interactions that our app would support.

Referring back to these lists throughout iterations ensured that our system remained rooted in user research and supported all of the interaction goals of users.

Some unexpected findings were that (1) users wanted the contact information of authorities of the parking lot, (2) users were extremely interested in towing/ticketing information for lots, (3) some wanted the ability to pay or be directed to the appropriate payment platform, and (4) users needed to be able to give feedback about the accuracy of the information presented.

My group sat down with our individual sketches as well as our user tasks derived from system requirements, and compared each version of each feature, discussing the usability, aesthetic, and functionality of each rendition.
‍
Sometimes this would result in scrapping an unnecessary feature entirely or drafting a new version that combined previous iterations.

At this point my team chose to focus on designing the default guest login version of the app, removing the settings and profile pages. This is because none of our participants were interested in creating an account, and the settings page offered little value for this MVP.

We ended up with the intermediate design below.

Based on this sketch, we developed a high-fidelity prototype to evaluate our design's effectiveness in making parking lots discoverable.

Below is the list of UX targets I created based on our initial goals of reducing annoyance and time spent searching for a spot for users.

Now with our prototype and UX targets, we conducted a usability test with 9 participants to determine the effectiveness of our solution and potential points for improvement.

We asked them to complete the benchmark tasks as written in the UX target table. At the end, participants were asked to complete this survey.

Overall, the lowest average was on the question of how likely users would be to use the fully developed app. While the average rating for this question was still positive, it could suggest that users aren’t very excited about the potential for this app to solve the problem of parking. Going forward, this lack of excitement or certainty is an insight that the team should work on improving.

The second lowest averages were tied across 3 questions. A lower rating on these questions could indicate that the user flows for in-app navigation and parking lot search could be improved, as well as the quantity and clarity of the lot details page content should be improved.

Our primary goal was to reduce user frustration surrounding and time spent searching for parking. The success of our app in solving this problem heavily depends on presenting reliable data, which is currently represented by static placeholders in the prototype.

Thus, the next steps for this project would be integrating live parking data into the app, as well as figuring out the backlogged user profile and settings functionalities.

This was one of my first UX projects. Through this project, I learned how to lead a team, how to root my design in data, and the importance of updating and referring back to research artifacts across a long project timeline.

Here is the final round of feedback I received from members of my project team.

Overall, I’m very grateful to my team and professors for this learning experience!