TripAdvisor: The puzzle of group payment
Concept project #3 for General Assembly UX Immersive 2018
Duration | Team | Role | Project Type
2.5 weeks | Team of 4 | UX Designer | Concept Project (General Assembly)
User interviews | Affinity mapping | Personas | Competitor analysis | User journeys | Experience mapping | Design studio | Sketching | Wireframing | Rapid prototyping | User testing | Visual design | Presenting
Sketch | InVision | Marvel | Mural | Omnigraffle | Trello | Paper | Post-its | Sharpies
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
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 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.
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 build out our first experience map — something that we would return to and develop as we worked through our user interviews.
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.
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.
Having completed our full research we found that we needed to revisit the experience map and actually add in more steps. For example we found it was very typical that users would set up a WhatsApp group for the party.
Building a persona
Our persona, Sara, was based on the most common attributes and characteristics from the user research. We decided to make her 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.
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.
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.
Wire flows: 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 site.
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.
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 wave of testing on the paper (v2) prototype we started creating the screens in Sketch and exporting the screens into InVision where we could apply basic interactivity.
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.
How we tried to meet user goals
We re-worked the experience map to understand how our design solution would impact the task-flow across the user journey. Our solution added steps prior to a transaction, but would address the main post-transaction pain points.
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.
You’ve read what I did on this project, now you might also be interested in what I actually learned during it.
Hand over your ideas
It can be tough making decisions as team. But there are ways of managing branched opinion at critical junctures in the design process. In the early stages, transitioning from rough wire flow to actual interface, it can be hard to build consensus. There is always the option to simply test two ideas or three or four. It only takes five minutes to sketch the screens and start testing. Even better, hand over your sketches and take someone else’s.
Having a Kanban board isn’t doing Kanban
I’ve spent enough of my career working with (frustrated) project managers to know that having a process and having people follow that process are worlds apart. We had a Kanban board but no-one responsible for it, and we didn’t build our daily routine around the process.
Testing in waves makes life a lot easier
Testing is great, I love it. But having four people independently testing and making changes to screens — that doesn’t work. And this is where enforcing a workflow can help ensure that all team members are informed and making decisions based on the wider research findings.
Thanks for reading my article, I am a UX designer looking for a full time job, you can find my portfolio here.
If you ♥ what you read please be sure to give me a clap.