As a student at DESIGNATION, I participated in an exploratory design challenge to design a mobile carsharing app for Uber. The final product had to be an exclusively digital platform from which the user could easily join, reserve, find, and return vehicles. The challenge consisted of 4 design sprints spread across an equal number of weeks.





Competitive analysis

Presented with very few constraints, my team and I needed a way to wrap our heads around the problem we were solving and the basic structure of our emergent solution. To do this, we performed a competitive analysis aimed at understanding the carsharing market. Our goal here was to surface a competitive advantage over other carsharing apps. In total we looked at 12 competitors in car sharing market.

We noticed that there were far fewer P2P carsharing services than fleet-based B2P services. We were curious if this void existed because people were not interested, but we found that P2P carsharing companies were experiencing rapid growth in Chicago and across the country. It was also clear that the majority of P2P carshares were geared towards a more affluent customer base.

Based on these observations, our competitive advantage was to offer users an extremely affordable P2P carsharing service. Eager to explore the viability of the opportunity uncovered in our competitive analysis, we looked to the users themselves.


User interviews

The design brief identified our target users as millennials. We conducted 12 interviews aimed at understanding our target users’ attitudes towards car sharing and goals for getting around. Our interviews also focused on surfacing barriers that might prevent these individuals from participating in P2P carsharing.

As we began synthesizing our findings, several potential values and barriers related to carsharing surfaced:

Through a short post-interview questionnaire, we were able to verify and quantify several trends in our users:

From this research, it was clear that our target users were price-conscious individuals who needed a great deal of reassurance to feel comfortable using a P2P carsharing service. We debated pivoting away from P2P towards B2P, something more similar to Zipcar, because we knew much of users' discomfort stemmed from using another person’s car. However, the value users placed on affordability seemed much stronger than their wariness of P2P carsharing. We decided not to rule out P2P just yet.

To get a more concrete sense of users’ needs, wants, motivations, and frustrations we took the insights from our interviews and developed them into a primary persona.



After creating our persona, the next step was defining the problem we were going to tackle.


Defining the problem

Our user research suggested that P2P could be a cost-effective alternative to fleet-based carsharing platforms such as Zipcar but existing P2P services failed to create a comfortable experience for users worried about their personal safety. Given that the majority of users usually drove with their friends, these services also failed to leverage the social aspect of carsharing. We needed to create a friendly P2P carshare experience for our users by leveraging their existing networks. We defined these issues collectively in the following problem statement:

We also developed a set of principles to steer our designs and structure our decisions as we moved forward.


On demand

Focus on the user's command: get a car when you want it, where you want it, with the click of a button.


Assure the user with feedback every step of the way. 


 Assure the user with feedback every step of the way.


Despite being digital, the platform still feels like a community.


Our design principles were put to the test as we began ideating solutions to the design gap defined in our problem statement.


Ideating the solution(s)

At this point I knew that the majority of our users were like Rachel: highly concerned with keeping costs low and reluctant to participate in car sharing because they felt it was expensive.

From our user interviews, I also knew that 67% of users surveyed said they would chauffeur someone in the car they were renting to reduce the cost. Furthermore, a whopping 75% of our interviewees used Uber Pool and felt comfortable enough to get into a car with a stranger.

I began to wonder how users would respond to a carsharing app that paid them to chauffeur an Uber customer in their area who had requested a ride. Would our users be interested in assuming the role of an Uber driver to reduce their fare, and would this discount be enough of an incentive to overcome the barriers preventing them from using carsharing?

In preliminary sketching exercises, I explored the idea of pairing users with an Uber customer in their area headed in the same direction. The user could choose to chauffeur this person in the car they were renting and split the fare. Alternatively, they could continue on without picking up an Uber customer and pay full price.

Each member of my team presented several ideas to the group. We took a vote on which idea to pursue and my concept was selected. The next step was to test its viability with users in concept testing using low-fidelity paper prototypes.


Concept testing

In concept testing we presented users with two major concepts:

Concept 1:  My Uber Pool inspired concept where users were given the option to chauffeur an Uber customer headed in the same direction for a 50% reduced fare.

Concept 2: A purposeful deviation from my original idea that gave users the option to add a friend rather than a stranger to the car and split the fare with that trusted friend. This concept was more in line with our problem statement, which sought to leverage users’ existing social networks.


Only one user said they would use the feature that allowed them to add a stranger to their ride because they were concerned about their personal safety. Given Uber Pool’s success and popularity with our users, I was surprised to find that our users were intensely wary of sharing a car with a stranger. It became clear to me that what’s right for the market is not necessarily what’s right for the user.

