Enhancing the way users plan their journeys, ensuring each adventure is
as exceptional as the traveler embarking upon it
2 Researchers
2 UX Designers
UX Designer
October to December 2021
Adobe XD
Adobe Illustrator
Photoshop
Miro
Competitive Research
User Research
Usability Testing
Prototyping
Information architecture
AdvaTravel is an iOS mobile app prototype that aims to simplify the trip planning process for families and friends. The app offers personalized trip recommendations based on desired locations and also provides information about events and activities in those areas. Additionally, users can effortlessly add locations or events to their itinerary and share it with their travel companions.
Our team created AdvaTravel as part of a class project for my Interaction Design II course. To develop AdvaTravel, we adopted the Lean UX process which focuses on testing our hypotheses and assumptions to create a better product or service. This approach helped us refine AdvaTravel's features and functionality to better meet the needs of our target users.
Because of the pandemic, our team completed AdvaTravel virtually by leveraging various digital tools to organize and complete our work. We utilized the whiteboarding platform, Miro, to facilitate collaborative work and conducted user interviews and testing sessions over Discord and Zoom.
To ensure that we were not limited by our own personal biases or assumptions, our team conducted interviews with individuals outside of our immediate social and academic circles.
Our team utilized the Lean UX methodology as outlined in Jeff Gothelf and Josh Seiden's book, Lean UX: Designing Great Products with Agile Teams, to guide our approach for AdvaTravel. This method emphasizes the importance of testing assumptions, which are statements of ideas we believe to be true. In Lean UX, user research and testing on the Minimum Viable Product (MVP) are critical components. The goal is to create a hypothesis and test it to evaluate its value for the product.
Our team had limited time and resources due to the nature of the classroom setting, so we were only able to conduct two sprints. A sprint is a designated time frame where the team works on a specific goal to achieve completion. Each sprint is broken down into three weeks of design, lasting two to three weeks each. These sprints are comprised of design zero, design week one, and design week two, which I will elaborate on further below.
To kickstart our project, our team held a Design Zero session where we completed a product problem statement template. This template helped us gain a clear understanding of the stakeholder's business goal and any dominant constraints that would impact the project. Additionally, we compiled individual assumptions on our potential users by writing on sticky notes in Miro. This exercise enabled us to stay on track and align our work with the stakeholder's business goal.
Problem statement
Existing travel apps have largely emphasized itinerary planning, recommendations, social sharing, and luxury travel (with a focus on expensive destinations), but have overlooked the need for comprehensive location recommendations, all-in-one trip planning, and guidance on budget-friendly travel options.
What existing products/services lack is the ability to recommend all travel destinations, facilitate easy sharing of information, provide guidance on where and how to travel.
After defining the project problem statement and compiling individual assumptions, our team proceeded with the assumption template to document our business and user assumptions. This template served as a starting point for identifying problems, proposing solutions, and addressing concerns. Once the template was completed, we developed a hypothesis statement or product backlog, which outlined the features and functionalities of our Minimum Viable Product (MVP) to be tested and validated through user research and testing.
After completing the assumption template, we moved on to creating the hypothesis statement, which outlines our assumptions about the business and user outcomes, as well as the features and proto-persona that form our product backlog. Our team generated eleven hypothesis statements and then prioritized them based on their level of risk and value. The product backlog is a list of all the tasks and features that need to be completed in order to finish the product or service.
At the end of design week zero, we wrapped up by creating our Sprint 1 backlog template. This involved utilizing the assumptions from the product backlog to make informed predictions about the most significant risks or valuable features. The product backlog itself is a compilation of features that we believe the proto-personas would require to accomplish their goals. Upon thorough review of the product backlog, we determined that our app would need to have both recommendation and itinerary features.
Next, we moved on to defining the user and customer segments. At this stage, we created three proto-personas based on the team's collective assumptions about who would use our product. These proto-personas were developed without substantial research or evidence, and they will be subject to change as we gain more knowledge. They are living documents that capture the user's goals and needs, and they will continue to evolve as we conduct further research.
During sprint week 1, we started with two days of stand-up meetings, which are quick, 15-minute meetings for each team member to discuss their goals and expectations for the upcoming work. Initially, we planned to create a comprehensive app that would aid in planning a trip. However, we realized the need to refine our approach and narrowed down the key features to focus on two main features: recommendation and itinerary. We used a mind map to help us streamline our ideas and adjust the problem statement accordingly.
Following our second stand-up meeting during sprint week 1, our team shifted our focus towards creating a wireframe for the recommendation page. This involved collaborating together to create a low-fidelity wireframe, which is an essential step in the design process. By creating a rough visual representation of our ideas, we were able to discuss and iterate on the design until we had a clear and concise plan for the page. I took on several tasks in the wireframe creation process, including developing the filter, recommendation, reviews, itinerary, and adding trips. Our main goal for the wireframe was to emphasize the recommendation feature.
To gain a deeper understanding of our user base, test our assumptions, and evaluate our features, we conducted three user interviews with participants ranging from their early 20s to their early 40s, who have previous travel experience. Each interview session involved a moderator and a facilitator, and I primarily acted as the facilitator during most of the interviews conducted in sprint week 1. Throughout the interviews, we asked questions to explore their past travel experiences, as well as their approach to planning trips. I carefully took notes during each session to capture important insights and feedback that we can use to refine our product.
From the interviews, we learned that our recommendation feature could be a valuable resource for travelers:
During Sprint Week 2, our team continued to hold stand-up meetings every two days to discuss our progress and what needed to be done. We started the prototyping phase for the recommendation feature, using the low-fidelity wireframe we created earlier as a guide. Our team collaborated to develop a more detailed prototype, incorporating feedback from the user interviews we conducted during Sprint Week 1.
During the second part of our user interviews, we designed a case scenario to help us understand the interviewees' trip planning process and test the need for the recommendation feature and its sub-features. As the facilitator, I took notes to capture our findings. Our first interviewee shared her approach to planning a trip, which involved researching and saving multiple tabs for the different aspects of the trip. We gained insights into how our recommendation feature could streamline her process. To test the feature's effectiveness for users with a smaller budget, we created a scenario for our second interviewee. Overall, these interviews were valuable in informing our design process and ensuring that our features align with users' needs and behaviors.
Our second round of interviews revealed some common themes in our interviewees' planning processes. We found that our interviewees frequently save multiple tabs when researching and planning their trips, which can become overwhelming. They expressed a desire for an easier way to store and view their trips, as well as a way to vote on activities and an efficient way to read reviews. These insights will be helpful as we continue to refine our recommendation feature and explore potential sub-features.
In sprint 2, our team continues to conduct our meeting session virtually. The interviews gave our team a better understanding of our persona. We also learned that the recommendation feature still aligns with our assumption based on the data we collected. In sprint 2, our focus was primarily on the itinerary feature.
In design week zero, our team met to discuss our assumptions and revalidate our problem statement, our product backlog, and create our proto-persona round 2 based on the interview and research we collected. Revalidation is where our team reviewed and evaluate whether our problem statement and product backlog are still valid after user research and interviews. We learned that the younger age group prefers to use the note app found on their phone, while the older age group prefers to use Excel or Google docs to keep their notes.
From our interviews, we have a better understanding of what is needed to develop for the app to meet the users' goals. For this phase, we focused more on the recommendation feature and an efficient way for users to save a trip to their itineraries. We also reviewed our proto-personas to ensure it met the demographic of users in their 20s and travel often with family and friends.
For sprint week 1, we focused primarily on our next MVP, which is the itinerary feature. I took the role of a facilitator for two of the interviews and a moderator for one of the interviews. For this portion of the interviews, we tested the need for an itinerary. We interviewed 3 interviewees and gave them a scenario, “You and 5 other people of your choosing want to go on a trip to Florida. You were picked to plan out this trip for everyone and your goal is to be able to send everyone an itinerary for this trip. What do you do?” We also asked them to walk us through their process by sharing their screen.
From these interviews, we learned that the younger age groups like to use the notes app that comes with their phone and share it with their friends. We also learned that four of our interviewees prefer to use a bulleted list.
For this session of interviews, we focused on the itinerary feature had the interviewees share their screens with us about how they organize their trip. We provided the interviewees with a scenario, "You and 5 other people of your choosing want to go on a trip to Florida. You were picked to plan out this trip for everyone and your goal is to be able to send everyone an itinerary for this trip. What do you do?"
After conducting our interviews, we learned that our assumption about using a day planner was the opposite of what we thought. Most of the interviewees prefer to have notes on the activities they want to do, list of what they need, and events and activities available for them. We also learned that the younger age group prefers to use the note app available on their phone and also share those notes with their family and friends. Additionally, most likes to use a bulleted list for readability.
For the last portion of Sprint two, we focused on usability testing to better understand whether our app is functioning properly to meet the user's goals. To do this, we interviewed and have three interviewees share their screen while testing through the prototype.
Through the usability testing, we were able to make adjustments to the prototype and understand what users look for in an app in order to meet their goals. The following adjustments that needed improvements on were as follows:
A valuable lesson that I learned from this project is the importance of breaking away from our previous methods and adapting to a new approach. Given the complexity of our app idea and the numerous features involved in trip planning, our focus shifted away from creating an MVP. In addition, we realized the significance of collaborative teamwork during the Lean UX process. Even though we initially struggled to comprehend how an MVP works, we were able to get back on track and make progress. This project provided me with a hands-on experience and deepened my understanding of the Lean UX approach.
Through working on the AdvaTravel project, I came to realize the essential role that collaboration and communication play in the development of a successful product. By maintaining an open dialogue and ongoing collaboration, our team was able to overcome challenges and complete the mobile app. This project allowed me to develop a sense of ownership and initiative-taking, which were instrumental in helping me contribute to the overall success of AdvaTravel.
Reflecting on the completion of AdvaTravel, there are some adjustments I would make for future projects. Firstly, I would dedicate more time to creating a detailed low-fidelity prototype. This would give us a clearer understanding of our wireframe and reduce the time spent on the high-fidelity prototype. Secondly, I would present the same case scenario to all interviewees to better understand their trip planning process and identify any common themes. Lastly, I would prioritize ensuring that all team members are on the same page and communicate regularly to avoid any misunderstandings.
Let's Connect!
