Published on | Prototyping: From UX to Front End — Medium Carolyn Ly

This is a design project I completed as a student at RED Academy.

After completing my third year of university, I decided to get get my hands dirty by enrolling in the UX Design Foundation program during my summer break. I had signed up for the Summer ‘17 cohort that would run for 10 weeks from June to September.

The capstone project we had to do throughout the program were done in conjunction with the lectures and workshops. It allowed me to apply new skills I learned from my instructors along the way.

For the capstone, my classmates and I were given the liberty to individually identify a problem to eventually design a solution. As a person living in the bustling city of Toronto, I picked a problem that aligned with my personal experiences: downtown parking.

For the purpose of this course, the product we had to design was an app for the iPhone 7.

Examining competitors

From being the person in the car, to the observations I’ve made of drivers scouring the area to find suitable parking — I knew it was a topic I wanted to explore, so I began my project by doing some research.

I did some comparative competitor research to see how other products were tackling the issue of parking. Through close inspection I used my own insight, along with user reviews, to roughly type down the following: the features my app would need, the type of information required to be made visible, and what pieces of content should be in focus. This would serve to give my app an advantage over competitors.

The two apps I chose were: Green P, and Park Shark.

Looking closely at the problem

Before cutting straight to the solution, I wanted to dissect the issue in order to understand what types of experiences drivers have in Toronto. Despite experiencing and hearing negative things about downtown parking, I didn’t want to make any assumptions that would produce biased results*. To further this investigation, my next step was to conduct user interviews.

*A representativeness heuristic is a cognitive bias where we categorize a situation based on a pattern of previous experiences or beliefs about the scenario.

The interviews

Before proceeding to the interviews, I screened the questions over and over again to avoid any leading questions to mitigate the chances of bias.

I had a total of 5 participants for my interview. A constraint was not being able to randomly select interviewees from my target population (drivers who have driven in Ontario) due to the nature of the project, so I asked friends and acquaintances to take part instead. The participants’ ages ranged between 22–30 years old.

Participant 1:

From Cobourg, ON
Found parking harder than average but the greatest downfall was high cost for parking
Also, there’s a lot of parallel parking
Said that parking sucks in addition to the busy traffic, making parking tedious and time-consuming.
friends who live in Toronto can navigate it much better. Since they know the city a lot better, they probably have a greater understanding of where to go, and which places are best for parking.

Participant 2:

From Hamilton, ON
Uses Uber to avoid parking to save time (spent 30+ minutes finding a spot his last experience)
Does not use it all the time because it gets expensive for more than one trip
Prefers to drive but finds the drive downtown annoying because it is difficult to find affordable parking
Would rather pay a flat rate for transit instead of driving due to the search for parking — paying for an hourly rate is less appealing.
Does not trust leaving his car in a parking garage due to the fear of theft or any other crime.

Participant 3:

From Mississauga, ON
Does not own a car for financial reasons
Carpools or uses public transit
Dislikes the traffic and the time wasted when his driver tries to find parking

Participant 4:

From Toronto, ON
Prefers to travel by car, even though she acknowledges that it can be potentially time-consuming to find parking. Public transit is the last resort for special circumstances (ex. if car is unavailable)
Sometimes has trouble finding a spot if not fast enough — would lose parking spot. This happens often at U of T (the school the participant attends)
Dislikes getting parking tickets for being a couple minutes late due to active ticketers — she considers this the worst part of the experience

Participant 5:

From Toronto, ON
Prefers to travel by car and seldom uses public transportation
Does not find parking difficult because he knows the area very well, and thus knows the best places to park for free or for a low price
He thinks that living in Toronto has trained him to become a better driver so parking in tight spaces is no problem

From talking to each person I generally found that those who were from outside the city of Toronto had more difficulty. It also left a negative impression that consequently became a decision-factor for if they wanted to visit the city again or not.

The surveys

In order to test if my insights were correct, I decided to conduct a survey except this time with an effort to mitigate potential biases. I surveyed roughly 170 strangers online from across different parts of Canada (though they were mostly from Ontario) through ads on Facebook.

Qualitative survey results taken from original Google Form

From both quantitative and qualitative data, I made an affinity map and noticed that 9 of 10 people of the 18 percent living outside Toronto, mentioned that parking was a big pain point. The extent of the struggle was generally proportional to the number of times they’ve been in Toronto*, and inversely proportional to their age**. As a result, I had a good idea of who my primary persona was.

*More frequent visitors of Toronto seemed to have more positive experiences with parking.

**The younger the driver, the greater the pain point probably due to the fact that they would generally have less experience on the road.

The Persona

Using Sketch App, I created a profile for my primary persona based on the above findings.

The persona flow becomes useful to understanding what the user’s goals are. I came up with user stories underscoring their goals:

As a driver from outside Toronto, I want to find free parking so I can be more economic when I go out or travel

As a driver from outside Toronto, I want to quickly find parking so I can prevent spending too much time in heavy traffic

