This project is from 2016! Visually it's lacking, but kept it here to showcase some process đź‘Ť
Challenge and brief
For this academic prompt, our creative director gave us a scenario where Uber has decided to enter the booming industry of car-sharing.
Opposed to Uber’s current ride-sharing dominance, car-sharing is physically renting and driving a car for any amount of time. Uber wants a share of the action, with the intention of addressing the current needs of users, attracting new users, and creating repeat users.

Our challenge as UX/UI designers was to design an incredible car-sharing iOS app from the ground up that addresses the current pitfalls of the industry. 
Mapping out a whole lot of interviews from users with all kinds of knowledge backgrounds.
Exploring the landscape
We began with a few questions: 
After high level research, we discovered the academic prompt to be true; the market was growing at a rapid rate. The industry is projected to grow...

“$1.1 billion in 2015 to $6.5 billion in 2024, with 66% of car-share users between the ages of 19 to 35."

This also informed our initial age demographic of our target audience. We paired this statistic with the decline of millennials buying cars and Uber’s growing profit and it became clear why Uber wanted to enter this market. 

There is an extremely large amount of people converting to the sharing economy and car-sharing is beginning to lead the pack.
The number of shared cars on the road is projected to grow quickly over the next 15 years, causing a decline in vehicle production due to declining car ownership. Left, Right.
Car-sharing companies have their demand well established but all supply their demand from a different source. 

Cars can either be sourced from their own fleet or from personal ownership of their community (peer to peer). We found a steady divide between the two across the industry. This lead us to our first binary distinction - fleet models (e.g. Hertz) versus peer-to-peer (e.g. Turo).
Hertz and Zipcar own their own fleet, while Turo and Getaround rely on peer-to-peer. Fleet models have volume but suffer maintenance costs, while the peer-to-peer models is cheaper, but relies on community for it's full supply.
This distinction allowed us to tailor our interviews towards determining which supply will best support our users' needs. Our initial assumption was to differentiate ourselves from the traditional fleet model and follow a modern peer-to-peer approach, but these assumptions needed validation.
Understanding our users
The overarching questions:
Before these questions we were clueless about the general public’s understanding of car-sharing. These important questions were meant to give an introductory direction to the project. It quickly informed us about our peer-to-peer versus fleet model decision.

We synthesized our interviews by grouping our takeaways by similarity to uncover new patterns. We were then able to visualize all of our data and uncover the voice of our users accurately.
Evaluating and pinpointing what our affinity groups meant for our users. Many users were concerned about allowing other people to use their cars, even for a short period of time.
This was a breath of life into our group. We began to see why car-sharing was appealing to our users. They loved short trips. 

We also learned when users found car-sharing situations applicable to their lives. We discovered where and why their goals and frustrations existed, and most of them revolved around poor transparency and limited availability.
Affinity mapping stemmed into creating recurring groups such as type of trips, fleet vs peer-to-peer opinions, and current knowledge of car-sharing.
Overall research findings and themes
After synthesizing our takeaways from our research, we illuminated a few takeaways:
This began shaping our first direction. Users didn’t desire an entirely different service. They wanted existing services to have increased integrity and availability.

We found that most users often did not want to lend their personal cars to others for any amount of time. This concerned us about which type of supply model to design for. 

With demand so substantial for car-sharing, how could we possibly meet it with a low supply? For this reason, we ended up concept testing for the fleet model rather than peer-to-peer.

Visualizing the process of booking a car
We began to discuss and illuminate areas of frustration and delight for the current space of car-sharing. Through this visual of the entire process of booking a car, or group began to see precisely when common frustrations occurred.
The early dip on the left hand side indicates initial frustration with the lack of locations. As the process goes along, the user begins to feel more confident about the process.
This revealed a lot of frustration appeared early in the booking process. Simply finding a nearby location was a major pain point. The major moment of delight is when the booking process is smooth, the fees and conditions are clearly portrayed, and the locations are plentiful.
Setting the foundation
Up to this point, our research allowed us to understand our project direction. We began to distill all of our findings into two actionable references. We used our problem statement along every step of the way as a marker of our primary research.

