At Intent, we as a company are very focused on solving problems that our users actually have. Through one of our main goals towards the end of 2019, which was developing extremely accurate and in-depth user travel journeys based on our already rich and meaningful user personas, we as a team noticed a problem arise. During our bi-weekly user testing sessions, we noticed that the same thing was being mentioned time and time again. Age, gender, economic background agnostic, this problem persisted. What’s more we started to notice it our quantitative data as well; there was a particularly high abandonment rate when it came to one thing in particular. I am sure many of you who are reading this would of experienced this problem in your own lives, I know I personally have on many occasions. The elephant in the room when it comes to the poor experiences when booking travel is of course; Group Planning & Booking.
Through in-depth interviews and analysis we identified that the biggest pain point when it comes to traveling for leisure is getting everyone aligned and on the same page. Our users helped us realise that the journey for group booking starts long before the research phase and often begins as casual conversation between close contacts. As time goes on people come and go, ideas are suggested and rejected, tempers rise and bonds weaken. In other words, planning and booking as a group of 2 or more is dynamic, it is ever changing and does not abide by the rules. The problem with planning and booking as a group is that everyone in that group has thoughts, opinions and requests that they want to be taken seriously… and with this call to action, we at
Our solution, which we later branded as TripHive, was to consolidate all aspects of group planning and booking and bring it to where the group actually is; group chats. Through our user interviews, we noticed that there was one consistent way that people went about planning and booking travel as a group, and that was the creation and inclusion of others in a group chat, most commonly WhatsApp. Below is a snippet of a real user quote relating to group booking.
“I need to talk to [my] group of friends, I usually do the research in person unless its not feasible, then l will send links in messenger or iMessage”
In general the person creating group took reigns for the majority of the orchestration of the trip and others in the chat chimed in at varying stages. This unearthing lead to the idea of roles within the group with TripHive allowing users to assign roles within the group e.g. one group member to look after money collection.
To be truly part of the group, TripHive needed to be both a standalone web and mobile application as well as a group chat integration. In other words, TripHive acts as a member of your group which you add into your group WhatsApp. Once in the group, TripHive sits and listens, acting as the silent, diligent friend. As the group shares information in the chat, the TripHive bot collects and sorts all of the links and stores them in an easy to access web application.
Members of the group can then easily get a link to the TripHive web app from the in chat bot. From our research we knew that users hate the sign up process of many applications, so we got rid of it. We added in simple text and QR verifications to hastily bring our users to their main TripHive dashboard. The dashboard itself is a collection of all of the links that have been shared within the group chat but they have been categorised and organised into clean and insightful collections. Users can quickly view, vote and comment on different parts of their trip as well as receive tailored recommendations on things to do and places to stay.
TripHive aimed to take the pain, confusion and frustration out of group travel planning and booking by being serving the role as the trustworthy friend within a group. Keep reading to find out how TripHive came to be and what real users had to say about this new innovation in travel.
To take the problem of group booking and planning, we decided that it would be the perfect opportunity to put my shiny new Design Sprint Masterclass by AJ&Smart to use. Unlike the traditional 5 day Design Sprint developed by Google, the sprint we decided to opt for the shorter, more intense 4-day offering. The days are broken up as the following: day 1 is about defining the problem, day 2 is all about solutions to that problem, day 3 focuses on prototyping and finally day 4 is when we validate our solution with real users. The full day break down can be seen below.
Before we began the Design Sprint, we needed to have problem statement to which we could underpin all of the weeks tasks too. To create a solid problem statement, myself and a user researcher paired up and looked at all of data around group booking as well as our user journeys. We identified one area which could be improved in the journey and that was the sharing of information. Below is where in the booking journey this problem lies.
With this in our sights we did a quick workshop exercise together to ideate and formulate a problem statement to be the basis of the sprint. In end we decided that the following most accurately represented the problems our users faced. It is important to note that we did not want this statement to be too broad as to be overwhelming or too specific as to start laying out solutions.
When planning and booking travel as a group of 2 or more, users are missing the ability to seamlessly share information whilst still accommodating individual needs within the group.
Now that the problem statement was finalised the next step was to prepare for the task of running this whole sprint. Presentations needed to be made, talking points laid out and exercises practiced to make sure my first Sprint as sole facilitator went as smoothly as possible. After this I then recruited a multidisciplinary team to take part in the 4 days. Members from engineering, design, marketing, data science, business development and product management were lining up to take part in the activity and in the end we went with a modest but powerful group of 6.
Defining The Problem.The Sprint started off on Monday morning with domain expert interviews with the Director of Product and the Director of User research. As the interview went on, the group frantically wrote down How Might We (HMW) Statements which would help with food for thought for later on in the day. As with all exercises during the Sprint solutions are voted on by the group with the final decision being made by one decision maker role. In the end the voted HMW statements looked like this:
Following on from the HMW statements we next looked optimistically into the future and set out a 2-year goal. The reason we focused on a 2-year goal and not a 5 or 10 year goal is that we didn’t want to look too far in the future that technology would be the solution or that the problem space might change. Basically we wanted to outline where we wanted to get to in an ideal world. We decided that our 2-year goal which takes user and business needs into consideration would be:
- “In 2 years time, group travellers will use a trusted
After a goal was set we then looked pessimistically at it. We started to as questions in the form of “can we” statements. These questions intentionally tried to pick holes and identify potential blockers which would stop us from reaching our two year goal. These can we questions help us keep the sprint on track and would be used as constant reference going forward. These questions are also what we want answered during our user testing sessions. As a group we moved forward with the following sprint questions:
With the problem identified and defined along with questions we wanted answered at the end of the Sprint, the next task at hand was come up with solutions. Because we were working on a 4-day rather than 5-day Sprint, we worked under the mantra of “alone, together”. This meant that we would work as individuals and reconvene as a group at set intervals.
To come up with solutions we underwent a 4-part sketching exercise. This involved: note taking, crazy-8’s, doodling, and concept sketching, with each part adding levels of detail unseen in the previous phase. Eventually we were left with 6 potential solutions that have had in total about 5 hours each of effort and thought put into them. In the end the group voted on one idea overall with some features of other ideas to be considered at a later point. The chosen idea, seen below, was the first iteration of TripHive.
With a solution that the group was happy with, we then started to get more granular. We as a group started to storyboard the solution and focus on the flow steps involved to help our users reach their goal. The storyboarding part of Design Sprints is notoriously the hardest part of the whole week and considering we chose a solution which spanned across multiple platforms (web, mobile and chat) the group was definitely pushed to their limits. In the end we created a detailed storyboard which we, the UX team, could take and hit the floor running on the following day.
On the penultimate day of the Sprint, the UX team took everything that was discussed over the past few days and attempted to create a high fidelity prototype which we could test and validate with real users the following day. We knew that this day was going to be long and tough with many walls hit throughout the day. But 14 hours later, we prevailed, we create wireframes and hi-fi clickable prototypes. We create chatbot scripts, we created a landing page, we utilised all of our individual strengths and came up with what I would call one of the most impressive turn arounds of career to date.
One key factor I contribute to our success on the prototyping day (bar the obvious talent of the team) was the use of Figma. Figma is a tool that we in Intent swapped to a number of months before hand but still some of our designs remained in Sketch, lost in folders help by one person on their computers hard drive. What this Design Sprint thought us as a team is that Figma is the right choice if you want collaboration and agility within your team. The ability to all work off the same file in real time is something that none of Figmas competitors come close to achieving, even with multiple additional bits of software.
After 3 long days, the time had come to let our solution do the talking. It was time to invite in real users to give us feed back and help validate our solution and answer our sprint questions. In total we brought in 5 users throughout the day and in traditional Intent fashion we had a well prepared testing script, scenario and task list.
We asked the users some intro questions about their past group trips and upcoming plans before proceeding to the task at hand of planning and booking a trip using TripHive. Users were not prompted but more left to freely explore and interact with the experience which spanned across mobile and desktop.
In order to create a realistic prototype, we decided that the chat functionality had to feel real to the user. It had to be relevant and timely, something which could not be achieved without the use of AI. This was not something which we had access to in the day we spent building the prototype so we opted for “The Wizard of Oz” style prototyping scenario where members of the design team played the role of computer actors, all working in tandem to orchestrate a continuously flowing, harmonious experience which users really engaged with.
After the testing was complete, we took all of our findings, recording and notes and started to create affinity maps and themes using thematic analysis. From here we could draw conclusions and answer some of our questions that we set out at the start of the Sprint.
Personally, the result of this Design Sprint was confidence in my ability to prepare, organise, facilitate and coordinate a group of people to complete a colossal undertaking in 4 days. From a business point of view our analysis of the user testing and interviews which were carried out spoke for itself. TripHive was seen as being a complete and total success and even as far as being the most highly received initial concept solution by users that
Through testing we managed to answer the sprint questions that we set out at the start of the week. Those problems that we identified were in-fact not barriers to TripHives success and that was because we provided a solution that accurately helped users in a way that felt familiar, useful and stress-free.
From a next steps point of view, TripHive is being expanded to offer all that its UI promised and from a business point of view investigation is underway to see the commercial viability of such a product. Keep your eyes peeled for the future of group travel.
Some Sample Screens.
If you would like to find out more about my work or would like to work on a project together, then please reach out.
I am currently looking for interesting, rewarding roles in UI/UX and Product Design.