As a driver from outside Toronto, I want to find a parking that is within my driving ability

I built a list of features that were catered to these user goals and then categorized them into three sections — “needs”, “nice-to-haves”, and “not necessary” — to create the minimum viable product (MVP).

After creating a user flow, it was time to start designing!

Original user flow (has since been modified after usability tests)

Sketches and Wireframes

Despite creating the MVP, I had some trouble with my design. Using the Agile design approach, I had to go back and refine the prioritized list of features to further improve the usability and experience of my app.

Here are some early sketches of the low-fidelity wireframe:

I then turned my wireframes into a paper prototype. You can test the digital paper version here.

Here are some changes that I’ve made based on usability testing (5 participants in total):

Filter isn’t being used in anticipated order so I needed to go in and revise this (users preferred to filter their searches later)
The bottom toggle icons should be labeled to avoid confusion of what they mean
Add more icons for the bottom toggle instead of placing information elsewhere because it’s harder to find (accessing account information from the hamburger menu was less conventional and harder to navigate)
Omit the free public parking option and make the app focus on people renting out their private property for parking (Parking P is an app the city already uses for public parking)
Instead of the credit card information from the beginning, maybe present it to them when they need it (with a save information option so they do not have to input it again)
Required a legend to understand the availability chart to book parking

It took multiple iterations — a constant feedback loop between usability research and design. I think I changed my design a total of 5 times, so I had to change the site-map (not pictured) as well. Paper prototyping was quick and easy because I could sketch over my wireframes.

After I was done with that, I moved on digitizing the design using a vector-based tool called Sketch (which is quite similar to Adobe Illustrator, but I find it much faster to use. Its files are compatible anyway).

…An early version of my mid-fidelity wireframes:

Mid-fidelity wireframes (iteration no. 4)

After running another round of usability tests (this time with 8 participants), I made even more changes. Again, creating another prototype with the following considerations and changes:

Participants had to explore the pages from the bottom toggle before getting used to the app. Implementing a walkthrough can save new users time. Those who like exploring on their own can skip through using a skip button
Some pages were too dense with information. Spacing things out and adding accordion menus would make the presentation of some information less overwhelming
A suggestion from the instructor: when the user is looking for directions, have the Park.me app open Google Maps to avoid adding too many functionalities. This avoids unnecessarily extra work and complications that Google’s design has otherwise already considered
With the above in mind, it’s not necessary to add two search bars if I’m excluding the directions from the design. Using the search bar to input the location the user needs to find nearby parking is sufficient.

After a lot of tweaking, I finally created my final prototype using the mid-fidelity wireframes. My options were either Azure or InVision, but I opted for InVision instead because it was compatible with Sketch App on my Macbook.

Test it out here.

User interface and more

Though this is more of a UX focused capstone project, I tried to play around with Sketch to incorporate some UI elements to the project.

Loading (left), Nothing (center), Correct/Incorrect (right) screens

Loading Screen

Since waiting for something to load could be boring, I decided to add playfulness to the loading screen. By giving the car a path to travel on, it gives the user a fun visual of their current progress.

Nothing Screen

After users create their account, when they enter the home screen there’s a tutorial that walks them through each part of the app. There is a progress bar that allows users to anticipate how many stages they are left. Users also have the liberty to skip if they want to proceed.

Correct/Incorrect

This correct and incorrect screen is an example of a possible form the user needs to input. A pain point is presenting an error notification after the user filled out all of their information. Users generally find this frustrating because they have to re-enter their info (especially if some parts refresh). My design allows for notification errors to pop-up along the way so users can make direct changes to the form.

Empty (left), Too Many (center), and Confirmation (right) screens

Empty Screen

Since waiting for something to load could be boring, I decided to add playfulness to the loading screen. By giving the car a path to travel on, it gives the user a fun visual of their current progress.

Too Many

This Too Many screen is an example of where a lot of information is presented. I decided to make an infinite scroll so users can see which listing corresponds to the one on the map. The number of results are restricted anyway by the filter (results that show up within a certain area radius).

Confirmation Screen

The confirmation screen lets users know whenever they’ve successfully completed a task. An important one is right after payment to ensure that their transaction has been successful.

Going forward

After months of working on this project, I have finally finished. There was a lot that I had learned from this course that I will apply to current and future projects, including a mobile app I’m designing for my friend’s startup and also a nutrition app for the health organization I volunteer for.

In the future I would likely consider designing for the stakeholder’s user experience because for this capstone I only considered the consumer’s perspective and experience. Another goal is to potentially improve the project by completing the UI. Though RED Academy’s program focuses on the UX, it would be a good exercise to complete the high fidelity prototype as well.

If you’ve made it this far, thank you for reading!

RED Academy Capstone: Solving difficult parking in Toronto was originally published in prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

RED Academy Capstone: Solving difficult parking in Toronto

Cool stuff, every week

More Articles