How can we design a simple and convenient system to welcome new users, create repeat users, reveal locations with ease, and offer a transparent car-sharing experience?

We then created design principles from the aggregate of our data by pulling information from pain points, frustrations, and the most prevalent goals from our users. These five qualities addressed the major problem of inconvenient and non-transparent car sharing. They also were the guidelines for the future of Uber.
This served as the solid foundation for our designs. It ensured our design aligned with our users. It continued to help us stay true to our research by driving the proper ideas. Equally as important, it helped us to stay away from ideas that subtracted from our vision, seen in the UI portion of the project.
From research to prototyping
It was time to bridge the gap into design solutions. Utilizing our foundation, we sketched out different ideas and discussed their importance. We drew conceptual sketches and critiqued each other about their implications for our product’s future. By the end we had created dozens of prototyping ideas.
Left: Search feature exploration. A few ideas combined search with filtering. and others pairing it directly with a map view. Right: Just a glimpse of the many sketches we did (will need to be recreated)
Dot voting highlighted the idea of transparency costs and a full detail before purchasing a car as crucial elements to our design. The right hand side was an idea for add-ons. This did not make it into the prototype due to it attempting solving a problem that didn’t exist.
Our group used paper prototyping due to its quick nature. This quick prototyping process allowed our ideas to quickly transfer to actionable concept tests. It allowed us to receive feedback quickly and reiterate often. Our task flow was to have a user login, find a car, and book it. We all separately designed a flow around that task.
Basic flow went from picking a date and time, filtering, finding, selecting, and then booking a car.
A photo of me beginning to introduce our concept testing to a user. We introduced the prototype screens in a stack, and as they tapped on buttons, we introduced the next screen in the flow.
Left: Welcome page and nearby cars was my first idea of introducing the user to the app. This idea presented the user with a quick selection of cars, which was interpreted as promoted vehicles.
Middle: Location map and car selection. My initial idea was to have the filtering options shown with the map on the same screen. Users desired the filter and map to be viewed separately.
Right: Pick up options and payment method. The idea was to have users take an uber to their location. We ended up removing this unnecessary feature down the road, and changing the payment method onto the final screen
Overall UX findings
Given our foundational research and concept testing results, we were ready as a group to converge on a prototype that embodied our direction. This direction will provide users with short trips in a powerful, simplistic, and transparent manner. It will provide a robust filtering system and a versatile map/list view. The design will convey a strong sense of confidence and integrity, encouraging a repeat user.
Convergence on the final prototype
After a lengthy group discussion of relating back to our values, testing results, and our initial foundation, we determined that my prototype solution will be implemented into our mid-fidelity wireframes.
For my paper prototype, the sliders for selecting the time tested out very well, but the calendar feature was tedious. With our wireframes we enhanced the calendar system to a more visual input and kept the sliders for further testing.
We selected my prototype concept because it best represented our overall findings. We created these wireframes due to the visual simplicity embracing white space, fewer screens in the user flow, and map/list view testing best among users.
Left: Filter page. This auto-populated cars near the user based upon their categorization selection. Middle: Map view. This uses current location or a searched area to find car locations. Right: List view. This presented locations nearby with a greater amount of information for direct comparison.
The filter feature was simple yet robust - striking the correct balance of effectiveness and simplicity. User opinion about filtering varied to such a large extent that we needed to hit the right medium. This solution of categorizing vehicles tested most effectively.

