About Parkit
Parkit is an app designed to help users find parking around them, or at a specific destination.
The Challenge
To design an app that helps user find parking whether they are driving or stationary.
The approach
A prototype of this app was already created when I undertook this project. I went through the prototype, and identified what problems existed with the flow and functionality.
I then examined how a user would approach the app, and what their pain points would be. I asked myself “What is the most important functionality?”. From there, I’ve identified and stripped the original prototype to that user goal – finding parking. I then asked myself: “How would the user approach to solve this problem?”, “ What environment would they be in when interacting with the app?”. When designing this application, what the user is doing and where plays a crucial part in streamlining their experience with the app. Are they driving in their cars? If yes, is the driver using the app to find parking, or is their passenger using the app to find parking? Or are they at home conducting the search? Is the user hosting a party, and want to share to his / her friends about available parking around the party location? With these questions, not only did I use them against the current prototype, I generated user goals and a general foundation for creating personas.
With a general foundation for creating personas, I went to validate them, and identify what features, information, and functionality would help the users in their journey. I did this through user interviews, asking them a series of questions on what they find most important when finding parking. I’ve also asked users about current apps that currently exists in the marketplace that tries to solve this problem, and what their pain points are with that application.
After all information has been gathered and analysed, I drafted up wireframes using SKETCH, and prototyped it on Invisionapp. I then conducted user testing to identify if the flow made sense to them, and if it was made easy to complete their primary user goal – finding parking.
The Green P
The Green P app was a common app that was brought up when discussing with users on apps they currently use, or app that came to mind that attempts to solve the problem of finding parking. Aside from asking the users what their pain points were with the app, I downloaded the app, and went through the app trying to accomplish the user goal of finding parking.
While playing around with the app, I’ve identified that the Green P app does find Green P parking lots, but it is not its primary goal. The app’s primary goal was to assist and make convenient in paying for parking at Green P lots. Their finder was more of a secondary user goal / flow. Although the feature does find Green P lots near the user, it does not solve the problem if the user did not turn on their location settings, or if they were searching from a different location.
Taking in these pain points, it was clear on how to improve their designs, and on a business aspect, on how to generate money. Since the Green P app only tailored towards Green P lots, having a third party parking app such as Parkit, can allow for other lots to be listed that are not government owned. Private and public lots can be listed on the app and can use the app as an ad serving platform to generate business for their lots.
B2B Possibilities
Aside from other lots using the app as an ad serving platform, the lots can take advantage of the ease-of-payment with phone world. Parking lots, can use the app to manage, as well as allowing users to pay for their parking. Other solutions can be later implemented to assist users finding parking and helping lots generating business. When designing this app, I kept this in the back of my mind on where is it possible to generate money from the app while providing a clean experience for users both parking seekers, and lot operators.
The product
The final product was designed accessible enough for drivers, easy enough for passengers who are not familiar with the app, and for users at a stationary location.
Designing the onboarding experience
When designing the onboarding experience, I had to make sure that the app communicates what the was designed to do, and why the app requires certain things like location to be turned on in a non-disruptive manner. I’ve designed out 2 onboarding flows, one using current location, and one where user does not allow app to user location services.
To login or not to login
The original Parkit prototype had the user login as part of the onboarding experience. I looked at this flow and thought, is login necessary? Does it disrupt the flow? Although, I do understand the importance of “logging in” or “registering” to create a profile to further streamline the experience with storing lots visited, favourite lots, and potentially payment information, it did not seem necessary asking at the beginning.
Here are my reasons:
- 2 / 3 identified approaches in the use of this application would cause potential pain points. If the user was driving and wanted to find parking, the user has no time to login or register if the user has just downloaded the app or for some reason the app had refreshed; thus asking for the user’s credentials.
- If the user was driving, and passed his / her phone to the passenger to use the app, it causes time delay and frustration when the passenger is asking for login / registration credentials.
- When the user is using location services to find parking, most likely the user has already arrived at destination and is looking for parking round it. It’s best to jump to the point, and give the user what they need for a pleasant experience.
- Since Parkit if launched is an unknown product / brand, giving a “trial” of the product before asking the user for information would reduce drop off rates as well as letting the user experience the application.
Asking for login / registration information can be later asked when the user wants to add to favourites, pay for parking, or any other additional feature. The user will more willingly to register as a trust has been built with the product and brand.
The onboarding flow
The reasoning for these 2 flows is not only different advantages from using location services, but where and what the user is doing when using the app. When the user uses location services, most likely they are in a travelling vehicle whilst a user who doesn’t enable location is most likely in a stationary environment – the user doesn’t have time to input destination into search bar vs has time.
The Splash
Even though the “splash” screen wouldn’t last very long, the screen states what the app does and instructions on how to use the app at a quick glance.
Asking for location permission
Right after the splash screen, we get directly to the point and ask the user for location services. Instead of jumping directly into the android system message in asking the user if the app can use location services, there is a screen before that asks the user for permission. This may seem repetitive; however, it serves a larger purpose.
The screen at a glance identifies to the user how long the setup is before the user gets to use the app for real, and why the app wants to use the user’s location. This is a really early stage of the app experience. Even though the name, marketing, and splash screen may hint the reasoning and advantages for the app wanting to use the user’s location settings, it is reassuring and more comforting with an explanation and advantage than launching out “HEY. Can I use your location because of reasons?” like Tinder.
The secondary action to not allow the app to use the user’s location is also available to prevent drop offs from users who still do not wish to use their location. The app can still be functional without the use of the user’s location, so why not allow them to use it if they say no even though it is better to use location.
Setting up preferences
After asking the user if the app can use their location, the app asks for their search preferences – the app asks even if the user says “no”.
The preferences the app asks for are:
- Search proximity
- Garaged
- Open lots
- Street
These 4 parameters are the most important questions that come to mind when searching for a lot since price is relatively the same. This also prevents the app from searching all lots available at a time, but it is to a specific location.
The button text “Find me parking” reassures to the user what is going to happen next – the setup has been completed.
finding parking
Depending on the user’s decision to allow the app to user their location or not, the flow may differ from here onward.
We’re going to go through the flow as if the user did not accept locations first.
Once the user has gone through setup, it is time for them to use the product; however, how to use the product? Even though the splash screen at a very high level explained how to use the app: “Search, Select, Park”, an unfamiliar product could be confusing.
Clear instructions for the user that communicates what to do next is stated on the first page they land on. The user has more time here – they are not driving. How do I know this? Because they declined the use of locations. Given, this may not be a 100%, but it is still designed that even if you are, you can input via mic with the mic icon.
The instructions is very important especially if the phone is passed to the passenger. Many times have I personally come into the problem when I tell the passenger to take control and navigate through an app. I get this reply 90% of the times “How do I do that?”.
The background image is a taste of what is supposed to be displayed once a location has been set. It communicates to the user: “Oh. Okay. That’s what’s supposed to happen and I’ll expect that result.”.
After landing on this page, we can attempt to persuade the user to use their location for a truly better experience. Having the button located on this page helps motivate the user to do it. The user, after seeing why enabling locations would be beneficial may entice the user to use it. Reassuring text on what the app would use the location for would help knock down any security reasons for not enabling locations.
If the user has said "Yes" in allowing the app to use their current location, the flow is as follows.
If the user had enabled the app to use their location, the app jumps directly to searching for parking around the user. This is beneficial for someone who is driving.
It is important to communicate to the user on what it’s doing every step of the way. The loading screen is a great way for the user to not only identify what the app is doing, but their search parameters, and if need be, an escape to search for a specific location instead of searching around the user’s location.
Selecting a lot Flow
The flow is made simple and made similar to a familiar app Google maps. Since it’s similar with its use of material design and flow, it is very for the user to grasp on how to use. Modifications were made to tailor towards the use of this app.
Scroll that list
The user has 2 option when the app displays parking lot results. The user can either interact with the map or scroll to use the list view. The list view when the user scrolls, the map gets smaller as it becomes a secondary as the user is primarily looking at the list, and not at the map. The map zooms in displaying what the user sees on the list based on location proximity.
For an example,
When the user scrolls to “10 meters away”, the map will only display lots that are within 10 meters away. When the user scrolls to “20 meters away”, the map will only display the lots that are within 20 meters.
The user can toggle between map view and list view.
Selecting that map
The user can interact with the map and select a location. Once selected, the same information is displayed that is available when a user selects a lot via list view. The user can scroll up in both instances to get more information.