LET$PAY: A STORY OF TRUST AND FEES
Letgo, a native mobile app, is a second-hand goods marketplace that connects sellers and buyers locally. Let$Pay is the most convenient and safest payment method to use within Letgo.
The goal of this project was to create an in-app payment method for Letgo. The new feature should make the transaction process quick, more secure and hold buyers and sellers accountable. Stakeholders required this new feature to generate a small service fee for each transaction.
TIMELINE: 2 weeks
TEAM: Will Cruthers, Emily Darby, Evan Tyerman, and Inma Varandela
MY ROLE: User Researcher, Interaction Designer, Low and Hi-Fi Prototyper, User Tester
TOOLS: Screener Survey, User Interviews, Personas Development, Design Studio, MoSCOW matrix, Paper prototypes, Sketch, Marvel, Invision
DELIVERABLES: Clickable prototype, 12 min. stakeholders presentation
DEFINING THE PROBLEM
GETTING TO KNOW OUR USERS
In order to make sense of the product ecosystem, my team brainstormed a mind map to understand how LetGo works and how users interact within it. Also, an empathy map helped us to generate some hypotheses on LetGo users motivations, needs and pain points.
But we wanted real insights so we had to talk to our real users. Our first approach was creating a short screener survey to recruit people for in-depth interviews.
My team conducted 6 user interviews with current LetGo buyers and/or sellers over the phone and in-person. We gathered a significant amount of qualitative data that helped us understand who we were designing for. Furthermore, we validated some of our initial hypotheses and learned about users' needs and pain-points when making transactions within Letgo.
After categorizing and merging this data in an affinity map, we extracted the following key insights:
- Most people that usually sell on Letgo buy as well, and vice versa.
- There is a lack of trust in second party accountability when making a transaction.
- Frustration by time spent coordinating sales and exchanges.
- Users rely on online payments when depending on well-known companies (i.e. PayPal).
In order to bring data into life, we crafted personas to represent our users (motivations, current behaviors, pain points…) and ground future design decisions. We designed for our primary persona and accommodated the secondary.
Primary persona: second-hand goods lover who actively sells and buys.
Secondary persona: budget-consciousness, occasional buyer.
To clarify our design focus we defined a concise problem statement combining user insights and stakeholders goals. We used it to become aligned as a team and to validate wether future outcomes solve the problem.
Two systemathatized design studio sessions helped our team to generate multiple ideas –features– in a very short period of time. These are the steps we followed:
- Review personas
- Define the problem in an specific scenario
- Create solutions individually
- Pitch idea to the team
- Critique based on problem statement, not on personal preferences
- Iterate and refine one best version individually
We classified our ideas using a MoSCOW matrix, prioritizing features based on users and business goals top of mind to create a MVP product (and to avoid creeping featurism!).
The categories where features fell into are the following:
- MUST have: critical to the current delivery timebox in order for it to be a success.
- SHOULD have: important but not necessary for delivery.
- COULD have: desirable but not necessary, they would be included if time and resources permit.
- WON'T have (this time): least-critical, lowest-payback items, or not appropriate at that time.
After learning that trust was key for our users, the main goal of our design concept was building it.
Let$Pay is an in-app payment method that uses Letgo as a middleman between buyers and sellers executing digital payments. Money stays “in limbo” until both parties are satisfied with the transaction.
Assembling the selected features that will shape Let$pay, we created some user flows. Thus, we crafted a “happy path” for our primary persona that helped us plan what to sketch next.
Before jumping into our computers, my team rapidly created a paper prototype and tested it on two users to validate our design concept.
WIREFRAMES AND USABILITY TESTS
With feedback from user testing, our ideas advanced to mid-fidelity wireframes using Sketch. Again, the mid-fidelity prototype went through two rounds of usability tests before turning it into high-fidelity wireframes.
The goal of users test was to assess:
- Does this new feature increase users trust when making online transactions?
- Does the contract nudge users accountability while keeping flexibility for editing the logistics of the exchange?
Throughout the usability tests, we observed that users didn’t completely grasp the concept of Let$pay.
Consequently, we designed a quick onboarding process with clear instruction on how to connect their bank account or/and credit card to their Letgo profile in order to use Let$pay.
But this was not clear enough… We wanted every user to understand and feel comfortable using the new in-app payment method. To ensure buyers and sellers completely understood the concept of Let$Pay, we included a quick tutorial within the onboarding process.
The idea of generating a contract between both parties was our attempt to solve two important issues we found in our research:
- buyers were weary of the quality of the second-hand good
- sellers were concerned about buyers haggling
Once both parties are ready to make a deal, the seller would fill up a contract with all logistics of the transaction to send to the buyer for their final approval.
The buyer received the contract from the seller and could either approve it or modify the exchange logistics, as flexibility was also important to all users tested.
A transactions screen consolidates all sales and/or purchases, both completed and upcoming.
The “limbo bank”
As people reported dropping out of deals was a major problem, we ideated this system in an effort to hold both parties accountable. This is how it works:
Once the buyer confirms the contract, their money is sent to Letgo bank as a downpayment until the day of the exchange.
On the day of the exchange, the buyer would “Send Payment” to the seller when they were satisfied with the item, essentially releasing the funds from Letgo bank.
The transaction fee
One of the requirements from stakeholders was applying a small fee for each transaction. However, based on our research, my team knew that users don’t like fees so we decided to obtain more solid evidence to present to stakeholders. Thus, we distributed a survey to previously screened user and we obtained +30 responses confirming our hypothesis.
Based on what we heard from users, we recommended to stakeholders that they implement a service fee ONLY on Let$pay transactions and that this should be the seller’s responsibility, because they are using Letgo to host their items and make a profit.
My team was very excited about incorporating other features to alleviate the most important pain points users asserted during research: accountability and trust.
- Penalty fees when one of the parties cancels the deal without enough time in advance (similar to the approach Uber has when riders cancel a reservation last minute or don’t show up)
- Rating system for seller and buyers (a similar system as eBay, which has been proved very beneficial in our user research)
I personally would be interested in assessing how the contract could increase accountability in both sellers and buyers. Designing for changing people’s behavior, in this case locally buying/selling second-hand goods online, is always tricky. The main problem is that what they say in a usability test environment might be different from what they actually do in real life.