CONTEXT

Initiating the Product

WeTravel is a platform for independent trip organizers and travel agencies to market trips and accept payments from guests.

Although the brand had attracted thousands of users their trip organizers could only accept incoming payments from guests but had no way to make outgoing payments to their vendors through the platform. The leadership team needed to validate the need for trip organizers to send payments and the probability that the recipients would be willing to adopt a new platform.

I led a team through the development of three new features. We needed to integrate these payment features into WeTravel’s existing IA and cater to a new use case (vendors) while prioritizing their existing user base (trip organizers). I lead a team through research, design and testing while communicating with WeTravel’s leadership team and managing a tight timeline.

See below for a preview of the core features. Following the annotated screens you’ll find a description of the process we deployed when designing this end-to-end product.

DESIGN AND IMPLEMENTATION

Core Product Features

PROCESS

Planning Our Approach

Because WeTravel had a strong user base but was unsure of the viability of the new payment feature, we started by validating user need. We needed to dig into the challenges for two separate use cases, so we deployed the Double Diamond approach. We split the team in half, each focusing on a separate use case.

USER RESEARCH

Use Case 1

Trip Organizers are existing WeTravel users who host trips on the platform. Trip Organizers would be using the feature to send payments to domestic and international vendors.

We identified a collection of learning goals for our interviews to discover:

1. How trip organizers currently make payments to their international vendors

2. Learn about the pain points around making payments and managing vendors

3. Understand comfort level in making payments through a third party platform like WeTravel.

After interviewing 7 exisiting WeTravel users, the following insights emerged:

Use Case 2

Vendors are partners who provide services in the host-country. They would primarily be receiving payments from Trip Organizers.

Because this was a new use case for WeTravel, we developed a user persona and began recruiting vendors for testing. In addition to generative interview questions, we ran comprehension testing through a series of rough initial mock ups to gauge comfort level in receiving payment through an unfamiliar platform. We wanted to understand:

1. How international travel vendors were currently receiving payments

2. The pain points associated with their current payment system

3. Any concerns around receiving payments through an unfamiliar platform

4. Primary motivators that would drive their adoption of a new payment platform

On the vendor side, the following insights emerged after our synthesis:

We needed to consolidate our findings from each use case to prioritize insights and begin thinking about features. We mapped user insights from both use cases on a 2x2 based on business impact vs ease of implementation.

Based on our affinity map, we scoped out three different options and proposed them to WeTravel’s engineering team.

Analyzing Options & Driving Growth

Because WeTravel is currently focused on serving trip organizers. We wanted to continue to prioritize their needs. Therefore, we narrowed the options down to 1 vs 2.

Option 1 was attractive, as WeTravel had already gained traction by providing a service that was valuable to trip organizers. If they double down and continue focusing on what they’re doing well, they can increase their market share and attract more trip organizers.

However, after discussing the options with WeTravel’s leadership team, I gained clarity around their plans for growth in the financial sector and decided to move forward with Option 2.

Option 2 provides greater upside, as transaction amounts are more substantial and WeTravel will be catering to a new use case while providing a new feature for their existing users. By providing a payment solution for both vendors and organizers, WeTravel can create a viral effect. Vendors are typically invited onto the platform when organizers initiate a payment, thus driving acquisition. Once vendors are retained, they will begin requesting payments from other non-WeTravel clients thus attracting new users on the organizer side and driving acquisition.

In addition to the core features, to ensure the objective of driving acquisition of new vendors, we had to ensure onboarding was seamless.

Trust was arguably the most important factor, noted by 7/7 vendors during our interviews. We proposed a purchase order (PO) and invoice generator to be included in the product features as these are formats vendors are familiar with, however, the client declined so we designed the initial email to appear in a similar vain.

Learning from other competitors, we designed the payment flow to include minimal inputs with autofill capabilities. We paid close attention to error states and minimizing user error.

TESTING

Feature Validation

REFLECTION

Closing Thoughts

From the start of this engagement I realized it would be a trying challenge. We needed to get creative from the time we started recruiting subjects for both use cases. We gained a solid understanding of the product and were able to make design decisions based on business objectives.

Filling the role of project lead required a high degree of facilitation between the design team and WeTravel’s leadership team which I enjoyed, however, leading the project was both rewarding and humbling as I needed to advocate for our design decisions while keeping our client’s vision in mind. I learned the importance of validating decisions through data and the importance of consistent communication.

Take-Aways

I learned the importance of engaging the engineering team early and validating design direction based on plans for growth. We were constrained by the need to implement our payment feature into WeTravel’s existing (and inconsistent) information architecture and utilize their pre-existing design system. These were expectations that needed to be identified early. If I could repeat this project, I would have included the engineering team in our design sprints from the start, working cross-functionally from an earlier stage in the project.

I look forward to seeing the implementation of our designs in Q2 2019 and watching WeTravel’s continued growth.