Written description and illustration/diagram of the analyzed experience
More often than not, daily parking garages have a payment system where the driver will receive a ticket indicating the time they entered the garage and pay that ticket to a machine or attendant at the same place they entered the garage. However, I once parked in a garage where ticket was expected to be paid in the inner part of the garage before exiting, and the machine at the exit only verified that the ticket was paid for. By the time I had realized my error, there were at least 5 cars behind me waiting to exit the garage and no attendant to assist me.
Presentation of design process
- Entering parking garage
- Returning to car
- Paying ticket via machine
- Exiting parking garage
- Parking garage
- Inner building with payment machine
- Receiving timestamped ticket from automated machine or garage attendant
- Paying ticket via machine or attendant
- Driving around in parking garage
- Ticket dispensing machine
- Ticket payment machine
- Drivers using the parking garage
Laying out all of these factors made me realize just how much the conventional process that I was familiar with overlaps with this parking garage’s process. All of the interactions are essentially the same, but the order in which they occur (particularly, the timing of paying the ticket) are critical to creating a streamlined and intuitive experience.
The most trivial solution to this problem would be to replace the machines (dispensing/payment ticket machines, entrance/exit gates) with the ones of the conventional parking garage’s. However, considering the extraordinary costs it would take to either convert or entirely replace the garage’s existing technology, it would be more ideal to modify their processes and machines within a reasonable scope.
Brainstorming ideas about modest changes also had me thinking about how my idea of conventional parking garage payment systems could also be completely changed with a refactor of the entire process and the technologies involved.
For instance, I tried to think of a way to get rid of the paper ticketing system entirely, as it’s sometimes inconvenient to keep track of a small piece of paper. One of the ideas I came up with was an NFC-driven system where parking garage users would touch their phone to the machine upon entering the garage that uniquely identifies them based on the time they entered and the device used to initiate the transaction. Then, upon exiting, the user would touch the phone to the exit machine to determine how much is owed for the time parked in the garage. Additionally, users could set up some sort of account on their phone beforehand that will automatically debit the amount owed when exiting the parking garage.
While I think this idea is interesting, it also introduces a new array of inconveniences that vary depending on the user’s device’s capabilities since NFC in phones remains underutilized for the most part.
Description and concept sketches of proposed intervention
My redesign of the parking garage’s payment system doesn’t really involve refactoring the features of the technologies as much as it does redesigning the indicators to make sure that the user is aware that they have to pay before attempting to exit the garage.
First, the ticket-dispensing machine’s display should capture the user’s attention by instructing how to receive a ticket. Once the user has pressed the button to print a ticket, the display would then have a message reminding the user to pay the ticket at the machine inside the garage (describing where it is) before exiting. To ensure that the user doesn’t just take the ticket and drive off, the display would prompt the message with a flashing light on the machine for a few seconds before it prints ticket.
Once the user moves onward to find a parking spot, no matter where they park, the payment machine or the area containing the machine should be visible. One issue I vividly remember is not even seeing the machine when I was exiting the parking garage and entering the building it was attached to. Apparently it was on the first floor of the elevator-access room, but I took the stairs so I didn’t see it. Having multiple machines throughout the garage also couldn’t hurt.
The ticket itself could also contain instructions about how and where to pay in bold, distinguishing print at the top since most users will probably be getting their tickets ready before leaving the garage. This also serves as a backup first-time instruction in case the user ignored the display when first entering the garage.
Written reflection on the challenges of designing for yourself
Designing for yourself is inherently difficult because you view the problem with a particular bias that others may not share as strongly if at all. I was constantly questioning the importance of the problem. In my case, I’m not sure if the failure to pay my ticket beforehand expecting to be able to pay at the exit like most other garages was an error in my observation or just a legitimate flaw with the “unconventional” (which is also subjective based on your exposure to parking garages) system that the parking garage was utilizing. Also, all of the factors at the time may have made the problem seem worse than it actually was: no attendant at the exit to assist me and an angry line of drivers behind me wondering why this kid is getting out of his car and blocking the exit.
Designing the solution was equally, if not more, difficult because the act of entering and exiting the garage is such a passive activity. Creating indicators to grab a user’s attention for a moment may just annoy them or, in the worst case, go unnoticed. It’s easy for me to say how I think the instructions for the parking garage could be distributed more apparently, but that doesn’t always apply to every user. Collaborating with others when designing universal solutions is useful because each member can contribute something unique while keeping the others’ ideas grounded.