PARKING BUDDY
A tool that will enhance the parking experience for drivers seeking their next parking spot
OVERVIEW
Problem Statement
In a COVID-scarred society, there are individuals who are immunocompromised or otherwise phobic of large crowds or high-capacity locales. As thus, when planning an excursion from a household, it is important to know the capacity and parking availability of the target destination to avoid either a situation where one arrives and there is no available parking, or one arrives and the destination is already serving too many people for the individual to be comfortable.
Location
Users
10 weeks
4 members
Online, UW
Drivers
Duration
Team
Vision Statement
We hope that our platform will improve the parking experience for drivers. We are working on designing a product that helps to reduce the amount of time it takes to search for available parking spots and help users feel confident as they plan their next trip whether that may be to the grocery store, park, or event.
Context
The duration of this project spanned 10 weeks for the HCDE 318 course in Spring 2021. Due to the COVID-19 pandemic, all work was completed remotely. We built a mobile application called Parking Buddy to address multifaceted pain points drivers face when parking their car.
research phase
Research Findings
Our overarching research question to understand the space we were designing was:
What are the pain points of drivers in highly congested parking
areas in a time of COVID and how can we make this more
convenient?
Our design question was:
How can we improve the experience of parking lots in the
time of COVID-19?
From our semi-structured interviews that took place over Zoom calls, we found that participants:
-
View paid parking prices can be inconvenient and out of budget
-
Struggle with small parking spaces along with dense/busy areas.
-
Desire a convenient way to check parking availability at the desired location
-
Most participants are familiar with smartphone usage and utilize Google Maps/Google search’s popular times feature to view capacity information
User interviews allowed us to gain more insight into the user’s goals, pains, desires, and experience with technology. Using this information, we integrated the concepts to formulate ideas for features to include in our platform to best address their needs.
Polished Personas
From our user interviews, came together to share common findings and used a Lucid chart to do brief affinity mapping and grouping based on similar experiences shared by our interview participants. After laying out our findings, we grouped them into the categories pain points, desires, goals, and technology familiarity respectively. From here, we were able to draft provisional personas which we then iterated into polished personas using our interview data.
The personas served as visual artifacts to communicate the users’ wants and needs. They included the top priorities to have in mind as we designed our app. The artifacts deepened our understanding of how we can design alongside our intended audience as we ideated the user journey map and design features.
Meet Kevin and Naime!
User Journey Map
The user journey map depicts the experience of one of our personas, Kevin, throughout his trip to the grocery store. The pathway begins when Kevin is planning his trip through the process of leaving the parking vicinity of the grocery store. The main sentiments we portrayed were confidence, anxiety, and frustration. Using the details in our user journey map and helped us ideate the design requirements in the next phase of our projects to help alleviate negative feeling levels.
DESIGN PHASE
Design Requirements
The theme that we were tasked with was health and wellness. The prompt was left open-ended to each team’s interpretation. As the pandemic was still in effect and the new stages were slowly being reinforced with the release of COVID shots, we kept in mind the traveling safety and comfort of parking lots as they can sometimes be crowded in certain areas.
Some of the design requirements that we wanted to implement were:
-
A traveling directional plan in traveling to selected parking spot locations
-
A seamless experience with autopay and viewing remaining time
-
Being able to view and compare occupancy rates along with pricing
Storyboard Samples
Our user storyboards served to depict experiences that our two personas might have with the product that our group is designing. Illustrating this flow helps our stakeholders understand use case scenarios for our product. From these interactions, we were able to identify some key design solutions in our application. The visual stories conveyed in our drawings shaped the decisions we chose to define in our information architecture map.
Information Architecture
Taking each of the storyboards that the team created, we were able to identify several key pathways and functions we wanted the app to be able to perform. The information architecture segment was intended to be a visual representation of the various pathways included within the design. It is specifically important that it shows that our app centers around the homepage, and all pathways branch from the homepage root. This allowed us to organize our intentions and plans, in order to begin drafting our preliminary prototype.
Click to View on Figma
Prototyping phase
Low-Fidelity Prototype
With the Information Architecture Diagram that we created and agreed upon from the earlier step, we tried to design and implement a low-fidelity interactive prototype with Figma. The intention of this prototype is to test our essential ideas of the application in an early phase of development so that we can establish a basic guideline for the app design rationale and identify potential problems with our main focus and flows of navigation of our app and any possible improvement.
Three key pathways the lo-fi prototype features are：
-
Checking information (especially population density and parking availability) of targeted location
-
Automated parking charge system
-
Saving & sharing the location for future retrieving
These pathways are the main functionality and sell points of our app, which will be later tested in the user evaluation phase. During this process, we figured outback buttons are essential for a good user experience to quickly navigate to the main screen or previous page, and we should not have a random map for the prototype since the user might be confused from seeing unrelated locations and map view during testing.
Quick Evaluation
The low-fidelity prototype built is used in this process to do a quick usability test with four participants and ask them to complete the three task flows decided in the earlier phase. The intention of the evaluation is to see if our design meets our user group’s expectations and if there are any features we might miss or want to remove. The entire evaluation process will be formally recorded and documented for future discussion and finalizing our final project, the high-fidelity prototype.
Some major findings from user evaluation：
-
Some buttons and icons on our interface are unintuitive
-
Some mediate frames are missing throughout the navigation flow, causing a false mental model on the user
-
To display both the population density and parking price on the main map page for user to quickly retrieve wanted information would be helpful
This process and findings are particularly crucial to our project because they set up the norm that we will integrate into our final design and to really hear our users’ voices so that this app is not built upon assumptions. This helps us to make any change necessary before our final development stage.
Annotated Wireframes
To incorporate all the critiques, feedback, suggestions we received from the user evaluation to our app, we created wireframes to map out the entire system. It is the last process before the actual implementation and polish of our final product and serves as a framework and structure to how every screen would look in detail. The wireframes have annotations explaining the functionality of any buttons, icons, or tasks and list all the pages with internal hierarchy identified as our Information Architecture Diagram previously shows. They help us to have a clear visualization of how our app would look like and specifically what to build in our high fidelity prototype and make sure it fits with all the concepts we have developed so far.
High-Fidelity Mock-up
After receiving feedback on our low-fidelity wireframes, we implemented the design changes on the mock-up. Then after finalizing the low-fidelity frames and their respective changes, we moved forward by creating high-fidelity screens to represent the main user flows for our app. As we designed our high-fidelity mockup, we continued to receive feedback and iterate an additional two times. Ultimately, our high-fidelity mockups demonstrate what our application would look like as a fully developed platform for our users.
Group Reflection
This quarter we were presented with many challenges especially with the class being remote. Due to remote classes, this often presented challenges when finding a time to meet and also understanding our problem scope. During the research phase, because our user research centered around the people around us, this limited the design considerations to address when designing for different groups. In the future, during the user research phase, we would interview more than 4 people to truly understand our problem space and pain points users face. Additionally, with remote classes and as the deliverables advanced, not having the environment to brainstorm/whiteboard our thinking often led to miscommunication regarding design changes and implementations to make on our prototype.
If we had more time, we would have allocated more time toward user research and the design phase. The purpose of this would be to see where the gaps are within our problem space. We realized that as we were designing our storyboard samples and lo-fi prototype, the feasibility, desirability, and viability could have been considered more deeply as many similar products already exist.
The most surprising thing about this project was seeing how we were all able to think about integrations of our app features to existing map platforms like Google and Apple maps could be helpful for drivers in the future especially for drivers living around large cities. There was a lot of overlap between our application and existing applications so brainstorming the potential of how they could merge was an interesting experience especially when thinking about how these existing applications will continue to change as time passes.
As a team, collaboration remotely was no easy feat. We found it challenging to balance time zone differences, limited schedule availabilities, and difficulty evenly allocating the work to do for each deliverable. However, with a central communication platform and the time provided in-class, this helped us structure how we desired to complete each phase of the project.
Overall, our team enjoyed having the opportunity to experience the entire user-centered design process while utilizing the knowledge provided to us in class. It was a good way to also be exposed and practice using tools like Miroboard and Figma. The project had an intensive timeline but this allowed us to practice optimizing our time and deepen our project management skills.
MEET
OUR TEAM
2nd year HCDE student
3rd year HCDE student
2nd year HCDE student
2nd year HCDE student