parking banner.png
parking banner.png

A solution that allows drivers to quickly and easily pay for their street parking, so that they can carry on with their day, hassle-free. 

Project type

Design challenge, iPadOS

Timeframe

1 week (January 2022)

Tool

Figma

Role

Researching, ideating, designing, prototyping (individual project)

Parking meter interface design

 

In response to a design challenge, my solution creates a practical, accessible experience for urban drivers paying for street parking. 

Process: design thinking framework

 

January 12-13

January 14

January 15

January 16-18

.

 

 

 

Foundational research

User interviews

 

 

 

Problem statement

Project goal

 

 

 

Design constraints

Brainstorming

Sketching

 

 

 

Wireframing

Prototyping

Empathize

 

Conducting foundational research and user interviews to understand user pain points

IMG_9151.heic

Analyzing current

parking meters

  

The lefthand image is of a parking meter in my Toronto neighbourhood. This current system allows for physical payment to the meter or via the Green P app.

Overall, the design is cluttered, combining a non-backlit screen (that is susceptible to sun glare) with analog buttons.

User interviews

  

I conducted a few interviews with family and friends to gauge drivers’ current biggest challenges with parking meters.

Common responses described the frustrations of encountering an out of order machine, booking the exact desired amount of time, confusing parking restrictions, and potentially losing cash to a faulty machine.

Secondary research findings echoed the concerns raised by my interviewees.

Define

 

Developing a problem statement and product goals based on user research

Problem statement

  

My solution should allow drivers to quickly and easily pay for their street parking, so that they can carry on with their day, hassle-free.

Product goals

Ideate

 

Brainstorming and sketching solutions to visualize user flows and to review concepts

Design constraints

  

The design challenge included the following constraints:

  • The parking meter is for 6 parking spots

  • The machine has a single touchscreen, which does not support pinch and zoom, hard press, or advanced touchscreen functionalities

  • The parking meter can accept credit card payments, but is not otherwise connected to the internet and is not bluetooth enabled

On top of these constraints, I made the assumptions that the machine is able to print parking tickets and that the only accepted method of payment is credit card.

Brainstorming

  

In identifying drivers and parking attendants as the 2 key stakeholders in this project, I decided that the app’s homepage should immediately branch off into their respective flows: paying for parking and issuing tickets.

 

From there, I considered the necessary app interactions to account for all of the possible situations that could arise in both domains.

  • Parking in a vacant spot, paying for parking

  • Parking in a spot with time remaining, paying for extra time

  • Parking in a spot with time remaining, not paying for extra time

  • Car in expired spot, issuing a ticket

  • No car in expired spot, classifying as vacant

  • Car in "vacant" spot (driver did not pay), issuing a ticket

  • No car in vacant spot, confirming vacant

User flow diagram

  

This diagram maps out the user flow for a parking meter app (driver or attendant), which helps with understanding the key features required throughout the processes.

site map.png

Sketching

  

I created sketches of each user flow to solidify them logistically, prior to generating detailed mockups.

sketch.png

Parking attendant logging in and issuing ticket to driver whose parking has expired

Prototype

 

Creating a high-fidelity prototype that allows drivers to pay for their parking and attendants to issue tickets

At a glance

 

This is a tablet application that allows drivers to pay for their parking and attendants to issue tickets to cars who did not pay, or whose parking has expired.

1.png

Paying for parking: available spot

  

A driver selects their parking spot, adds time in 15 minute increments (which cost $0.75 each), and pays by entering their credit card information.

The “Payment successful” frame appears as soon as the payment goes through.

Since this system does not involve printing the ticket to display on one’s dashboard, the driver does not need to return to their car prior to running their errand.

2.png

Paying for parking: spot with remaining time

  

A driver selects their parking spot, adds time in 15 minute increments (which cost $0.75 each), and pays by entering their credit card information.

3.png

Attendant issuing a ticket: expired spot

  

The parking attendant signs in with their employee credentials, selects the spots that are either expired or “vacant,” and then issues tickets to drivers whose parking has expired or did not pay.

4.png

Attendant issuing a ticket: driver did not pay

  

If a car is parked in a spot marked “vacant,” it means the driver did not pay for their spot, and the attendant issues and prints a parking ticket as before.

Key takeaways

 

Given that this was my first UX design project and case study, I learned so much about applying fundamental concepts to an actual design process. I also taught myself how to use Figma, in order to create the high fidelity prototype.

 

In solving this problem, it was challenging to design an app interface that would take into account all possible user groups, which is an extensive population given the prolific nature of parking meters.

 

While I included some accessible features (i.e. help and language selection buttons), I would add options for larger font size and greyscale display in the next iteration. The current design also only accepts credit card payment, and I believe that the solution would be more inclusive with an added debit card payment option.

 

Given more time, I would definitely test the app with users to identify areas for improvement, and iterate features based on user feedback. To determine the success of my solution to the identified problem, I would test the app with both drivers and attendants, and qualitatively measure their behaviours and feelings about the experience. On the quantitative front, I would iterate the design in order to achieve users’ faster interactions with the app.

Screen Shot 2022-02-02 at 1.05.34 PM.png