Thankfully, users responded positively to the “add a friend” concept. All users identified the split fare feature as the most valuable feature presented. Because users were so resistant to the idea of sharing a car with someone they didn’t know, we chose to move forward with a mid-fidelity prototype of Concept 2 instead.


Mid-fidelity prototyping

Assured that users had validated our second concept, we moved on to mid-fidelity prototyping in Axure. Each member of the team created a mid-fidelity Axure prototype consisting of the flow from booking a car through adding friends. The goal of this prototype was to create a layout with limited functionality that clearly communicated the app’s purpose and intended functionality. Click on the image below to view my mid-fidelity Axure prototype.

Click the image above to view my  mid-fidelity prototype .

Click the image above to view my mid-fidelity prototype.


Mid-fidelity usability testing

After building out four mid-fi prototypes in Axure that varied slightly in terms of flow, iconography, and messaging, we performed a quick round of usability testing with a random sample of 7 users between the ages of 18-35. There were several key findings from this round of testing:


Car Specifications: Many users reported wanting to know more information about car specifications ranging from vehicle mpg, to how much storage space and passengers vehicle can hold, to whether or not rental includes a car seat.


Car Owner Information: Many participants cited that they felt comforted and secure, knowing a bit about the owner in the form of a picture, ability to message owner, or confirmation note at the end of the booking process.


These results showed that we still had grounds to cover in terms of making users feel comfortable when using our app. We realized that much of the uneasiness people feel about renting a stranger’s car stems from a lack of knowledge about the car they are getting into and lack of transparency around who they were renting the car from. We tackled these issues in our next iteration: a high-fidelity prototype built using Sketch and InVision.


Hi-fi prototyping

In our hi-fi prototypes, we let users choose specific features including car make, model, and year and gave them the ability to ask questions directly to the car’s owner.

Our initial designs paired users with the closest available vehicle. In our hi-fi prototype (right) we gave them a detailed filter system that allowed them to search for specific car types and features:


Our hi-fi prototype also gave user the ability to message owners directly so that they would be able to ask specific questions about the vehicle they were renting.

Car view.png

To settle on a final visual design, we each developed a unique user interface design and applied it to the screens of our hi-fidelity prototype. In total we had four versions of our high-fidelity prototype, each varying only in terms of the user interface design. View my hi-fi prototype below:

We performed a final round of usability testing with a random sample of seven people aged 19 to 35. We asked users to identify their preferred interface design. Users ultimately chose the design was the most familiar to them. Users liked that it felt on-brand with Uber.

Users validated all of the updates we had made in our high-fi screens, but identified a few features that they wanted to be included in the app. These included:

  • Ability to extend and/or cancel trip time

  • System for unlocking and locking car

  • Process for locating car once it is booked


Final prototype

We incorporated these additional flows to our final prototype. We also added the interface design we identified as the most desirable in the last round of user testing.

User testing with our high-fidelity prototype surfaced several areas for future consideration that we were not able to address in our final prototype. These areas for consideration included:

  • Ability to “favorite” cars and past trips

  • Option to split fares manually

  • Integration with Google Maps, PayPal, and Venmo

  • Owner-side experience and interface

  • Payment approval process

We were not able to make these changes within the remaining timeframe, but they gave us a solid understanding of how the app might develop in the future.


What I learned

Behavioral and attitudinal needs

This project taught me the importance of listening to users’ unstated needs rather relying on their stated preferences. In our initial user interviews, we asked users whether they would be willing to chauffeur a stranger if it meant their fare would be reduced by half. While asking this question was itself not a mistake, assuming the response was an accurate representation of users’ actual behavior was. I relied heavily on this assumption in the ideation phase and underestimated many of the unstated barriers we saw deeply embedded in our user interviews. As a result, I produced a concept that addressed one user need at the expense of another - as well as a pretty resounding “No!” from our users. My role as a designer is to understand the user’s implicit needs and not rely purely on what say out loud.


What’s right for the market vs what’s right for the user

Along similar lines, I also saw firsthand how something that is successful in the market as whole might actually be really wrong for the user. In the ideation phase, I was transfixed by Uber Pool’s success and popularity with our target audience. I wanted to how the Uber Pool model could be successfully applied in a P2P car sharing application, but I really should have been asking whether this was the best way to address their needs.

This project underscored the importance of finding product/market fit. There is rarely a panacea that can be applied across industries, and focusing on the wrong information to gauge that fit can sabotage the user and their needs.