Park then Pay

I have omitted confidential information in this case study. All information is my own and does not necessarily reflect the views of Arrive.

 Background

Parking reservations provide restrictions to users including pre-payment, commitment to specific dates and times, and limited flexibility when plans change. Different technical solutions are needed for different parking facility types. Some facilities have gates, some facilities do not, and there are many variants of payment technologies at each facility.

I led the Park then Pay initiative and designed solutions for users to be able to pay for parking without reserving in advance in ParkWhiz native apps. This included functionality for users to scan tickets and process payments without through their phone instead of a kiosk, open surface lot transactions, and digital payments with bluetooth gate access control (imagine opening and closing a parking garage gate by tapping your phone). Our Park then Pay technologies have become even more relevant in the parking space with Covid-19, where touchless payment technologies are now needed more than ever.

The following case study is specifically for the open surface lot solution, which has been the most widely adopted Park then Pay method of the three to date. The open surface lot solution was created for facilities that do not have gate control access. I designed a solution for users to pay for parking in the ParkWhiz app after pulling into a parking lot, instead of paying through a kiosk on a parking lot site. 

Discovery

Our user researcher had run a previous diary study to learn how people park without an app. In this study, we learned that different open surface lot facilities may function differently. Some facilities require users to enter their license plate into a machine and will cross reference plates in their system against license plates parked on the lot to validate (no paper required). Other facilities require users to place a printed receipt on their dashboard.

When users reflected on both scenarios in the diary study, users were concerned about making a mistake and felt confusion around paying the correct amount. Additionally, we found that users felt they had limited flexibility when paying at a kiosk before walking away from their car. Users were frequently over paying just in case they needed extra time. 

We also spoke with parking operators about their perspectives, to ensure that we were creating a solution that would be widely adopted by facilities.

Finally, we considered pain points that we had heard from users about our reservation product, that we could solve with our Park then Pay product. The main pain point users communicated was paying for a reservation in advance limited their flexibility, a problem that also exists for open surface lots when users drive up and pay at kiosks.

Primary goals founded in research:

• Establish transparency around parking rules and rates

• Increase flexibility for users who may have plans change

Concepts

I first began by concepting possible solutions to get more explicit feedback from stakeholders. Presenting others with visuals to get direct feedback is a regular part of my practice. Even if it’s early!

After rounds of iteration, I narrowed in on the 2 primary concepts seen below:

A. Start/Stop

The start stop method would require users to start and stop a timer- determining their times as they go.

B. Auto-End: Select a rate in advance

Off street parking rates are tiered in nature, i.e. 0-2 hrs costs $12, 2-6 hrs costs $16, 6-12 hrs costs $18, etc. This option allows users to select a rate in advance while allowing users to adjust by ending the session early or extending as plans change.

Validation

I created prototypes to be usability tested for the start/stop and automatic end versions (2 total). Here’s a snippet of one of the start/stop prototype.

Learnings from Usability Testing:

• Extend is an extremely important feature for the auto-end experience. Users who tested this version were delighted by the added flexibility.

• Users who tested the start and stop method have concern about forgetting to end a session when they return to their vehicle.

• Participants asked many questions about getting a receipt. Confirmation of payment is critical.

• The sign in and up process is long for new users, applying to both prototypes. We created another project to iterate on sign in/sign up.

Final solution

After sharing results out with the broader team, including Customer Service, the concern of users forgetting to end their session was held by many. We did not want to risk the chances of increasing tows, which is a frustrating experience for the user and expensive to the business. For this reason, we decided to go with the automatic end version.

How we solved for discovered pain points:

• Establish transparency around parking rules and rates

  • We display up to three rates for users to have immediate access to rates available now. An additional page exists for users to estimate a rate for any end time in the future.

• Increase flexibility for users who may have plans that change

  • Two buttons below the countdown timer allow users to end a session early or extend a session. This gives users control to update their rate as they go.

We usability tested the final solution again, to work out all kinks with affordances, copy, etc and worked with Visual Design to finalize the product. I led visual QA through the launch of both iOS and Android platforms.

The open surface lot solution brings is currently being adapted by parking facilities across North America and I look forward to seeing the product grow!