Many college students drive home for school breaks and holidays. Driving is often cheaper than other forms of transportation (flying, taking the train, etc), especially for students who carpool. While many ride sharing apps and platforms exist, they are not used by college students. We wanted to fill this gap and create a platform that facilitated carpooling and college students would use.
Product Design Course Project
User Needs & Requirements
User Research Report
Usability Testing Report
High Fidelity Prototype
Research & Ideation
College students know that carpooling to get home during breaks and holidays is cheaper both for passengers and drivers. The current method of facilitating this carpooling is posting in college Facebook groups. This posting process and the communication that follows is tedious and can be stressful for students trying to ensure they can get home.
Preliminary User Research
When we began the project, we started by conducting preliminary interviews and sending out a questionnaire to Tufts University students. During this initial user research process, we were looking to understand the pain point that currently exist in the carpooling process and what expectations users would have in an app that facilitated the carpooling. We were also interested in current travel habits and concerns students have about carpooling.
The questionnaire totaled 34 responses and we interviewed 10 students who had carpooled before. We found that while 76.5% of participants have never carpooled from college before, 73.5% of participants would use a carpooling app if made available. Several themes were repeated as students talked about features and expectations:
Students did not want to figure out how to estimate and split gas - they wanted it to be included in the app
User profiles (name, school, picture) would ease many students’ concerns about driving with a stranger
Drivers wanted to be able to post trips and connect with searching riders
Several students expressed interest in seeing mutual connections they have with riders and drivers
In-app messaging function
“I would love a way to contact riders without having to add them on social media”
“I don’t want it to feel like I’m driving for Uber”
“I want us to be able to decide the music ahead of time”
User Needs & Requirements
We used our findings from the preliminary research to create a list of 10 user needs:
User needs to be able to plan trips in advance.
User needs to have the ability to decide whether they want to share a trip with another user.
User needs the app service to deliver a cheaper travel expense.
User needs to have a personalized approach to the app.
User needs to feel safe throughout the entire booking process and trip
User needs to feel a community value and atmosphere from the app.
Users needs to be able to contact other users easily.
All potential user types (riding only, driving only, and both) need to find the app functional and useful.
All users need to find the app accessible.
All users need to find the app usable and easy to navigate.
After defining the user needs, we also created 20 user requirements and a problem statement to refer back to as we began designing the app.
Problem statement: College students need an easier, more cost-appropriate, and more efficient way to organize domestic traveling.
We started designing by creating the user flow. We determined that the app’s functionality could be split into four sections:
Searching for a ride
Creating and managing the user’s trips
The user’s profile
Once we had an idea of the navigational structure and content organization, we mapped out the user flow.
Request Ride Flow
Navigation and Post Ride Flow
Low Fidelity Design
Once we had our flow and some preliminary screens sketched out, we created the low fidelity prototype. We chose to use Balsamiq for our low fidelity prototype so we could focus on the information architecture across the pages. This also helped in the first round of testing, where we were aiming to receive feedback on the functions, rather than the visual style.
Our next step after designing our low fidelity prototype was to test it. We conducted usability testing with 10 participants. During the testing, we were primarily looking to understand whether users understood the functionality and information architecture of the app. We asked users to go through two scenarios.
Usability Testing Scenarios (Round 1)
Please post a trip in your own car from Boston to New York City using this scenario:
You’re driving back to New York after school ends to visit your parents and friends from home before starting your summer internship at the Boston Museum of Science. Since you’re already moved in for the summer, you don’t have much luggage and want to sell the 3 extra seats in your car.
[After the participant posts the trip]
Okay now let’s say a few days have passed and you want to check on the number of confirmed and potential passengers for your Boston to NYC trip. How would you do that?
Please book a seat in a car from Boston to Providence using this scenario:
You are traveling with a friend to Providence on May 11th to celebrate the end of finals. Since you’re already having to pay for your Airbnb, you want to keep the price as cheap as possible. You’re also concerned about making the 1.5 hour drive early enough to make your 12:30pm lunch reservation at Sydney Providence in downtown Providence (400 Exchange St, Providence, RI) and would prefer to be dropped off nearby. Your music preferences are flexible, as long as the driver doesn’t play any country!
Overall, participants responded positively to the app. We found that users primarily struggled with some of the language used and wanted more explanation on certain screens.
Usability Testing Findings
Users did not know whether they would leave at the time listed on the ride or arrive at their end point by the time listed.
Participants were unsure whether the person was driving or riding in the listed upcoming trips
Participants did not understand what "Mutual Connections" meant
Participants did not understand whose location they were supposed to input (theirs or the rider's) and they were confused about what the function of the radius was.
High Fidelity Design
As we moved to the high fidelity prototype, we addressed many of the issues we discovered during the usability testing. For example, we specified “My Address” under drop-off and pick-up locations when users were posting rides to clarify which address they should input. We also changed the drop-off and pick-up radius to “Maximum pick-up distance” for clarification. We also added further clarifying language around the app, such as specifying that departure times in the search page were, in fact, departure times.
After designing the high fidelity prototype, we conducted a second round of usability testing, this time focusing on the visual style and interaction patterns in the app. We were also looking to evaluate whether our changes to address the issues found in the first round of testing were successful. We used similar prompts for the second round of testing, but instead of asking users to walk through a scenario, we asked them directed questions about each screen.
Usability Testing Scenarios (Round 2)
[start on the search screen] You are searching for a ride to go from Boston to Providence.
After filling out the text/date boxes, what would you do next?
How many seats in Caleb Little’s ride are available?
If you wanted to see the details of Caleb Little’s ride, how would you go about that?
If you wanted to view Caleb Little’s profile, how would you do that?
Can you briefly explain each item on this screen to me?
Request a seat in Caleb Little’s car
Assuming the text boxes were filled out, submit your request.
[start on the my trips screen] You’re driving back to New York after school ends to visit your parents and friends from home. You posted your trip on the app to rent out the 3 available seats.
Looking at your Boston to New York trip can you briefly explain…
Each item on this screen to me?
How many seats have been rented out?
Francis Barnes has requested to rent a seat in your car, take the necessary steps to confirm her seat.
The second round of testing confirmed that our changes after the first round of testing solved many of the issues we found initially. Our largest issue in the second round of testing was that users did not understand all the icons and indicators.
Usability Testing Findings
Participants felt “Popular Trips” cluttered the app, since they might not be going to those destinations.
Participants were unsure of whether 1 seat had been filled or 1 seat was still open.
Participants were unclear why some badges were blue and some badges were gold.
Branding & Visual Style
We wanted the app to be fun and playful to keep it from feeling transactional or like a job. We also aimed to give the app a modern, simplistic style because we were presenting a fair amount of information. To achieve this, we used mostly white, gray, and black for the app components, but added some orange as an accent. To add to the playful feeling, we renamed the app from Füber (our working name) to Karpuul.
We created our mascot, Jeffrey the octopus, to add some delight into the app. We used him sparingly on screens with little information (such as the loading screen and server error states) to surprise users, without taking away from the important content.
We were able to iterate on the app one more time after the second round of testing. We used this as an opportunity to address the issues found in the second round of testing as well as build out our brand identity more. We changed the seat icon pattern to representing open seats with an outlined profile, while a taken seat is then a shaded profile. The gold and blue badges were meant to represent different badge categories, but we felt the different categories did not hold enough significance to justify users’ confusion. Instead, we changed all badges to blue.
We also dove more into the fun, playful brand identity we were trying to portray. We created illustrations of our mascot, Jeffrey, and added him to several places in the app to create delight.
At the end of the project, we felt we had successfully designed an MVP that college students would use. If given the option to continue iteration on this app, there are several enhancements and research areas we would have liked to explore.
While we gained incredible helpful insights from the usability testing we conducted, we were not able to have users actually use the app to plan a trip. Going forward, it would be interesting to learn if the app’s functions are useful and straightforward when users are actually trying to carpool, not just in a hypothetical situation.
We also received feedback from users that they wanted a GPS feature that would show them the quickest route (particularly if there were multiple passengers being picked up or dropped off from different place). We felt that this feature was out of the scope of our MVP since we only had 6 weeks to work on the project. In future iterations of the app, we think this could be a key feature.
Overall, I am very proud of the project and learned quite a bit. Throughout the project I was primarily working with 1 other designer. Working in a pair on every screen and every feature was something that was very new to me but I really enjoyed the process.