CarryOn - travel with friends

A mobile application designed to ease the process of planning trips with a group.

About the Project

My Role: UX/UI Designer
Duration: 1 month
Tools: Adobe XD, Miro

This project was completed as part of the Georgia Tech UX/UI Design Bootcamp. The directive for this project was to discover a major pain point for users in their travel-planning process and to design a mobile app that addresses that problem. In order to narrow the scope of the project, my partner and I decided to tailor the research to specifically users planning trips within a group. We hypothesized that people would face specific challenges when planning a trip with other people, and these challenges would motivate the design of our app. For our interviews, we chose to target users that travel regularly, as we believed they would have more insight into the travel-planning process. For my final solution, I designed a mobile app that would help users make group decisions and keep track of their shared trip information. Constraints on this project included a 1 month timeline and no budget for user research.

Conducting Research

My research partner and I conducted 5 user interviews and a survey. We asked participants about their travel habits, their general travel-planning process, and specifically how they tackle planning a trip with a group of people.

Figure 1: Facts learned from interviews and survey before being grouped.

Figure 2: Affinity diagram from survey and interview data with point-of-view statements for each grouping.

We recorded the facts we learned from both research methods and sorted them based on what they communicated about each user’s traveling experience. We were then able to write point-of-view statements for each group that captured the overall sentiment of the responses. The following statements were most influential in motivating our design decisions because they expressed a planning-related problem and emphasized that users depend on their mobile phones during travel.

Figure 3: Critical point-of-view statements.

Defining the Problem

The most commonly cited frustration for planning a trip was coordinating plans, agreements, timelines, and payments between a group of travelers. Some users even said they avoided traveling with more than 1 person because they cannot handle the frustration of keeping many people on the same page. At the same time, a majority of users did not want to travel alone, making planning with family or friends a necessity. These combined factors led us to conclude that clear and comfortable communication with travel partners is what our participants desired, and we decided this was the problem we would address in our app design.

Settling on Solutions

At this point, my partner and I followed our own design paths as these were the project instructions, so the rest of this design process was completed on my own. I decided that my best approach was to design an app that systematized good communication. I wanted users to:

• Feel heard and appreciated by their travel partners

• Be able to easily compromise on matters of preference and taste

• Feel less anxious about planning and traveling with other people

I brainstormed on many feature options, and eventually chose to create a planning app that incorporated a voting feature attached to a messaging system for making travel decisions. This was intended to give all members of a group a voice when deciding what to do on their trip. The app would also contain an expense report and a trip itinerary that was derived from the group’s decisions, so that users would feel they had a coherent and organized plan for the whole group to view. I felt the combination of these two features had the potential to smooth the group planning process in a peaceful and systematic manner. To help verify the logic behind my feature choices, I created a user journey map detailing how I imagined this app would fit into a user’s real world scenario.

Figure 4: User Journey Map for persona Sophia planning a trip to Costa Rica with some friends.

Implementing the Ideas

I went through a few iterations of sketching wireframes and created a user flow for the app before moving to digital wireframes. This helped me make sure I had my ideas fleshed out before building an initial prototype. I then created a digital wireframe and tested basic tasks like onboarding, sending a message to a group chat, and making a suggestion to the group. This first round of testing also confirmed that the use of icons was meaningful and helpful to users.

Figure 5: User Flow for the CarryOn app.

Figure 6: Wireframe flow of the mid-fidelity prototype.

I then created a more extensive mid-fidelity prototype and tested more subtle tasks such as adding a suggestion to their itinerary and checking their budget for the trip. Because of testing feedback I chose to shorten the onboarding process, keep the main navigation on all screens, and rethink the navigation to the suggestion feature.

Figure 7: Edits made between mid-fidelity and high-fidelity prototypes.

Branding & Style

After testing the layout of the app I iterated a couple more times to implement a better visual aesthetic and bring the prototype to high fidelity. I chose a simple color scheme of whites and blues in an effort to keep the app looking organized and calm. I also added additional iconography to form fields and revised the UX writing for clarity.

Future Steps & Lessons Learned

Next steps for the app would be to more stringently test how the app handles the relationship between group decisions and adding events to the itinerary or the expense report. In future iterations the app could include a more thorough budgeting system, as well as the ability to add events to your itinerary directly from email confirmations.

This was my first time independently designing a mobile app, so I learned countless things along the way. Below are a couple of my favorite lessons.

• The words you choose in your instructions to people during user testing are their own mini UX design challenge. Choose those words wisely.

• Give yourself lots of time to think. What is in your flows and wireframes should be documentation of a lot of thinking. If you jump right into wire framing you will end up with half-baked ideas.