Help users create groups, share events, communicate and pay...
TripAdvisor currently enables users to book trips and experiences. It plans to expand this feature to facilitate experience bookings for groups of people who are not necessarily travelling together, but are in the same location. Mobile and tablet are the target devices.
Additionally there were three main features to be explored:
- Real time communication between users in the app
- Ability to share the event and/or invite people on other platforms
- Users should be able to pay individually for the experience
Using the Double diamond methodology
Following the double diamond approach (Discover, Define, Develop, Deliver), we started our discover phase by first conducting competitive research and then user research.
Conducting competitive research
For the competitive research we looked at TripAdvisor’s direct competitors such as Airbnb, Expedia and Timeout. Few of these businesses offered group booking in the main checkout flow. Further research across various travel, flight and hospitality businesses indicated that group bookings were usually serviced by a dedicated channel with a separate booking process.
It appeared that Airbnb was the only competitor to offer group booking in the main checkout flow — groups of up to 16 users in fact (and a 2017 press release hailed this as a major solution to user needs). These had to be booked a long way in advance and were reserved for 72 hours. Hosts hated it as they considered their properties being held hostage during the reservation process. We couldn’t determine whether the feature was still live.
We also looked at indirect competitors that addressed other aspects of the brief (e.g. payment splitting apps) but none offered an integrated or inline experience.
Conducting user research
We conducted user research in two waves, starting by getting out of the building. We visited venues listed on TripAdvisor, talked to users that booked London sightseeing experiences at a hostel, and finally attended a Meetup to meet people passionate about organising group events.
At the Tower of London, my colleague Gina and I were able to talk to multiple groups of visitors. I also got a brief history of how group ticket sales had migrated online from the attendant at the group booking window.
These are our initial finding:
- Bookers tend to pay and usually have a preferred way of being reimbursed.
- Groups find it difficult to agree on a date and collecting money from participants.
- Online booking is the dominant payment method.
This helped us construct our first experience map , something that we would return to and develop as we worked through the rest of the discover phase.
User interviews and affinity mapping
We conducted a further 12 user interviews. These were based on a discussion guide and set of questions we developed to ensure consistency across the work. After transcribing the audio we atomised the content onto 166 Post-it notes and undertook an affinity mapping exercise to identify themes across the interviews.
They main insights from this process are:
- Payment was the key issue, for both bookers and bookees.
- Usually one person pays and it’s stressful asking friends for money.
- Bookers take charge, sometimes they like it, other times they worry it simply won’t happen.
- People want to communicate with their friends…on the platforms they are on e.g. Whatspp or Facebook.
Building an experience map
Working on the first iteration of the experience map, we realised the complexity of the process. There were some significant emotional lows associated with the journey. Organisers worried they might not be reimbursed, having people drop out of contact exacerbated this, and constant payment reminders were embarrassing at best.
Mapping the user journey
Having completed our full research we found that we needed to revisit the experience map and add in additional tasks across each phase of the user journey. For example we found it was very typical that users would set up a WhatsApp group for the party to build consensus in the Finding/Agreeing phases.
Creating a persona
Our persona, Sara, was based on the most common attributes and characteristics from the user research. We decided to make Sara (our primary persona) a booker and developed the following experience-booking scenario.
Sara is organising an intimate hen party for her best friend and five others in Paris. She’s found a luxury Paris day trip on TripAdvisor.
We decided on a problem statement with a distinct financial slant as this was the issue that came into focus most clearly from the affinity mapping.
The trip is quite expensive and Sara doesn’t want to put it all on her card.
We sketched out storyboards to depict the four parts of the outcome statement (Situation, Problem, Solution and Outcome). It's a useful way to highlight which parts of the product experience are most important to the user and helpful in solidifying a team vision.
Running a design studio
We had planned to run three sessions for ideation, one for each of the deliverables highlighted in the brief (communication, sharing and payment). However, our research had indicated that the main issue was around payment and that there was significant complexity for us to select this as a focus.
We developed a ‘How might we’ (HMW) statement around enabling multiple users to pay for experience on the site. We explored three areas during ideation: creating groups, helping groups manage a shared pot of money and also ways of implementing dashboards/notifications to provide visibility on group payment status.
How might we enable multiple user to pay for an activity?
The flow design
While we came out of ideation with a clear direction, we still needed to consider how the features would integrate with the existing site structure.
The wire flows are a series of rough screens that represent the user’s path though the application and task completion. This ensures that all the screens needed for a paper prototype are accounted for — and in this instance that the solution integrates meaningfully with current product.
Prototyping is a way of getting screens in front of users and testing design solutions as quickly and cheaply as possible. Our first step was to work through the screen flow and get to a core set of screens that we could use for the initial paper prototyping. We took photographs of the screens and uploaded them to InVision where we added basic interactivity.
How we tested
Each prototype was tested with actual users. They were presented with a scenario (for context) and a set of tasks to complete. Issues were recorded and colour-coded across each set of prototype tests, this way it was easy to identify trends.
The paper prototype (v1)
There were some key issues that emerged from the first round of testing:
- Users were unsure exactly what constituted a group. Did two people count, and how many people did it go up to?
- Users hated having to add email addresses for friends. In most cases they didn’t have them, especially for friends in a social/messaging environment.
- Users were confused not to be able to find a breakdown of how much each party member had paid.
The paper prototype (v2)
We decided to create another paper prototype (calling it V2) to capture these changes as they required significant alterations to the screens and flow. There were also some broader non-UI issues that needed addressing.
- It became apparent that a reservation period would be required in order to give large parties time to log in and pay.
- If the party is ready to complete the transaction an auto-payment feature would reduce the burden on the booker to keep checking the app.
- The user journey started on a new screen. Users expected this feature to be signposted on the checkout page.
The digital prototypes
After a round of testing with the second paper prototype we started to incorporate the changes into a low fidelity digital prototype. While we were still iterating the solution, at this stage we were also firming up how the screens visually integrate with the existing website.
One of the main problems was that users had few expectations or experience of how group booking would work so there were limited resources for us to draw on . Users were unclear what several phrases (e.g ‘reserved for 6 hours’) and icons mean. Additionally we were trying to create a UI that users could find intuitive in the context of an exiting product.
We continued to iterate through waves of testing, gradually upping the fidelity of the work.
High fidelity screens & prototype
Here is a selection of the final high fidelity screens.
High fidelity screens
As we drew to the end of the sprint our testing period came to an end. We incorporated a final round of changes then worked on fully applying the TripAdvisor brand identity.
There’s always more to do. This is what we would focus on next:
Speak to project stakeholders: Concept projects are always something of a free-for-all when it comes to implementation. There were no product managers or developers to bring into the process and as such the solution was designed with few constraints. It’s odd including this as a next step as it has a place much earlier in the process.
Refine UI: The UI has some significant flaws that comes from four designers struggling with a process in a limited timeframe. While the screens were taken to high fidelity it should be considered a concept only. The UI needs to be revisited and reviewed against standard design patterns and visual language.
Prepare for Alpha/Beta testing: As with any piece of new functionality it requires testing and Q/A. Given that changes are being introduced into the main payment flow, adopting a rigorous process of Alpha- and then Beta-testing will be mandatory.