ParkAmigo is driveway sharing startup. I joined in late 2018, performed detailed usability assessments of the current App and redesigned its UX and UI from the ground up. This case study covers the redesign process and focus on the interactions of “Find Parking”.
Easily jump between choices and see the rates and time limits for comparison.
Reserve a spot and you have 15mins to get there and check in.
See the price that you have accumulated, when do you have to pick up your car and how far you are to your parking location.
1. Fill in the location, enter your price, upload a picture, and add a pin over the picture.
2. Enter your bank detail for earning payouts.
3. Turn the toggle, make your listing discoverable.
ParkAmigo has a two-sided market. The supply side is similar to Airbnb, users list their available spaces. The demand side is similar to Uber, users request parking spots on demand. The current App fulfills both sides’ need, but doesn’t do either well enough. In order to attract more demands for parking, we set out to improve the finding parking experience.
I listed two important questions before I start examining the current design
1. Is there any redundancy that distracts parking users in their interactions?
2. Does the interface align with peoples’ mental model on using a map-based App?
You are close to the destination. Yourself or a passenger in the car opens ParkAmigo to look for a parking spot nearby. After taping on the few different options nearby and comparing their time availabilities and prices, you decide on one. You tap the reserve button, take up to 15 mins to drive to the location, and scan the QR code to check in.
With the current design, it takes a minimum of four taps for a user to make a reservation. In the case of checking out another option, it’s three more taps for every switch.
Design Opportunity I：Reduce the steps between opening the App and deciding on a parking space. Improve the efficiency for the users checking out different options.
The current App follows a typical 2014 map-based iOS App’s UI Pattern. The layout is not custom built for the service.Let’s take the interface apart and see how each section functions for the interaction required to find parking.
Search Bar: Since we don’t allow booking in advance, we encourage users to look for spots when they are close to their destinations. For the rare occasion, you can search for parking somewhere other than current location.
Conclusion: Search bar serves a purpose, but it’s not as frequently used as other Apps.
Tabs Bar: To switch between the categories you are searching for. As extra functions are overshadowing the primary parking function. We strategically decided to prioritize parking, remove extra function and thrive for a minimum viable product.
Conclusion: Categories would be either collapsed into one tab, or deprecated.
Map and Pins: Users can move around the map and explore parking locations. They can see parking spot markers and tap between options.
Conclusion: Markers and the map should be prioritized.
Menu Tab Bar: For parking users, they only need the “Parking Status“ tab when their car is parked. As for the “My Driveway” tab, it shouldn’t be shown a user with no intention of listing driveways.
Conclusion: We should separate what parking users and driveway-owners see. Not all of the tabs are necessary in the menu bar.
Over the past few years, the market has changed and a few competitors have matured. I used product thinking to help the team to recalibrate our targeted audience, find our competitive edge and better align our missions.
Find parking on the street, on demand. Park at user-listed driveways and never having to deal with garage navigation.
Users has to input information and find parking in advance with other app. When you are already close to destination, there’s no spontaneous options other than putting in a lengthy requests.
Drivers who park spontaneously, always changing schedule and need parking spots on demand.
We started by analyzing our current App, taking apart and auditing UI elements and interaction flows. Based off of my analysis and assumptions, as well as the recalibrated targeted audience, below are the key objectives we set for the redesign. In redesign, we wanted to restructure the UI based on projected usage and redesigning how information are presented and layered. We explored ways to make it more efficient, intuitive and inviting for users to find parking.
Redesign the UI with new visual theme.
Restructure the app to focus on parking users.
Improve efficiency of finding parking.
There were contrast issues and inconsistencies everywhere in the App. However, instead of fixing all the small problems, I was encouraged to redesign the visual theme from the ground up. Since the original App was scheduled to go live soon before I joined, I didn’t have the time for workshopping conceptual low-fi prototype with the rest of the team. A visual update is expected first and foremost, so I quickly refreshed the main screen to set a tone for a new visual theme. Given the time constraint, as we progress into the structural redesign, I continued presenting designs in higher fidelity.
To help me empathize with the parking users, I asked myself these three questions:
1. What’s happening before people open the App and start interacting with ParkAmigo?
2. How urgent are users while searching for a spot?3. What happens after check-in?
3. What happens after check-in?
When users open the App looking for a parking space nearby, they want to see a map as soon as possible with nearby availabilities. We decided to remove the “choose” screen from the flow and have the parking tab active by default. To focus on parking, we combined all the local experiences into an ‘explore’ tab.
Since we want to encourage users to look for parking when they are already in the area, the search function wouldn’t be used very frequently, we reduced its visual weight.
While the menu tab system has its pros, for the single-action service that we are offering, we decided to opt for the side drawer system creating a distraction-free experience.
After adopting a different menu structure, the next step is rearranging the information architecture. From the main screen, we expanded to a few other key screens including the side menu and designing the my profile page, where the list component will be reused throughout the app.
After researching through different Apps using side drawers and reading through material design’s guideline, we devised the layer structure below.
Following the structure, we gradually created symbols and cards and expanded to all other pages of the App.
We started designing by listing out the interactions and trim down to the minimum amount of screens to be efficient but still flexible.
Contradicting to helping people park fast, in designing the process, I chose to design slow and guide people through the process. As a niche service, I tried to match people’s mental modal when they use a map app to find a restaurant and navigate there. Although sometimes a guided work-flow takes longer to complete, but it results in higher conversions and satisfaction.
Show the price?
Since the driveway owner list their own prices, we can expect parking users to switch between options before deciding on one. Being able to compare price is very important. The most efficient way is to display the prices on the markers:
1. Most straightforward for price comparison
1. User still need to take the available-until time into consideration, so they still may switch around after choosing the cheapest option.
2. Price sensitive users would move the map around to find cheaper spots, resulting in detours and ultimately bad experiences.
Hide the price
What we explored next is a collapsed card that shows the price and time limit. It occupies a smaller screen space so users can still scroll around and explore other markers while the card is active.
From a developing stand point, it is very flexible for future iterations. A product approach we may explore is standardized dynamic pricing for areas. This design give us maximum flexibility on the information we choose to display at different stages of the card.
From the user stand point, when they are not presented with the price upfront, they will naturally pick the most convenient location. For someone who is not price-sensitive, if the price is acceptable, the mental price comparison is effectively taken out of the the user’s process.
1. Flexible for future iterations
2. Change information displayed on different stage of the card without breaking up other designs
3. Prompt users to explore most convenient option first
Price sensitive users may take a long time exploring all options on screen to find the most affordable option.
Preventing decision paralysis for price sensitive users
If we show every single spots available, a price sensitive user may tap on all the choices hunting for the best deal. In the event of too many options available in the area, since human cognitive ability cannot efficiently compare more than five options, we show the six most affordable options with at least two hours opening. Due to the abundant supplies, the price range between the six options would be very small.
We are also considering a special marker for lowest price (exploring at the end).
Two pieces of important information at this stage:
1. Hourly rate
2.Available until time
After the card expansion, we left some space on top of the card so that the user can still see the map. Seeing a portion of the map gives them comfort that they can easily access the map and explore other options.
Balancing visual hierarchy between the ‘Reserve’ CTA and the ‘Check in’ CTA was a challenge. Normally a user would reserve and then check-in on arrival, but giving the option to skip ‘Reserve’ and checking directly is still offered. Tapping on ‘Reserve’ creates an additional state of the card. We included a progress bar to show how much time you have left to get to the location before your reservation expires.
To track the parking after users are checked in. We add the “parking status” card using the same system. First, we made it clear that this address is where your car is parked. Then we included a total price accumulated as well as the remaining available time. Finally, we changed the ETA from driving to walking mode.
Tap around options, reserve one for 15 mins. Take your time to get there before reservation expires. Can’t make it or found some other way to park? Simply cancel the reservation. Finally, scan the QR code to check in.
When viewing your parking status, you can monitor the accumulated price as well as the original rate. See the ending time and track how long you have left. After you check out, see a quick summary of the parking activity. If anything didn’t go right, you can also contact support from there.
We are currently user testing the “pick a spot” interaction. Users turned out to be more price sensitive than we expected, despite the close price range, a lot of subjects still went to the length taping on all six options. Although there maybe inaccuracy, since we didn’t simulate the experience putting our test subjects in cars, they weren’t in a hurry checking out all six spots.
A potential solution is using highlighted markers for “Best Option” and “Lowest Price”. Longest available time can also be offered is needed. The decision we made to keep the markers simple made this kind of potential iteration possible without shaking up the interaction flow and the design system. Interactions that are compartmentalized give us flexibility on a/b testings in the future.
Conversions — from user start exploring markers to reserving a spot & from reservation to finish parking.
Average spots found — we have potential collaboration that we can access garage API if no user-listed spot is found in a search.
Parking time length — it partially reflects if users trust the model.
Driving time to parking — it reflects if the navigation view is effective. It also will give an indication on if the reservation time limit could be adjusted.
Feedback — we have a summary screen with an option to provide feedback at the end of a parking flow. That would give a qualitative insight into the users’ real life difficulties.