After filtering, many users needed to visualize the location proximity and the map view was an effective solution. Clicking on a location in the map view showed a dialog box which kept the user on the current page. The list view then satisfied those seeking a larger volume of information for comparison rather simply than location.
The flow of selection to purchase. Users appreciated being given exact and clear information, and being told all the details after their purchase. This instilled confidence in the service they’re receiving.
The bottom navigation bar. Home is where all reservations and recommendations exist. Nearby consists of the map/list view. Favorites contains all cars the user saves for later use.
We chose home, nearby, and favorites as the navigation bar tabs. Previously we had 4 tabs. After group discussion we found it to be unnecessary. Users wanted primarily three things. A place to view their reservations, a place to search, and a place to view their save cars. Through testing, users did not require additional tabs.

The convergence of our wireframes properly represented our design principles and problem statement. It created a smooth, seamless, sensible, and effective way to find a vehicle and quickly find nearby locations.

Due to the locations being an critical factor in user goals, we designed for a large amount of locations. Similar to the expansiveness of Starbucks, locations will be widespread throughout cities and towns. With several parking lots of available cars, paired with a powerfully transparent and seamless task flow, our next step was applying our visual language.

Applying a visual language
We began looking at our competitors’ branding to see where we could differentiate. Many traditional and established companies expressed their history with outdated branding. Relatively new companies such as Lyft and Uber took more modern approaches. Our solution struck a healthy medium so that it could be both timeless and relevant.
Left: Hertz uses a bright yellow outdated corporate branding which does not appeal to younger users entering the car sharing industry. Right: Turo embraces a modern adventurous style, following trendy photo-rich designs.
Our next step was to compile images from several mediums for our visual inspiration. Once we discussed our visual choices, we began to explore which branding evoked our core attributes from our UX research. We began to portray our interpretation of the brand vision.

A style tile example. Most of our users rented cars for short trips, so this example embraces the adventurous side. However, this style ended up being too moody.
After each group member created their own style tile, we discussed their relevance. After critique, we refined our style tiles after gaining perspective from group members. Then we administered our visual style into our final wireframes.
An example screen from each concept, where we tested four separate visual languages
We had users go through our previous task flow: login, find a car near you, and the process of booking it. We then asked each participant to explain if the task flow is easy or difficult. We concluded with asking users how they felt about the whole process, and which prototype they are most likely to use in the future, and why.
Overall UI findings
Given these test results, it was indicated that my group member’s prototype would be moving forward. However, all prototypes tested well, indicating we were all on the right track. Our next task was to begin finalizing our UI with guidelines: typography, iconography, and branding color.
Preparing the final UI
With a large interest in UI, I stepped forward to take over the Sketch source file. I made sure to collaborate with my team members every step of the way. Most importantly, I referred back to our research foundation and testing results when making visual decisions. When the design began to stray into what “might look good”, we instead made decisions based that would evoke emotions that align with our UX foundation.

Our group began to create UI guides. I started with typography with thin weights and modern san serif typefaces, taken from my prototype shown earlier.
Using Avenir at different weights portrayed credibility and enhanced readability among our users
Next up was iconography. Embracing a similar style, I kept line weights light and consistent with the typography. This tested well among users. It was clear enough to notice the navigation tabs, but not enough visual weight to take away from the flow and CTA of a task.
Bottom navigation bar. The home contains current reservations. Book is the process to reserving a car. Nearby will pull up the map/list view. Favorites will show all cars that were saved for later use. The teal displayed which part of the app they are currently in.
To adhere to Uber branding, I kept a charcoal black throughout. Having a charcoal gray as the CTA was admittedly an odd choice. It’s not a common CTA color. But it tested well; it tested better than a teal or red CTA. I strongly recommended it as a future consideration, but due to time we could not address it without additional testing.
Using the CTA as a strip above the navigation bar was a design pattern consistent throughout the entire prototype. There was no confusion about the CTA, and lined up well with existing Uber branding.
Our logo received an incredible amount of iterations before arriving at our final design. We started with pencil and pad and then upgraded to dozens of digital renditions.
Several pages of logo sketches were created before deciding to embracing a circular logo, similar to Uber Eats. This lead into creating a steering wheel, shown the right with our digital iterations.
We wanted our logo to portray the freedom users have once they rent a car. Our final logo paired well with Uber Eats branding, a successful branch from Uber. Like the charcoal branding on the CTA, we kept along the lines of Uber Eats styling and kept the logo circular and cohesive.
Our final logo aligning with existing circular branding with a steering wheel, kept simple to scale down effectively
The finished product!
This is where the task flow first began. The user must first determine their pickup and drop-off time. Without these dates entered initially, the app would populate irrelevant cars. The scrollable date and time for pickup and drop off tested best among iPhone users since it was a reliable iOS design pattern.

