LET$PAY: a story of trust and fees

Letgo 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.
  • Timeline
  • Two weeks
  • Goal
  • 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.
  • My Role
  • Research, Interaction and Visual Design, Prototype, User Test
  • Methodologies & Tools
  • Design Studio, MoSCOW matrix, Screener Survey, User Interview, Personas, Marvel, Sketch, InVision
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 generate some hypotheses on LetGo users motivations, needs and pain points.

Empathy Map: stepping into the users' shoes.
Mind Map of Letgo ecosystem.

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.

Insights Synthesis

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).

I like the idea of integrated payments. You'd know 100% how you were going to be paid. It's easy and convenient.

Kayli

Safety depends on how many people use it (i.e. Paypal, Venmo), that it's a big company so it makes you feel confident.

Rachel

I don’t think I'd venmo someone until I was sure that those chairs actually existed and I could put them in my car and take them home

Erin
Personas

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.
Typically people buy and sell secondhand goods online with strangers. Koko is concerned about her financial safety online when she's unsure about the trustworthiness of the second party.

How might we help her complete a secure, efficient transaction?
Ideating Solutions
Design Studio

Two structured 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
Paper sketches helped us explore the idea of a contract between seller and buyer
Feature Prioritization

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

Critical to the current delivery time box in order for it to be a success.

SHOULD

Important but not necessary for delivery.

COULD

Desirable but not necessary, they would be included if time and resources permit.

WON'T

Least-critical, lowest-payback items, or not appropriate at this time

First version of MoSCOW matrix on a whiteboard
Final digitized MoSCOW matrix
Design Solutions

After learning that trust was key for the users, the priority of our design 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.

User Flows

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.

Contract setup flowchart
Flowchart: Let$pay set-up
Wireframes & 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?
Let$pay Onboarding

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.

Tutorial

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 Contract

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 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.

Users wouldn't pay a fee when not using Let$pay

Conclusion

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.

These are other features that could be incorporated to alleviate the most important pain points discovered during research: accountability and trust.

  • Penalty fees when one of the parties cancels the deal without enough time in advance.
  • Rating system for seller and buyers.

I personally would be interested in assessing how the contract could increase accountability in both sellers and buyers. Designing for changing people’s behavior 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.

SELECTED WORK
Explore other case studies