Shopify Parking Meter
Design Challenge
👩🏻💻 Role: UI/UX Designer & Researcher
✏️ Tools: Figma
🗓 Duration: 2 weeks
Project Overview
This project was a design challenge presented by Shopify. Participants were prompted to create a design solution for a parking meter, such that both drivers are able to pay for their parking duration, and parking attendants are able to perform their job duties. For this project, I decided to create a tablet application, utilized by a touchscreen interface, where both of these goals are met on one system. Full description on the challenge prompt and requirements.
Project Timeline
Background & Research
Assumptions Made
Since there weren't any other specifications mentioned by the given guidelines, I assumed the following information for my design:
-
There is no other budget allocated towards anything other than the solution devised for the parking meter.
-
The parking meter is unable to accept cash payments; it's only able to accept card transactions.
-
The parking meter accepts card payments through VISA, MasterCard, American Express, etc. (NOT PayPal, Apple Pay, Venmo since that requires internet).
-
The parking meter doesn't have any additional accessories, thus there is no card reader nor receipt printer.
-
Touchscreen dimension is equivalent to a common tablet size, 768x1024
-
According to Design Rush, the “most common tablet screen resolution worldwide” between March 2019 and March 2020 was 768px by 1024px at 51.43% majority.
-
Will confine this project to a tablet application size, since tablets have commonly been used in businesses.
-
-
Touchscreen can display color.
-
The parking meter is within a short walking distance to the 6 parking spots that the machine corresponds to, approximately (0-5 minutes).
-
The parking meter is evidently visible to users from their point of parking, meaning that users will know that their parking spot requires payment at the parking meter.
Audience
For this system, there are two main stakeholders who will directly be using this system: drivers and parking attendants. Drivers will be using the parking meter system to pay for the time that their car is parked in the lot. Parking attendants will be using the system to monitor which cars are abiding or violating their stay duration and the ability to issue violator tickets. With this in mind, we must take into account how these parties will use and interact with the system in order to provide the best service solution.
Identified User Goals
The system should meet the goals that the different stakeholders, whose characteristics are described through the personas in Figures 1-3:
-
To decrease users’ time spent trying to enter information in order to make a payment for their parked vehicle.
-
To decrease city upkeep of the systems implementation.
-
To increase parking attendants’ capability to quickly decipher parking violaters.
-
To increase the system’s quality of experience so that users are able to pay for parking usage and parking attendants are able to perform their jobs.
Figures 1-3: Personas of potential users interacting with the system.
Persona of potential user of system.
Persona of potential user of system.
Persona of potential user of system.
Persona of potential user of system.
Implementation Considerations
Design: Considering How to Charge
A major issue to consider regarding the design of the project is how will users identify which parking space to pay for when they step out of their car? With this in mind, I thought of two possible solutions:
-
Label the parking spaces using paint so that users pay by the parking space they occupied
-
Have users enter their license plate number into the system so that users pay by license plate information entered
1: Charging by space occupied
PROS
-
Painting the spaces with identifiers makes it clearer for parking attendant to locate which specific space is physically occupied and compare it to system’s payment record.
-
Example: User goes to meter and enters that they will be parked in the space “A2” for 2 hours. The parking attendant can then check on the system and compare the occupation records to the specific physical location.
CONS
-
User may park over the spot without noting the space identifier, which could cause users to have to back out of the space to see the spot number again in order to pay.
-
Specific car/user identifier is ambiguous since only occupation and payment of the space is noted.
-
Higher upkeep of painting physical parking spaces to demarcate clearly which space is which.
-
User would have to pay at specific parking meter that corresponds to the group of parking spaces.
VERSUS
2: Charging by driver license plate
PROS
-
Parking attendants can simply enter license plate numbers of vehicles in occupied spaces into the system and see if the user had made a payment, therefore a specific parking meter wouldn’t need to be used in order to pay.
-
Lower upkeep of physical parking spaces since space identifiers wouldn’t need to be regularly repainted due to weathering.
-
Increased user responsibility and accountability in accordance to parking lot guidelines and rules, since they will have to note their license plate number.
CONS
-
User may not know their license plate number, which will cause users to have to go back to their car and note their license plate number.
-
Using the user’s license plate as identifiers makes identifying the specific placement of the vehicle in a certain space more ambiguous.
First Iteration
At first, I had decided to charge by driver license plate numbers. This was because this method allows:
-
Users to more quickly pay for their parking since they only need their license plate information, rather than having them figure out or learn which spot they parked in and should pay for (Nielsen’s error prevention heuristic)
-
Users have the flexibility to pay at any parking meter rather than a specific one for the 6 car slots per meter (Nielsen's flexibility and efficiency of use heuristic)
-
Parking attendants don’t have to actively memorize parking spaces and layouts; the process for checking for invalid cars is simplified through less recall and more recognition (Nielsen’s recognition rather than recall heuristic)
I had decided to design the system around paying by driver license plate number, since this would rely less on user capability to pay for the correct space. I thought that this would be a better solution because there are more risks involved when relying on user ability to select the correct space, which could result in a driver paying for an incorrect spot which would not only deter other potential customers from parking in this lot since the physically available spot is not correctly listed in accordance to the parking meter availabilities, as well as a driver's frustration with figuring out which spot to pay for, which could discourage a driver from using the lot service.
Although this approach was sufficient for user-end needs, I had failed to account that parking attendants only utilize the parking meter and its system to deduce who has paid and who hasn’t; there are no external devices that the attendant can use besides the parking meter itself. I hadn't considered that the sole use of driver license plate numbers as the indicator for duration and payment would be difficult for parking attendants to efficiently perform their job duties.
Second Iteration
Rather than charging drivers by license plate, my final solution considered ways in which users can accurately be charged by space. In the previous consideration, I was concerned that users might not be able to recognize which space to pay for unless the parking spaces were regularly painted with identifiers. With this, the city’s upkeep of the system would increase in order to allow the system’s solution to charging users to function.
Instead, it is possible to more accurately charge users by the space they occupy and lower the costs included in order to do this by providing a visual representation of where their car space might be in relation to the parking meter they are standing at. For example, we should provide visual relation points so that drivers and parking attendants can compare their parking space surroundings to, as seen in Figure 4.
Figure 4: Example of a location relational point
With charging by space, there are various points to
consider on what might go wrong with this approach:
-
Without the ability to paint specific parking spaces, it will be harder for drivers to decipher which spot they must pay for and similarly harder for parking attendants to see which car is in which space.
-
Drivers may mistakenly pay for the wrong space.
-
Drivers have to pay at the specific parking meter that corresponds to the group of parking spaces in order to visually see where they had parked and parking attendants will also have to perform their duties at that corresponding parking meter for that set of spaces.
Key Performance Indicators
Validation of the pay by parking space solution chosen will depend on the following key performance indicators:
-
Violation tickets issued by parking attendants decreases, which means that users are abiding by the parking meter’s payment and time duration limits
-
Users spend less time at the parking meter trying to pay as opposed to the previous system in place, which means that users find the touchscreen solution easier for making payments
-
Parking attendants spend less time trying to decipher which cars are abiders or violators
Information Architecture
In order to better understand how a driver might traverse the application to pay for their parking and to figure out how many pages are needed to complete this goal, I drafted an interaction diagram, as seen in Figure 5, that highlights the various pathways a driver can take depending on what information was input and what actions were taken previously. By creating an interaction diagram to represent user flow prior to creating the wireframes, I had more thorough understanding of action sequence. In turn, I was able to combine and condense some pages together to simplify the number of steps a driver takes to successfully pay for parking.
Similarly, I created an interaction diagram for the parking attendant's interface, as seen in Figure 6. This highlights the differences between driver and parking attendant flow, since each have different functions unique to their user type. Full descriptions on parking attendant user flow and driver user flow.
(Left) Figure 5: Interaction diagram of user flow and action sequence for Driver users.
(Right) Figure 6: Interaction diagram of user flow and action sequence for Parking Attendant users.
Low Fidelity Wireframing
With an outline for what pages would be needed from the interaction diagrams, I was able to envision how they would translate onto pages through buttons, content, etc.
Since one of the project goals was to simplify the payment process, I focused on trying acquire driver information through a sequence of isolated action items. For example, rather than presenting all the input fields on a single page to include all information fields needed for payment, I split these sections into different pages to be completed in a step-by-step process, since it is tricky for drivers to keep in mind all this information at once. This way, drivers aren't overwhelmed by the amount of information they need to input.
The following are low fidelity wireframes of a driver's view of the parking meter system:
High Fidelity Wireframing
Parking Attendant: Design Decisions
Since there are two different user types, drivers and parking attendants, who will be utilizing the same system, I decided to make the entry point into the parking attendant interface and user flow rather small and hidden. Parking attendants are able to access their "side" of the system through a visibly hyperlinked "click here" at the top of the page. Since parking attendants will be more familiar with the system through time and use, they would not need such an obvious entry or starting point to use the system as a driver might need. The entry point verification for parking attendants would be a text field where they enter their ID number for credentials, which I assumed would set patrons and parking attendants apart.
Driver: Design Decisions
I prioritized the driver user flow design over the parking attendant user flow for the aforementioned reasons. This provides a convenience to drivers since it is clear to any kind of driver type, such as a first-time visitor or a regular visitor, what they should do to continue along in the process. In addition, I included a version of a progress bar throughout the driver user flow because I wanted to show where users are situated in the payment process and an easy way for them to quickly jump through pages without having to remember what steps they did and in what order.
Overall Design
A motif present on other pages is also the top bar that includes a "back" and "cancel" links, as well as a "next" button at the bottom of the page that can be clicked when the necessary information is collected for that page. I chose to include this onto nearly all pages so that users, both drivers and parking attendants, can easily access pages without having to remember what page in specific was completed before and after and to give them the option to quickly completely abandon a process.
In terms of visual design, I chose green and shades of grey to be color motifs throughout the pages because I was inspired by Shopify's color branding. In addition, I included a yellow and red that complemented the Shopify green color, in order to provide easy indicators to parking attendants when a driver's parking space is good on time, nearing the end of its stay, and when it has ended.
The following are high fidelity wireframes that include pages from both a driver and parking attendant view of the parking meter system:
Takeaways
This problem was challenging because the requirements were very loose and up to my own speculation, so I had to assume or research what common specifications might be. However, the lack of constraints gave me more design and process implementation freedom for how I would solve this problem. Over the course of this project, I have learned that although simplifying processes allows us to spend less time on menial things, it also doesn’t necessarily mean that it is a better solution option. Instead, I found that making that extra step in the driver user flow process to figure out which space they had occupied made it easier to implement a process solution for the parking attendant user flow since they wouldn't have to always check length license plate numbers for parking verification. For this project, I didn't have access to any of the end users who might use this system, which is why I believe my research process lacked in enough insight for what a user really needs. If I had the chance to, I would have liked to research within the field site with which this parking meter would have been situated in and also conduct prototype evaluation on my high-fidelity wireframes to see if users could identify correct parking spaces.