The filter page shows the pickup and drop-off time at the top to ensure transparency. You’re able to rent cars for a few hours or days from Uber, so that pricing shows hours and days. You’re able to select multiple categories, or none at all.
Left: The very first screen in the booking process with scrollable date and time. Middle: The filtering page with iconography that transfers to the map view. This page can be skipped if the user wants to see all types of cars available. Right: An example of an expanded location with a dialog box. Tap outside of the box to exit the quick view
This is where the task flow first began. The user must first determine their pickup and drop-off time. Without these dates entered initially, the app would populate irrelevant cars. The scrollable date and time for pickup and drop off tested best among iPhone users since it was a reliable iOS design pattern.

The filter page shows the pickup and drop-off time at the top to ensure transparency. You’re able to rent cars for a few hours or days from Uber, so that pricing shows hours and days. You’re able to select multiple categories, or none at all.

After the filter page, the user will be taken into the map/list view. The map view utilizes the current location as a default to populate car closest to the user. When a user taps a location, a quick dialog box shows pertinent information. This is especially helpful for users that may be in slow speed areas, allowing users to view information without needing to leave the page or use excessive data and/or time. From this dialog box, users can start the reservation process or add the car to favorites. At any time, users are also able to search for a car or city to see various vehicle locations or specific car types.
Left: The list view presents cars within the closest proximity to the user. Middle: The reserve page shows the total aggregation of information for final purchase. Right: The confirmation page provides all information, plus an unlock code. This allows to access the car if their reservation isn’t readily available. Users can also add this car to favorites.
The list view is a scrollable page for those who wish to compare multiple cars at once. This view was the preferred method with a little under half of our users. The list view will arrange cars by their closest proximity to the user by default. It will also consider search or filter parameters. Users are able add a car to favorites from here at any time.

The reserve page is the total accumulation of information presented to the user before they book the car. Default will be the last card used, but users also have the option to change the payment here. For first time users, information will be prompted to enter it here. The location button will link to an external mapping service after asking permission to navigate away from the app.

Lastly, the confirmation page comes after the payment has been confirmed. This screen explains all the information once again from the previous page. Reservations will exist in the home tab in the navigation. The app will remind a user of an upcoming trip, but they can also add them directly into their preferred calendar app with the add to calendar button.
Future considerations
We were very pleased with the final product and we feel it embodied our foundation and vision exceptionally well. These four packed sprints left a couple of items I would love to explore further:

Our UX could have benefited from an additional round of testing after our first converged wireframe. Due to the time constraint, we immediately began applying our visual language from UX to UI.

The UI testing for our hi-fidelity prototype could have benefited from additional testing as well - such as the CTA color.

We focused on pulling directly from our test results, so we felt confident as a group with our final wireframes. Our time had elapsed, but we felt our current prototype was a great final product regardless.
Final thoughts
This mock project was important step into the next phase of my career — working with live clients. I felt substantially more confident in the process of design thinking — the cycle of brainstorming concept ideas, testing with users, and ideating again. I enjoyed creating clean prototypes with Axure and Sketch, and transferring them into InVision. I loved seeing how and why people reacted to designs our group created. I also learned a lot more group dynamics by working together everyday producing the best product possible.

This project began to informed me what I want out of a career, both UX and UI — a multidisciplinary approach. I really enjoyed seeing the whole project through. It gave me a huge sense of accomplishment and satisfaction, and I transferred that feeling to my next projects.

You may also like

Back to Top