Capstone project — Human Factors in Product Design Course
Karppul was a capstone project for my Human Factors In Product Design course. We were asked to create a product in 6 weeks that solved a problem for a group of users. We chose to focus on college students as our user group because they were fairly accessible to us during our research.
Research & Ideation
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.
Many college students drive home for school breaks and holidays and they know that carpooling to get home is cheaper both for passengers and drivers. While many ride-sharing and carpool-coordinating apps and platforms exist, they are not used by college students. The current method of facilitating this carpooling is posting in college Facebook groups. The posting process and the communication that follows is tedious and can be stressful for students trying to ensure they can get home. We wanted to fill this gap and create a platform that facilitated carpooling specifically for college students.
Preliminary User Research
We began the project by conducting preliminary interviews and sending out a questionnaire to Tufts University students. During the initial research phase, we were looking to understand the pain points that currently exist in the carpooling process and what expectations users would have for an app that facilitates carpooling. We also were interested in current travel habits and concerns students have about carpooling.
We interviewed 10 students and received 34 responses to our questionnaire. We found that while 76.5% of participants had 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
Students wanted an in-app messaging function rather than having to move to another platform for communication
“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
Based on our research findings, we wrote 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 the app to have a personalized approach.
User needs to feel safe throughout the entire booking process and trip
User needs to feel a sense of community within the app.
User needs to be able to contact other users easily.
User needs the app to feel comfortable and casual rather than transactional.
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 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 designed the app.
Problem statement: College students need an easy, cost-appropriate, and efficient way to coordinate long-distance carpooling.
First, we created user flows. We determined the app’s functionality could be split into four sections:
Searching for a ride
Creating and managing the user’s trips
Once we had an idea of the navigational structure and content organization, we mapped out the user flow.
Low Fidelity Designs
Once we had our flow and some preliminary screens sketched out, we created a low fidelity prototype. We chose to use Balsamiq for our 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.
Usability Testing (Round 1)
Our next step after designing the low fidelity prototype was testing. We conducted usability testing with 10 participants who were all college students. 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, one searching for a ride as a rider and one scheduling a ride as a driver.
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.
When searching for rides, users did not know whether the time listed was their departure or arrival time.
When searching for rides, participants were unsure whether the person listed was driving or riding in the listed upcoming trips.
When looking at a user profile, participants did not understand what "Mutual Connections" meant.
When scheduling rides, 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 Designs
As we moved to the high fidelity screens, we addressed 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 added further clarifying language, such as specifying that departure times in the search page were, in fact, departure times.
Usability Testing (round 2)
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 hoping to validate that 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.
The testing confirmed that our changes after the first round solved many of the issues we found initially. We found the largest issue with the high-fidelity screens was that our icons and indicators were not always clear.
On the home screen, participants felt “Popular Trips” cluttered the app, since they might not be going to those destinations.
When looking at an upcoming trip, participants were unsure of which seat icon meant seats were available and which meant seats had been filled.
Participants were unclear why some profile 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 that showed little information (such as the loading screen and server error states) to surprise users, without taking away from the important content.
We iterated on the designs 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, which matches available/unavailable patterns with icons in other popular apps. 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 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 iterating on this app, there are several enhancements and research areas we would have liked to explore.
While we gained 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 actively trying to carpool, not just in a hypothetical testing 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 places). 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.