Case Study: Talk and Plot — A new approach to plan group vacations
source link: https://uxplanet.org/case-study-talk-and-plot-a-new-approach-to-plan-vacations-as-a-group-83cdea8b1bdc
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Case Study: Talk and Plot — A new approach to plan group vacations
Overview
This is a user experience research-based project, the main objective was to use research methodologies, gather insights, and fuel product design. We followed the design thinking process (Empathize, Define, Ideate, Prototype, and Test) to consolidate this project.
My involvement in this project includes conducting research, defining problems & ideating solutions, creating wireframes & UI, and linking the research data to the UI by the means of ideation and wireframing. I followed a non-textbook approach and understood the usage of various problem-solving frameworks over the course of building this project. I also learnt extensively about building trust when working as a team, dividing work to conquer more ground, and working with time sensitivity.
This project and case study were built and written during a 48-hour hackathon under the guidance of Anudeep Ayyagari (UX Designer, Amazon) along with the support of growthschool.io.
Talk and plot is a hackathon case study by the collaborative effort of the team The Backpackers. Expanding over an intensive 48-hour work stretch, this hackathon began at checkpoint zero with nothing but only a couple of strangers wanting to work on something and came to a halt at an upbeat ending with some great relationships and oh yes — a plausible solution!
View solution & final screenshere
The call kicked off at 9 pm on Friday, and we began by selecting our problem statement -
Problem Statement
Design a feature for a popular travel booking app, allowing a group of friends to plan and book their mutual vacation.
Why this Problem Statement?
- The backpackers feel that a travel app is an all-in-one solution — Travel includes multiple aspects so it is best so that the users don’t have to rely on multiple services and as a team, we want to explore an app that provides a unified solution.
- From an industry point of view, we wanted to take on a challenge which is an obvious truth in the world at the moment compelling all competitors to work on it as well, so we believe working on it would intensify the competitive environment to make the product market-ready before anyone else.
- Since no one in our group has had the experience of working on a travel app before, we wanted to explore this problem statement and work towards it.
Plan of Action
“Six people, 48 hours — we will take turns to sleep, turn to work and it should be done.”
Haha. That’s the sound of life laughing at us, so clearly none of that happened. A lesson we humans have learned over and over again, but somehow still hope that next time it will work.
To chalk out a plan we began with listing out our task preferences —
Okay, so clearly that did not work either. With all the talking and our first checkpoint coming closer, we decided to take a different approach — deciding our timeline. Since we already had access to some reference tasks which laid out the process, all we had to do was divide all the tasks into 48 hours, and et voila — our plan of action would be ready! Right? — NO!
Timeline
- Understand the problem statement
- Coming up with the assumptions
- Secondary Research
- Primary Research
- Analyze the Data
- Define and Ideate
- Wireframing
- UI Design
- Prototyping
- Usability Testing
With just the major topics listed and no depth of the actual tasks, we realized it would not work. So the next plan was to break the process down into sizable working chunks, and so we did -
Process Breakdown Checklist
The first thing that brings clarity! With the process laid down in order, this checklist made our guide for the next 48 hours — bringing along with it a hope that yes — we can do this!
The next step in our plan of action was to divide roles, set timings according to our process breakdown list and micro organize so we can use every single second!
Timeline Tabulation
With roles and responsibilities, we began our process. Although, don’t be deceived — turns out we are not as perfect as we thought we are and what started as a final organized plan soon turned into one of the many revised plans!
Within the first hour of working, we got our first hurdle — a member had to leave. Going from 6 to 5 demanded a change in our plan or action, we worked for some hours, and while we were about to revise the plan to make it compatible for 5, came another hurdle — exhaustion! While we worked till 5 am in perfect order, it wasn’t possible to go further without some rest. After a 3 hour break and a clear deviation from the first plan, came — Roles and responsibilities 2!
Timeline Iteration
This poor table has seen everything in life! While it is called Roles & Responsibilities 2, it is an undercover agent that is version 3, 4, 5, 6……100!!
As the day began, came another big hurdle — sickness! Another team member fell sick and had to drop off, so 6 became 5 and then 5 became 4. But we’re the backpackers, so we packed our bags of stress and panic and revised our plan! There is only one way to move — FORWARD!
The Process
Understanding the Problem Statement
To thoroughly understand the problem, it was first vital for us to express what we understood of it. All the members described their understanding, which lead to a group discussion eventually leading us to a conclusive understanding.
Conclusive Understanding
Since the world has begun to open its doors to traveling again, everyone is planning vacations, especially large groups like friends and families. The travel app in the problem statement wants to cash onto this opportunity and create a section/feature solely focused on “planning” the entire vacation for such large groups
Assumptions
Step 2 to begin solving our problem — make assumptions. Our team conducted an exercise where each member wrote down their user & product assumptions. We collected all the assumptions, went through them as a team, analyzed the points, and divided them for the next step.
User Assumptions
Product Assumptions
Hypothesis Statements
After analyzing the assumptions. The team conducted another exercise where each member wrote down multiple hypothesis statements. All the statements were clubbed together and divided into specific topics to make the data easier to work with -
Itinerary-related
Communication-related
Travel-related
Finance-related
Preference-related
Service-related
Final Hypotheses Statements
- Our hypothesis is that the travel app should have a feature that makes an estimated budget range for the group of users who want to travel together.
- Our hypothesis is that the travel app would do well with gamification of the entire vacation process and making it more adventurous for the groups of friends going on the vacation, it could increase enthusiasm and level of planning the occurs in such groups. It can be incentivized or the group could be awarded discounts for conducting/participating in activities together.
- Our hypothesis is that the travel app would require a feature where friends can come together to make groups so that they can communicate and also casually chat and essentially discuss the entire trip together. (Replacement for the WhatsApp group.)
- Our hypothesis is that the app should provide a list of necessary things that a group should take with them on the trip as per the weather, location, other necessities. Add different categories for different types of places(Where people can just scroll and explore).
- Our hypothesis is that the app should have a feature assuring the groups of travelers that the covid19 protocols are followed while also urging them to comply with the covid19 rules and regulations that are specific to groups traveling together.
- Our hypothesis is that the app should have a feature that provides easy and hassle-free cancellation in case the whole group wants to cancel their trip or a few members need to cancel their trip without affecting the entire group.
Secondary Research
After narrowing down our hypothesis statements into 6, we began our secondary research. The team divided itself into 2 parts and work on the two aspects of secondary research simultaneously -
A. Desk Research — TEAM A
B. Competitive Analysis— TEAM B
A. Desk Research
The desk research done by Team A involved reading articles to validate the hypothesis statements.
1. We hypothesize that the travel app should have a feature that makes an estimated budget range for the group of users who want to travel together.
2. We hypothesize that the travel app would do well with gamification of the entire vacation process and making it more adventurous for the groups of friends going on the vacation, it could increase enthusiasm and level of planning the occurs in such groups. It can be incentivized or the group could be awarded discounts for conducting/participating in activities together.
3. We hypothesize that the travel app would require a feature where friends can come together to make groups so that they can communicate and also casually chat and essentially discuss the entire trip together. (Replacement for the WhatsApp group.)
5. We hypothesize that the app should have a feature assuring the groups of travelers that the covid19 protocols are followed while also urging them to comply with the covid19 rules and regulations that are specific to groups traveling together.
6. Our hypothesis is that the app should have a feature that provides easy and hassle-free cancellation in case the whole group wants to cancel their trip or a few members need to cancel their trip without affecting the entire group.
B. Competitive Analysis
The second part of secondary research was conducted by Team B, research of all the competitors that are in the travel industry — their features and complaints in relevance to our hypothesis -
Target Users
After collecting data through secondary research, we went through more articles in order to define our target users. Based on the sources, we came to the following conclusion -
Sources —
Primary Research
For our primary research, we found a few participants who agreed to talk to us about their travel experiences. So to ask them relevant questions, the team prepared a questionnaire that was used by every member to conduct the interviews.
A. Questionnaire
1. Ice-breaking questions
- Occupation
- Demographics
2. When was the last time you planned a group trip/vacation before?
- Who was it with?
- Where did you go?
- How did you go?
- How was your experience?
3. What factors influence you when you plan a group trip/vacation?
4. How did you plan your budget before planning the group trip?
5. How much was the difference between the budget before all of you planned the trip and the amount you spent after the trip?
- Where do you feel all of you spent the most money, more than what you expected to spend?
6. Did you ever take part in group activities and games while on a vacation?
- What was the activity?
- How was your experience?
7. Did all of you you ever interact with local people and make friends with them when you were at your last vacation destination?
8. Where do you mutually plan your trips? Do you use any apps to discuss your trip plan?
9. Did all of you prepare a checklist for your last trip?
- If yes, where and how?
- What kind of items did you list on the checklist?
10. Did you travel as a group during the covid pandemic?
- How was it different from traveling before covid?
11. When was the last time you canceled a group trip? What was your experience like?
B. User Interviews
Hypotheses Validation
After collecting data from both primary and secondary research, the team sat together and validated (or invalidated) all the hypothesis statements.
Ideation
While the next step for our team was to do a deep data analysis, we figured out that our problem statement may not require it. So based on our hypothesis validation, we proceeded to ideation. In ideation, we decided to ask the ‘HOW MIGHT WE’ questions to generate solutions.
How Might We?
We noted questions and then brainstormed the solutions for every single question.
1. How might we create a budget range for a group of friends planning to travel together?
2. How might we provide a way for communication between the group of friends who are planning to travel together?
3. How might we assure safety to groups of friends traveling together during COVID times?
4. How might we make cancellation easier for people traveling together in a group?
Defined Solution
To go ahead with our process, we analyzed all the solutions and then landed on one solution to work on -
Create a messaging feature that allows private as well as group chat and features like bookmarking and highlighting messages, budget planners, sending media within the travel app.
Wireframing
After deciding to work on a group messaging feature. We began to break down the solution into comprehensible segments to bring clarity for the further process of wireframing.
Solution statement to work on: Create a messaging feature that allows private as well as group chat and features like bookmarking and highlighting messages, budget planners, sending media within the travel app.
Breakdown
Private messaging — feature for sending text messages directly
Create a group — feature for discussing details of the travel plan
Features in the group —
- sending text messages: the average text exchange format like any group chat which allows the exchange of words, sending media (pictures, videos, and audio files), word search option, and message starring.
- budget planner option: questionnaire asking the members about their place, stay, food & activity preferences to generate an estimated budget for the trip.
- taking poll option: question with options to choose from for the members to settle any opposing opinions and see the majority vote.
First Iteration — Pen & Paper Wireframes
To start converting our solution into a product, we had to start somewhere, after dodging between some websites and discussing how to begin, we made pen to paper wireframes based on our understanding.
Second Iteration — Low Fidelity Wireframes (on Procreate)
Not very different from the pen and paper wireframes, we moved on to creating wireframes on procreate. After analyzing our pen-to-paper wireframes, we concluded that each member had a different idea of how the screen would appear. It was not a wise idea, to begin with, but with exhausted brains and aching backs, we went ahead anyway.
So after the realization, we decided to run away! Just kidding. We decided to run another exercise but this time, together. We made the following wireframes while coordinating with each other.
Image 1: In image one, there are three screens. Contact, chat, and group. The ‘contact’ depicts the person who can be added, the ‘chat’ depicts a group of friends planning their trip and the ‘group’ depicts an option to add members to a group and form the group.
This iteration did not work at all. We realized our focus is not on creating the group but on what the group itself brings to the table. These wireframes did not support our validation and solution and thus were not taken forward.
Image 2: In image one, there are three screens. Home, group, and poll. ‘Home’ depicts the person who can be added, the ‘chat’ depicts the users’ home screen where they will be able to message individual people and groups. The screen also had a red button to create a new group. In the second screen, ‘group’ depicts all the members of the group being able to talk to each other, and in-screen three ‘poll’ depicts the option of sending a poll to resolve any difference in preferences. This iteration did work for this stage. All the screens from this were relevant and could be taken forward. We realized our focus is not on creating the group but on what the group itself brings to the table.
Image 3: In this image, the 6 screens are describing the process of a budget planner. Screen 1 to 5 ask for users’ preferences and the last screen depicts an estimated budget for their desired trip. This iteration worked as well and was taken forward.
User Flow
After making wireframes for our main options in the group messaging features, we moved on to deciding the flow of the user.
While building the user flow, we came to a standstill where the feature of the budget planner did not have a further step due to assumptions about the nature of the behaviors that might occur. While our wireframe iteration worked, the was a missing link in the flow and navigation which lead to conducting another analysis.
Re-analysis of the Flow to Support Wireframes for the UI
Considering the nature of the problem and timeline, we relied on some common utopian assumptions -
The budget planner will work provided — -Members will not be lazy in the group -Members will be eager to fill up the questionnaire -Members would have similar preferences
Revised User Flow
The revised user flow brought in clarity. With the help of the revised user flow, we began working on the user interface on the app — with our base app as ‘ixigo’ — a travel planning and booking app. While working on the user interface screens, we realized there were still some missing links in terms of navigation. So we regrouped and made multiple iterations to support the navigation.
User Interface
Traditionally, making the user interface is a process that comes after making low or high-fidelity wireframes, although this is jugaad-a-thon — so catching up with the time crunch, we followed the revised user flow with a combination of low fidelity wireframe iterations to create our UIs!
A First Cut
Following are the first UI iterations that we made based on the revised flow -
The iterations shown above gave us a clear direction, although we soon concluded that for the screens to work we would need better and clearer navigation.
Final UI
After reassessing our first UI iterations and redoing our navigation. We formed the following UI Screens -
Base App — IXIGO
We broke the flow into 2 halves -
- Exchanging texts and media in order to communicate
- Comprehending each person’s preferences to provide an estimated budget for the plan
Exchanging texts and media in order to communicate
- The user can click on the ‘what’s new’ banner on the home screen of the app.
- On the second screen, the user can see their friends and groups created to plan their trip.
- In the third screen, users can send a poll to ask questions, take suggestions or resolve a conflict.
- In the fourth screen, the users can keep seeing the poll (whenever they wish to) to track the progress of the poll.
- In the fifth screen, the users can switch from the chat screen to the plan screen to plan trips through tools provided by the app.
Comprehending each person’s preferences to provide an estimated budget for the plan
In the second flow, there are 7 UI screens.
- In the first screen, the user can go to the ‘more’ section to access the trip planning option. This is the second way the user can use to get access to this feature.
- In the second screen, a wizard opens asking for the destination and date that the users want to opt for.
- From screens 3 to 6, the app asks the users’ preferences to calculate an estimated budget.
- In the last screen, the app shows the estimated budget and options to edit it in case the users want to make changes.
Conclusion
Someone said (us), and we quote -
“Six people, 48 hours — we will take turns to sleep, turn to work and it should be done.”
Little did we know this is going to be a crazy ride. While we have all done projects at different paces and timelines, this experience was a special one. This hackathon helped us build confidence in ourselves and definitely made us believe (with proof) that if we come together and focus our attention on something, we can achieve it regardless of the time!
We started as strangers who didn’t even know each others’ names and are taking along with us a friendship of a lifetime — thank you for following our journey.
Signing off (and going to sleep), The Backpackers.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK