"How do we make parking a better experience?"
In this UX course, we were tasked us to solve a problem area for students at UTM. With members of my previous group, we bounced around different ideas. I had spoken to a few of my friends beforehand to try to come up with problem ideas to research for this project. One of my initial ideas was to look into improving navigation throughout the campus with a focus on newer students who may have trouble finding their way to rooms or buildings. Eventually, we decided to tackle improving parking. This was going to be a tough task because our professor limited us to gathering data for research within our classroom in contrast to the previous HCI course which gave us full freedom to research and gather information outside of the classroom. This meant we could not actually go to our school parking lot to run tests or gather data.
Our project had four phases of research which we were to focus on throughout the course: Contextual Inquiry, Participatory Design, Focus Groups and A/B Testing.
UTM's current parking system
Before we dive into our design process, we need to understand how parking currently works at UTM (and by currently I mean at the time of this project, which was Winter 2019). Our focus is only on parking that is available for visitors and students and not reserved parking lots (e.g. residence parking).
Drivers enter the campus and can park at a number of parking lots. If the driver does not have a parking pass, they are required to pay for parking at any of the Pay & Display machines in the lot. At the Pay & Display machine, drivers select how long they plan to be parked in 30 minute increments, with a maximum amount of $15 to park until 8:00 am the next day. Once they pay for the pass and receive the ticket, the driver has to place the ticket on their dash to be visible by parking enforcement. Any violation of these rules could result in a ticket or a tow.
For our contextual inquiry session, we began our sessions with a short interview with the participants discussing their how they view parking at UTM and how they currently commute to UTM. We also asked what they do with their phones while driving so we could understand how we could integrate a digital interface into our solution. Afterwards, we had the participants perform a mock parking run in our classroom. As previously mentioned, we were not allowed to do our tests outside of the classroom and in a parking lot, so we setup the back portion of the classroom as a fake parking lot, where our participants would sit in office chairs and simulate their experience parking at UTM. After the mock demo, we discussed how the demo went with the participants and discuss some of the events that may have occurred or certain decisions they made during the demo.
We had five students from our class participate in our session. All our participants had negative feelings towards parking at UTM. We found that only two participants drove to UTM with only one of those participants being a frequent driver. The other three participants utilized other methods such as public transit or carpooling. All our participants always came to campus early before their class or other meeting in case of any unexpected events during commutes like accidents or delays. Some of our participants keep their phone out of sight (e.g. in their bag) while driving, and a couple would mount their phone to use for directions. One of our participants even stated they do not like using voice assistants to help them navigate because they find it distracting.
In our demo, we had one of our members act as a driver sitting in their car in the parking lot close to our "building", which is also where the pay and display machine is and an open spot at the far end of the lot. We told the participants they were on their way to a class which they were about to run late for. With our drivers in place, we able to see how our participants would (or would not) engage with the other driver when going to find an open parking spot. Most of our participants drove by the other driver without engaging with them, but two of our participants engaged with the other driver. One of those participants talked with the other driver politely and was able to take their parking spot, whereas the other participant honked at the driver to leave and was visibly agitated with the other driver.
After the demo, we asked participants about how the demo went and about the decisions they did (or did not) make. Participants who went immediately to the far spot said they would rather look for an empty spot rather than attempt to negotiate with someone in their car, even if the spot required more walking to the machine or their destination. Some of our participants stated that parking farther gave them peace of mind because they wouldn't have to worry about other drivers causing accidents as much compared to a more crowded spot in the parking lot.
Our Initial Design
Coming off our contextual inquiry session, we had an idea of how to improve the parking experience. Our proposed design was to make parking spots reserved through a ticket system which drivers would be able to access at the entrance of each parking lot, and to change how to pay for parking. We also had a companion app that would mitigate the pain of finding a spot by allowing the user to view what spots are available ahead of time.
Instead of walking to the kiosks in the parking lot, drivers would have to interact with a kiosk at the entrance of the parking lot to select a parking spot to park in, or scan their parking pass. If the drivers did not have a parking pass, The entrance kiosk would give them a ticket which would uniquely identify what time they entered the parking lot and which spot they chose. In order to pay for parking, drivers would pay for their allotted time as they leave. This would allow the drivers to not have to worry about selecting how long they have to park for and let them drive in, park and go to their destination quicker.
On their way out, drivers would see how long they've been parked for and how much they owe for the parking fee. We incorporated the same payment methods available on current parking machines: cash and credit card. There is no pad to enter a PIN for credit cards as we want the drivers to spend as little time as possible at the kiosk. This is also how the parking kiosk at UTM works. That being said, we decided to include a button to allow users to return the already inserted cash in case they change their mind about paying with cash or otherwise.
Our goal for the app was to display how spaces were open in each parking lot and to be used as a way to reserve parking spots, either by the driver well ahead of their drive or by a passenger if they carpool. Users could add a payment method or their parking pass to let them reserve ahead of time by paying through the app.
Of course, the app is not a required part of the design because visitors who are not students or staff are not expected to install this app for infrequently visiting. We had concerns over how involved the app should be with the design because using mobile devices while driving is not allowed in many areas, including the province of Ontario. So we made sure that the app was not the centrepiece of the design and could be used in a complimentary sense.
One feature we considered early in the design process was a voice assistant feature that would help navigate the user to a free parking spot. The idea came from how navigation apps such as Google Maps give directions to drivers using voice so that drivers can concentrate on looking at the road rather than at their phone. We eventually decided to consider this feature "out of scope" for this design iteration, but also because of how many of our participants don't use their phone for navigation.
With our initial design in place, we went into our participatory design session hoping to get ideas and feedback from participants. In our session, we got to work with five participants who we asked to give us their vision and ideas for improving parking at UTM and gave us critique on our design. Many of our participants opted to include an electronic sign by the parking lot to show how many spots are open in a parking lot. Many participants referred to Square One's electronic parking lot sign as their example.
Our participants overall idea for a companion app was similar to our idea of using it to pay for parking or reserve a spot ahead of time. One concern that came up with reserving a spot was finding a good balance of time between reserving and arriving at the parking spot before freeing it up. Commuters take a different amount of time to arrive to campus depending on traffic and the distance they have to travel. Reserving a parking spot for too long can also frustrate drivers who come and cannot take an empty spot because its been reserved for a long time. There was also the concern for abuse of the system, where people would hold spots hostage for malicious reasons.
When it came to getting feedback for our design, many participants expressed concern over lineups at each kiosk, especially during hours of heavy traffic. We knew this would probably be inevitable, and the best way to mitigate this would be to redesign the entrance and exit paths for drivers to properly account for lineups. There was also the concern for parking in the wrong spot and having that cause even more delays. We hope that drivers would adopt an "unspoken" honour system and park where they're supposed to, but in the case that this does not happen, fines would be given to drivers and parking enforcement would be vigilant of who is breaking the rules.
For our focus group, we had two groups of three participants each run through a mock parking scenario with our parking system design. The three participants of each group would run through the scenario at the same time, but would enter or leave the parking lot at different times. We also had each participant use a different method to ineract with the entrance kiosk and pay on exit to see how each of the methods would work. We would then hold a group discussion with all the testers to get their thoughts on how the parking system and their test.
We noticed that testers who were asked to use their phone to go through both the entrance and exit terminals had trouble using the phone. They had also made comments about how the app fails to give them information they may want such as how much they paid through the app, or how long they were parked for. Since this information is not shown on the terminal when using the app, we neglected to give the user this information in the initial design of the app. The testers who paid cash or used a credit card had less trouble going through the parking system, but one of the credit card testers stated they would like to see which types of credit cards are accepted at the exit kiosk for payment. This was also something we neglected in our first design and took into account for the final design.
For our A/B test, we focused on the utilization of the app for going through the parking kiosks, since was the biggest point of contention for our design based on our focus group sessions. For our A test, we had the drivers scan a parking pass screen in the app on entry and exit. For our B test, we had drivers scan a parking pass screen in the app on entry, but they would receive a ticket from the entrance kiosk after selecting a spot and would input that receipt into the exit kiosk when leaving rather than opening the app to scan on exit. We had our testers run through both A and B tests, alternating between doing A first and doing B first between users.
We had seven participants run through our A/B tests. Many of our testers were able to go through our tests with little difficulty, except for a few where we felt we did not give the tester enough information beforehand for them to understand the situation. In the end, four testers preferred test B (using the printed ticket on exit) and three testers preferred test A (using the app to pay). One of the testers expressed concern over receiving printed tickets for environmental reasons, as the tickets would have to be recycled of afterwards. In the end, we decided to go with go with the method used in test A, but kept the printed receipts for drivers who did not have the app.
With the four testing sessions completed, we went to work on the final iteration of our design. The feedback we received during the sessions was very helpful for helping us improve and refine our design.
We incorporated an electronic sign into our parking lot design. This was suggested numerous times during our Participatory Design session. This is helpful for drivers pulling into the campus to see which parking spots are free without having to drive around aimlessly.
The kiosks did not receive many changes to its design. We improved the readability of the text on screen by making the screen white with a thicker black text. The entrance kiosk overall remained unchanged.
The exit kiosk received more changes than the exit kiosk. We added the accepted methods of payment on the kiosk itself, and allowed the user to immediately input their payment method of choice once the details screen came up rather than selecting the payment method first. We felt that step was redundant and noticed users not doing it during our focus group session.
The app received the biggest change in our design. We added colour to give the app a visual identity. In terms of functionality, we added a scannable parking pass QR code screen to the app, which the user can access through a FAB on the home screen. This allows the user to scan their parking pass at the entrance and exit kiosks.
Apart from changing the add buttons on the Payment Methods and Parking Passes screens to FABs, we added a Receipts screen in the profile section. Testers who used the app to interact with our kiosks wanted to get information on how long they parked and when they parked, so we placed this information in a reverse chronological list under receipts. Each entry states which parking lot they parked in, the date they parked, length of time parked and amount paid for parking. For drivers who are currently parked, the item is at the top of the list and shows how much they owe at that moment in time.
This project was more ambitious than Spec Detect in my eyes. I had worries early on that we would have trouble doing this project because of the scope of the project compared to what I heard other groups were doing, as well as the restrictions imposed onto us by our professor where we were only allowed to run our tests in class. In the end though, this project turned out to be a huge success, and not just because of the high mark we earned on this project. The testing sessions were very valuable to us as we went through our design and the evolution of our design shows how we were able to integrate user feedback into our design and make it better for our users. It's a true look at how UX can shape a design and how important it is to design for your users.Back to top ↑