Atlas: Self Booking Travel App
Project Overview
Atlas was created to give travel enthusiasts the most personalized route to book a multi-faceted trip whether for work or play. This is accomplished by various user routes giving freedom to book flights, hotels, activities, and rental cars all in one swoop or separately with the encouragement of Atlas Cash rewards.
Our main goals were to design an app to meet user’s travel booking needs with efficiency and ease while, learning and exploring the abilities of research, wire framing, prototyping, and usability testing.
Details
Role: Interactive Design Team Member (Group of 4)
Duration: 9 Weeks
Approach: Goal Directed Design (GDD)
Tools: Figma, FigJam, Discord, Adobe Creative Suite
Introduction
This Atlas travel app was created for Interactive Design I, a course at Kennesaw State University. I was very intrigued by the idea of this project because at the time, in January, I was looking for plans for my Spring Break which was in March. I’m definitely the planner out of all of my friends so, coming up with a location, itinerary, everything boils down to me. I knew we all wanted to go somewhere other than the beaches in Florida but I didn’t have a specific spot in mind but I knew we were all on a budget. I had to do several hours of research through Google, Expedia, cruise sites, and the whole nine yards. So, when Atlas, a personalized travel booking experience, was introduced, I knew I wanted to be on the team.
For the purpose of this class, we were directed to create this app with an adapted version of GDD. This approach had to be adapted due to the crunch of time and the student experience (like how we never actually had stakeholders so please, keep that in mind). In the following sections, I will explain the process of GDD and how Atlas came together.
Method
Atlas was created with Goal-Directed Design as its guiding method. GDD was created by Alan Cooper and used at the Cooper Design Agency. This method is focused on “design of behavior” meaning we start with a stakeholder meeting to set expectations and ends with a user-achievement-based design.
For this course, we adapted the GDD process to include research, modeling, requirements, framework, and refinement. A further explanation of each phase as well as what my team completed during each phase can be found below.
Research Phase
In this phase, my team and I conducted a kick-off meeting, literature review, competitive audit, Stakeholder interviews, and user interviews. This research phase was vital to our success so my team and I could better understand our scope, what else is already out there, what people want, and why they want it. Without this phase, we would’ve been blindly designing what we thought would be best rather than keeping the users in mind.
This whole process was research into how different individuals travel covering what type of traveling they do most often, how they plan their budget, the process of finding their next destination, and what types of activities/experiences they look for.
Kick-Off Meeting
The goal of the Kick-off meeting was to get everyone on the team focused on the same scope and goals. We collectively developed a problem statement as well as assumption statements. We focused on how we could best tailor our app to the intended target audience, travel advocates and business travelers that are traveling on a budget and need convenience in the planning process. We came to the conclusion that Atlas needs to assist users with budget, time, and destination interchangeably.
The literature review set the foundation for our research. We started with articles based on the subconscious aspects of why individuals feel called to travel, various types of travel, the elements of travel planning, and the differentiating views on travel between generations.
Though we learned several different aspects of the psychology behind traveling we need on a few goals we wanted to keep in mind for Atlas. Our goals became based on the user’s drive for travel which includes variables like the age range of the traveler, what they want out of travel, their intended destination, when peak travel times are, and how much travel time they have. Whether the user is older, younger, richer, poorer, has a family, is traveling for leisure, or is traveling for business, our team’s goal was to create an app that is usable for all parties.
Literature Review
Competitive Audit
The competitive audit was my main effort in this research process. As a team, we found various travel apps and conducted a small version of a heuristic evaluation on those most like our intended goal. We found many successful attributes and features throughout each app and took inspiration yet, in those same apps we found many faults that could radically affect a user’s experience or travel plans. We investigated apps including Airbnb, Kayak, Hopper, Vrbo, and did lighter research on Expedia, All Trails, HipCamp, and Naver.
In our auditing process of Airbnb, Kayak, Hopper, and Vrbo, we came to many conclusions. We found that for our app to be successful, it needed to encompass all aspects of travel: flights, rental cars, stays, and activities. We also realized all of these apps have one user route that always begins with the destination followed by dates and ends on budget. At this time in our design process, we collectively decided to work only with legitimate hotels rather than with personal homes like Vrbo and Airbnb.
We also researched Expedia, All Trails, HipCamp, and Naver to explore other aspects of travel apps. All Trails and HipCamp are more for hiking and camping but gave great insight into the map features we wanted to include. Naver is a map app for things to do and must-see spots in Korea.
After completing the competitive audit portion of the research phase we specified our goals and must-haves for Atlas.
These goals include:
the search process needs to have multiple start routes
the filter and sort options are necessary for user success
user’s convenience relies on being able to book stays,
flights, rental cars, and activities all in one app
Stakeholder Interviews
In our adaptation of GDD, stakeholder interviews were a big change. A stakeholder meeting would be held to conduct interviews with stakeholders who would give input to the product being created. These stakeholders set the stage for what kind of product needs to be created and how to create it. In our case, and for the course, there are no real stakeholders involved. We instead ran the kick-off meeting and created an outline of what we thought stakeholders might desire.
We, as a team, imagined the perspective of a stakeholder. We created the mindset that stakeholders want the app the viable and applicable to a wide range of travelers with no limits to age, budget, location, or type of travel. Atlas would need to be usable to a variety of users for it to be worthwhile. A key part of this process was taking our stakeholder mindset and the hypothetical stakeholder goals and comparing them with potential user goals learned in the next phase of user interviews.
User Interviews
This part of the research process was absolutely vital to our team and Atlas’ success. Each member of our team identified a person who likes to travel, travels often or has traveled recently. These interviewees gave us an understanding of how they plan their trips, how they budget for travel, their previous experiences with travel apps, their travel app wants and needs, and their viewpoint on traveling in general.
We conducted five interviews of people who travel often or have traveled recently all ranging in age, reason for travel, and a variety of different financial standpoints. Throughout the interviews, we met with a college student who camps across the United States, a freelance travel photographer, a college student who recently to Korea to visit family, and a middle-aged father that travels for business mainly and leisure occasionally.
Overall, several key findings including:
Budget is not only relevant but important to all travelers no matter their financial standing
People favor convenience, all interviewees mentioned to tediousness and struggle of researching
A filter option to limit the search options is favored
Some users don’t necessarily have a destination in mind but more so of an urge to travel to any destination
Time heirs on the more important side for leisure travelers and business travelers alike
Modeling Phase
The modeling phase was where we took our previous research of users and sought out patterns, goals, and ended up with a more hands-on representation of our research and reasoning. We did this by creating personas, which were originally created by Alan Cooper, the creator of GDD, and used for various other design methods. To better explain, a persona is a fictional character based on research patterns to represent different user types. Personas are used to help better understand a user’s needs, goals, behaviors, and preferences.
For background, we have created two personas: a primary and a secondary. The primary persona represents dominant patterns seen during user research while the secondary displays residual patterns that still hold impact. Most often while satisfying the needs of the primary persona, many of the secondary needs are fulfilled without harm to the primary as well.
We introduced to you, Marvin White and Madeline Lowe.
Marvin White is our primary persona, he exhibits a love and passion for travel. He cares mostly for unique experiences and wants to make as many memories as possible. Madeline is our secondary persona, she exemplifies a user focused on work-life balance. She wants to balance traveling for work with traveling for leisure.
The question now is how did we synthesize five interviews into two representative made-up people? These personas are not simply creations of what we think a user would be like. To better explain we broke down all of our user interview information and webbed them together in a scaling environment.
To begin, our team identified behavioral variables we witnessed during interviews, these variables ranged from interviewee thoughts, actions, wants, attitudes, motivations, and abilities. We then are directed by GDD to map the interview participants on the previously created behavioral variables. This map acts as a scale visual continuum.
Identifying Behavioral Patterns
After placing the interviewees on the continuums, we looked for clusters that would represent dominant patterns. This brought to light the differences and similarities between our interviewees. With this, we noticed interviews 4 and 5 more often than not measured similarly as well as interviews 3 and 1. We used these two pairs to organize pattern clusters by color.
Defining User Goals
Then we defined persona goals and characteristics. We broke down the continuum into bullet points to describe the characteristics of the behaviors. For the primary persona, who represents the behaviors of interviewees 1 and 3 is now called Marvin White. He represents the “leisure travelers”, who “travel often” with “shorter planning time”, and is “looking for the most unique trips”. Madeline Lowe is representative of interviewees 4 and 5 as the secondary personas. She “travels primarily for business”, “travels leisurely once a year”, and is “very organized in planning and budgeting”.
We then took what these users want to do and created 3 end goals for each persona. Then we took who these users want to be and created one life goal for each persona. We based these goals off of Marvin’s and Madeline’s lists of behaviors and descriptions.
With these goals in mind, we created a short narrative description of Marvin and Madeline to implement a backstory to who they are.
Requirements Phase
In this phase, we focused n defining what is required in the app to help the personas achieve their goals. It is important to note that requirements are not supposed to be features rather they are the functional needs of personas turned into qualities of the future product. All of these requirements are created by first putting the personas into a context scenario of them using the app for a certain purpose and then extracting functions or expectations in the form of requirements.
Defining Product Vision
In Goal-Directed Design, we are starting with problem statements and vision statements based on user goals and user frustrations. In this phase, it is important to note the difference between a problem statement and a vision statement. A problem statement implements the stakeholder or business goal. A vision statement is the user goal that creates a design objective.
Our team then envisioned Atlas. We brainstormed the potential creation and qualities of Atlas. Then, we identified persona expectations. It is dire that the design aligns with user mental models or it will create challenges for users to achieve their goals. These persona expectations are built from the persona narratives, user attitudes, and experiences. This process posed a challenge for us because its hypothetical since the app has not been created yet.
Creating Context Scenarios
We then put together, a context scenario, which is a narrative that highlights the primary touch points that the personas have in Atlas. This narrative is told from the persona's perspective and focuses on high-level interactions within the app. The team and I imagined a hypothetical day in the life of the persona Marvin and how he might use Atlas to plan an upcoming trip.
Using this scenario, we finally identified the requirements for Atlas. We list these requirements in a certain sequence laid out by Alan Cooper where it begins with a base sentence of “call a person directly from an appointment”. In this sentence call is replaced with any action, a person is replaced with the object, and directly from an appointment simply describes the context.
It is important to remember although we are focused on the user goals in GDD, we note that these goals exist in tandem with business goals. We also list the requirements business, brand, and technical requirements. This gives us a list of what needs to be built for our next phase.
Frameworks Phase
The frameworks phase of GDD is a personal favorite. The main goal of this phase is to lay out a baseline of low-fidelity wireframes and then build on them to create high-fidelity versions. Wireframes are the basic structural layout of an application focusing on the behaviors of each page, the flow from page to page, and the organization of those pages. These wireframes are highly impactful to the success of a designer because they act as design guides for the high-fidelity frames.
Low Fidelity
In GDD, we create wireframes by creating Key Path and Validation Scenarios. To further explain, a Key Path Scenario is task-oriented paving out the most well-worn or used path the primary persona will take through the app while, a Validation Scenario highlights the screens that are less frequently used but may satisfy the needs of the secondary persona without harming the experience of the primary persona.
To begin this process, we slowly but surely begin adding requirements in the wireframe and cross them off the list. As a team, we focused on what the primary persona would use most and where they would ideally end and begin. This process took us several tries and reiterations to organize and complete. We first built until we thought we had completed the Key Path Scenario and satisfied Marvin’s needs.
Moving to the Validation Scenarios, we added the needs of Madeline, the secondary persona, while keeping the needs of Marvin prioritized. This means before creating anything we discussed if including a screen or feature for Madeline would harm the experience for Marvin. In most cases, the answer was no so, we ended up with one Key Path Scenario and several Validation Scenarios to complete the wireframe.
High Fidelity
We then shift from FigJam to Figma to create a high-fidelity prototype. Michelle, our team leader, laid out containers holding pages of who would create what. I was in charge of creating the Flights, Car Rentals, Stays, and Activities routes as well as the Trips and Rewards pages.
This prototype had many overlapping variables, the listings I created were often used in several other parts of the app while certain components like the favorite button (or heart button) were used practically on every page. This posed a bit of a challenge due to the fact that all four team members live and work on different schedules and have different allotted times to work. Often, we would be missing functions on one page waiting for another page to be completed to implement consistency. We chose to combine and correct these blanks and issues in the refinement phase.
Refinement Phase
During this phase, we touch up anything and everything in the interface. This included behaviors, information architecture, widgets, components, consistency, and pretty much everything related to the interface. The evidence for these adjustments and refinements came from usability testing and from our design perspective.
Usability Testing
We went back to three of our previous interviewees from the research phase to conduct walk-through tests. These tests consisted of the interviewee explaining that the test is not of their own intelligence but more of the app’s efficiency and the basics of how to walk or click through Figma. We then asked these participants to complete a task in-app and judge based on their success and their feedback.
Most of the feedback received was positive. The few changes we made were for usability and consistency. This included resizing several clickable icons, adjusting spacing, and rerouting flows. The interviewees were prepped with the knowledge that the app was still ‘in the works’ meaning it was intentionally not yet complete. With these interviews, we corrected based on feedback and completed the missing portions of Atlas.
Retrospective
I’ve worked on various projects comparable to this but, Atlas was my first school scale group project. Many aspects are constantly being intertwined between prioritizing user and business goals while trying to appease all parties. I feel as though I gained crucial experience working on this project with the group I had. We collectively experienced many challenges and successes. Although the ‘Final’ product is not perfect, I think it was a sufficient and effective outcome that I’m pleased with. I note in this that work really never is done with the ever-growing digital world. With that being said there are some things I’d love to reiterate in the future.
If I had more time…
Implement various start routes that don’t necessarily begin with dates
Build out confirmation pages and steps of confirmation pages
Spend more time exploring visual design
Further develop the trips page
price slider is not the most usable, I think in an iteration we could add a price minimum and price maximum text slot for users to just type in rather than slide if they preferred.
I think our after-delay timing and transitions are successful but small adjustments could be made to make it more smooth.