Bundling Travel and Event Booking
Project Synopsis
A responsive web platform using event ticketing as it's central focus, allowing users to bundle flights and accommodations. Our team focused on research, concept testing and prototyping to improve this beta-stage product, cement adoption and encourage retention with target users.
Timeline
4-weeks total, 1-wk long sprints
(October 2019)
Tools
Post-it Notes
Figma
Roles
User Research, Content Strategy, Prototyping, Concept & Usability Testing
Client
Rave Travel Technologies (Rave)
Overview
Background
In 2019 Rave was an early-stage startup whose mission was to allow consumers to book event tickets, airfare and lodging accommodations all in one place. Rave’s value proposition rested on the platform’s ability to incorporate API access to third party sites that sell event tickets, airfare and lodging, thereby enabling bundling to ultimately save users time and money.
Challenge
Rave came to our team to conduct research into their target user group, identify areas of improvement for their beta site, and test new features and site interactions. Rave already had a Minimum Viable Product (MVP) with their beta site, however the key stakeholders had designed this site on their own expertise, experiences and assumptions, which added an extra interesting piece to this challenge.
Process
Goals & assumptions
We had a lot to accomplish in a short period of time. Our team outlined the overall structure and research processes we’d use over the coming weeks. Additionally we identified our own personal biases and assumptions we had going into the project. Some of these personal biases stemmed from:
our ages
our personal experiences traveling
how we travelled and booked travel currently and in the past
various interests in events
our predilections for traveling specifically for a special event.
We knew from the get-go that time was a constraint, and were eager to meet with Rave. At the end of four weeks, our goal was to take Rave’s current Minimum Viable Product (MVP), dissect it and return an enhanced product.
Asking questions
Prior to the kickoff meeting, our team set to work researching Rave’s direct and indirect marketplace competitors. Through this research we validated that there was indeed an opportunity space when it came to an all-in-one platform offering event tickets, airfare and lodging.
But like all good UX researchers we wondered, “Why?” Yes, there’s opportunity, but we were curious as to whether people really wanted to bundle everything together; if so were there certain circumstances or situations in which an individual might be more likely to purchase everything at once? With these questions in mind, we set out to research the landscape of travel and events.
Kick off
During our kickoff meeting with Rave we engaged their team with an empathy map exercise to better understand how they perceived their users’ joys and frustrations. Through this exercise they stepped into their user’s shoes; we gained a more holistic insight into the problem space and perceived user. We also prioritized our goals for the entire project so everyone was on the same page.
Image: A screenshot of our team video conferencing and presenting wireframes to our Client.
Remote work
Rave’s team was primarily located in Texas while our team was Chicago-based. While working with remote clients is now common, it’s worth calling out as it was notable pre-pandemic. After all, pre- or post-pandemic, one of the biggest challenges in general is connection – connecting via technology with all it’s hiccups, but more importantly connecting with the humans on the other side of the screens. Our team of five was mindful of this gap; we employed techniques like delegating lead vs. supporting roles, and employed virtual workshops to engage our clients while gathering valuable information.
Audience
After getting more clear on Rave’s current beta product, future vision and constraints, our team set to work conducting interviews. We interviewed potential product users (Users) as well as Subject Matter Experts (SMEs) in the area of travel and events. We conducted 9 remote interviews with individuals in the US and abroad. For the interviews we sought out Rave’s stated target demographic: Millennials who enjoyed traveling. We were curious about what they wanted to experience during their travels as well as beforehand, during the planning stages.
Research
Qualitative data
Next we sifted for gold — we began to comb through our interview transcripts, looking for areas of overlap. Key trends began to stand out, including that many users actually enjoyed much of the trip planning process. Additionally individuals often didn’t book their event ticket, lodging and flight ticket all at once, nor did they want to. In the case of music festivals or concert tickets, oftentimes users reported they would know of the event before ticket sales were released. In these cases they wanted to get a jump start and book their lodging as they knew much lodging would be fully booked (or more costly) if they waited until tickets went on sale.
Honing focus
Given our initial findings, we began to wonder if there were instances when it might be more advantageous to users to bundle at least two travel purchases. Some initial questions we had included:
Was booking influenced by the…
destination?
context of the trip?
number of people going on the trip?
While people going on personal trips were less likely to book everything in one sitting, if the context of the trip changed to group travel they were more likely to book in advance, even bundling purchases. Users wanted to keep everyone together, minimizing the headache of group logistics.
Shifting our focus slightly from individual travel to individuals planning a small group trip prevented scope creep and allowed us to better identify areas for improvement on Rave’s beta site.
Refining the problem
By focusing in, we expanded our opportunity for meaningful impact on Rave’s platform. To keep our team aligned and focused on who we were solving for and why, we came up with a problem statement we could refer back to to make sure we always had our end user in sight:
The who: Zoë
We knew what we aimed to accomplish as well as who we were solving for, however we wanted to put a name and a face to this target user. Our research, interview synthesis and the above problem statement informed and shaped Zoë, an experience driven Millennial who loves trying new things, exploring new places and spending time with her friends.
Much like our problem statement, Zoë helped our team retain focus and alignment throughout the project; she served as a reference point during decision making always reminding us of who we were solving for.
Abbreviated user persona created for Rave.
Design principles
We came up with 5 design principles to ground and guide our designs. These principles were based on our users’ wants and needs as well as the problem we were solving for. With these design principles we aimed to:
Simplify - Allow the coordination of travel through minimal clicks.
Flexibility - Let users modify their travel and accommodations for a personalized experience.
Looped in - Be transparent by notifying users when and why their data is being shared.
Memorable - Offer a familiar but one-of-a-kind experience by designing for user’s desires.
Show me - Give users a breakdown of what they’re purchasing so they can see the value.
Five Design Principles represented in infographics, designed by yours truly.
Concepts
Initial concepting
Our team explored multiple concepts with focus on features that would be helpful for users planning group trips. Questions we asked ourselves:
What might be helpful to people who are the planners of their group?
What would be helpful to people who weren’t planning, but were still attending the trip?
When and where should we incorporate Rave’s existing beta stage screens in with our designs?
We came up with 9 concepts, and sketched them out as paper prototypes to test. We conducted testing sessions, asking questions on each concept to find out which concepts resonated and best solved for the problem.
We had to choose how to incorporate Rave’s existing beta stage screens in with our designs. We considered which elements should stay and what needed to be adjusted to work seamlessly with our concepts. Our design principles were key reference points, helping us navigate and define parameters.
Whittling down
Our findings pointed to two well-tested concepts, a group “folder” and a dynamic trip itinerary. We pitched these to Rave as concepts we’d move forward with prototyping and further testing.
The group folder concept proposed a centralized space for trip planning where users could invite friends, collaborate and favorite accommodations of interest.
After booking tickets a user would receive dynamic populated suggestions based on their trip information; these suggestions would be integrated into the trip itinerary feature.
The other seven concepts tested included: Price calculator, Travel buddy, Surprise me, Map view, Search by zip, Match with a Raver, and Request payment.
Image: Original “request payment” concept
The request payment concept resonated with users. While many users liked this idea during our testing sessions, they had questions about feasibility and had distinct preferences surrounding the options presented (Venmo and PayPal). We deferred this concept from further development as we thought it had strayed away from the heart of the problem we were trying to solve.
With the two well-tested concepts, we began iterating on Rave’s existing MVP, proposing changes and features to improve upon Rave’s current product.
Usability testing
Circling back
Concept testing allowed us to explore new ideas and variations on existing parts of Rave’s beta site. We referred back to our design principles to help guide in choosing where and when to incorporate Rave’s beta site material for the 2 concepts we proceeded with for usability testing.
At times during our prototype build-out we had different ideas of a flow or how something should. In these circumstances, we referred to our design principles, using them as our North Star.
A Space for Collab
Based on the results from our concept testing we iterated on the group folder concept. Users responded well to its collaborative aspect and the ability to favorite. We expanded upon certain features, like group chat and “bookmarking”.
Internally we’d been referring to this concept as the “group folder,” which didn’t feel right. Referring to our simplify it principle, we named the area housing this concept “My Trips.” Drawing language from the familiar (Pinterest), we referred to these folders as “boards.”
Users loved the idea of a space to collaborate and organize in. Some didn’t find it intuitive that the chat feature was relegated only to a specific group folder (they thought they’d be able to chat with anyone site-wide).
Confirmation and reminders
Users responded positively to the organized timeline and centralized location of important trip information and suggestions offered at relevant points, such as booking an Uber or being shown a yelp restaurant review. We added greater visual differentiation between booked itinerary items and suggested options.
Users again responded favorably to the timeline itinerary and liked that they were being offered helpful reminders as opposed to “pointless” add-ons. We received useful feedback that users wanted to be able to exit out of the suggestions if they wanted to opt-out. Similarly to the other concept, users loved that information was presented in a centralized way.
Findings
Usability testing showed us what worked and what needed improvement. In our final meeting with Rave, we presented our prototype and findings:
Timeline and suggestions - Users enjoyed seeing suggestions within the interactive itinerary viewing them as helpful reminders. Users wanted to be able to exit out of suggestions they didn’t want to see.
Splitting fares - Users wanted to have the option to split fares when paying. Users tied the cost calculator concept through to booking, assuming they’d be able to pay separately at purchase.
Linear booking flow - Users didn’t connect with the linear booking flow. They wanted flexibility since trip planning is piecemeal and things change.
Reccos
Based on our findings, our team presented Rave with the following future recommendations:
Add payment splitting feature - Due to positive feedback received during concept and usability testing sessions, we advise adding a payment splitting feature. Additionally we recommend Rave explore incorporating API’s from various payment platforms.
Redesign booking flow - Change the booking flow to allow more flexibility for users. Users appreciate not feeling “locked in.” By simply removing the linear progression bar present in the booking flow, users will feel more in control of their booking process.
In our final meeting, Rave was engaged, responding with curiosity and enthusiasm. We discussed what could feasibly be incorporated into the development phase, and what would need to be scoped out of this deployment.
Handoff
During our final client meeting we circled back to Rave’s vision for their Product Roadmap. We wanted to revisit this to make sure we were aligned on providing final deliverables that fit their needs and set them up for immediate and future success. Following our final meeting, we set to work on finishing touches. Our final handoff was carefully curated, consisting of:
Client presentations detailing each sprint (4 in total)
Research & Synthesis, including:
Affinity Diagram, Competitive Analysis & Summary Brief, Domain Research, Design Principles, User Persona, Problem Statement
User Research Plan, User Interview Synthesis
Concepts and Testing, including:
Concepts and Concept Statements
Empathy Map
Concept Testing: Plan, Script & Synthesis
Final Design and Usability Testing, including:
Final Site Map, Wireframes, UI Kit, Prototype
Annotated Wireframes, Prototype Walkthrough .mov files
Usability Testing Interview Plan & Interview Synthesis
Future Recommendations
Reflections
Don’t reinvent the wheel
I learned immensely from this project, a few things in particular stood out. We had to remind ourselves constantly not to start from scratch; rather we could introduce new concepts within existing structures.
Push/pull
I’d be lying if I said we didn’t regret our decision to scrap the payment splitting concept from testing. Multiple users said they wanted to see something like this, so this was a missed opportunity.
If I could do it over again, I would’ve push our team to include this concept into our prototype in some form. Though it was good we didn’t bite off more than we could chew, this instance was a reminder that though parameters are absolutely necessary, flexibility is key. This can be a hard line to walk, though this was a helpful lesson of when to lean in.