LetGo New Feature: A Story of Trust and Fees
Here I am, after three weeks within the Immersive UX Design Program at General Assembly, recapping my very first experience working with a team and a real client. Of course this was a simulation but it felt SO real!
My 3 teammates and I had no specific role assigned to each one of us, so we had to figure out where the boundaries were and how we could come to terms in every step of the process using certain methodologies that I will explain later on.
Our assignment was creating a new feature for LetGo, a marketplace for selling and buying second hand goods locally. I was really excited when I found out that this is a Spanish company whose headquarters are in Barcelona and New York: both cities feel like home to me because they are where I spent the majority of my life.
This was the problem/opportunity we found in the brief: “LetGo would like to facilitate in-person transactions by allowing for the other option of in-app payments between buyers and sellers, making the transaction process safer”.
In the beginning, since none of us had used LetGo before, we tried to become familiar with the app. I created an account and pretended to be interested in a couple of items just to get a feel for how things work within LetGo. The functioning was similar to the “For Sale” section on Craigslist but definitely more user-friendly and visually appealing. But still we found buyers and sellers trying to get a deal and to arrange in-person transactions.
We brainstormed about hypothetical LetGo users and their goals within the app:
RESEARCH
We needed to know who LetGo users are!
So we sent out a very short screener (just 4 questions!) to our contacts, some of us also posted it on our social channels and even tried to post it on Craigslist to see if someone would be interested in taking the survey.
Since there was no compensation, we didn’t get any data from the Craigslist post (it would have been very ironic if we had, considering that it is a LetGo competitor!). The goal of the screener was to recruit actual LetGo users that were willing to be subsequently interviewed.
We got 124 answers, and among them, just 6 people were LetGo users, meaning “our right user”.
We promptly interviewed these six users remotely, using FaceTime and Skype. The interviews were conducted by one of us while other team member took notes. We all switched duties throughout the process so we could each take on different roles (interviewer and note-taker). The main goal of these user studies was to find pain points in transactions made on the LetGo app from both perspectives: the seller and the buyer.
SYNTHESIS
After gathering all this qualitative data, we created an affinity map to identify patterns and trends on certain aspects that would be useful later on. After moving sticky notes around many times, some patterns started to emerge and we created categories. Some of the most important were COMMUNICATION, TRUST, EXCHANGE, PRICE and TRANSACTION METHOD.
These are some quotes extracted from user interviews:
“If percentage fees are known, it can drive people out of the industry”
“ If I could have used PayPal it would have been a lot easier (than paying in cash) because it’s more convenient. I had to go to the bank and get money.”
We merged all this information and came up with our two personas: a primary and a secondary. We based our design decision almost exclusively on our primary user, who happened to be both a seller and a buyer.
Please, meet Koko Wiley!! (PRIMARY USER)
…and Bri Tarth! (SECONDARY USER)
After many iterations based on the initial idea that people have to interact and exchange items with strangers, which involves safety and trust concerns, we came up with this problem statement :
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?
STRATEGY
After having established our user’s problem (from now on Koko’s problem), we had to generate the largest possible number of solutions for our primary persona. We wanted to kick off our design process with a brainstorming exercise. We were introduced in class to the Design Studio method so we used it in order to rapidly generate a ton of possible ideas for our design.
We first brought about a set of scenarios or tasks to design for, with the purpose to redefine the problem. This was our selected scenario: It’s Wednesday. Koko, 28, has arranged to sell her Kitchen Aide to Jake, 34, on Thursday after work, but he won’t have time to go to an ATM before they meet up. How might we help Koko and Jake facilitate an easy, secure payment?
From here, we individually created some rough sketches to try to solve the problem. After pitching our ideas to the rest of the team, we had a run of critiques based on our goal, not on our preferences (if we liked or disliked the idea). We came up with 1–3 ways to solve the problem for each individual design and one or two opportunities to improve it.
During the second round of the Design Studio, each member of the team created one best version based on what other members had presented and critiqued. This second individual sketch also followed the same protocol (create-pitch-critique).
We finally converged on one design after this process, but it also required some refining. The design concept was having a contract between buyer and seller when the deal was made. Also, we came up with the idea of a “limbo bank” where the buyer could deposit the money until exchanging the item. This way the seller could trust the buyer’s accountability. That’s how we came up with Let$Pay! Let$pay would be the middleman between seller and buyer, a secure and quick in-app payment method. We would charge a 3% transaction fee to users who pay with a credit card.
A second Design Studio was run after this with a different scenario in mind: Jeff and Koko agreed when they’d meet up to exchange a lamp Koko was selling. On his way to meet Koko, Jeff realized he needed cash for something he’s doing later tonight and would rather pay her electronically. How might we enable in-person modifications to Jeff & Koko’s contract?
Next step would be to prioritize features. Since the solution we came up with could involve a ton of new features to integrate, we had to decide which ones would be carried out.
Keeping Koko’s needs in mind, we used the MoSCOW method to decide the core features we would prioritize. We collaboratively mapped sticky notes onto a MoSCoW matrix.
After having set up our problem statement, our user goals, and feature priority in place, we had to start bringing all this to life through some wireframes.
First step was creating the user flow:
And from here, we started hand sketching some wireframes
We wanted to test those rough designs as soon as possible so we created a task scenario and put them in front of two users to get a feel for how our design was experienced:
Koko, Jeff wants to buy your Kitchen Aid. You’ve agreed in messenger on transaction logistics. Use this paper prototype to go from your chat screen with Jeff to formalize the details of the sale.
From those usability tests, we iterated our ideas and jumped into Sketch to create some mid-fidelity wireframes.
Some of the improvements we carried out:
EXECUTION
We brought these mid-fidelity wireframes into InVision and started testing them with users.
We completed six usability tests: we gave three different tasks to each user along with a scenario:
TASK 1
You are now Bri, 22 year old guy that lives in San Francisco but is on vacation in New York for a few days. You’re staying at your friends apartment and have noticed that she doesn’t have a Kitchen Aid but she loves cooking. You want to find a secondhand one and give it to her as a present for her hospitality.
So, Bri, you’ve been chatting with Koko on LetGo about buying her Kitchen Aid. She wants to be paid electronically and you’re OK with that. Link your bank account to your profile.
TASK 2
You are now Koko- you are a 28 year old freelance writer living in Brooklyn. You love to buy and sell secondhand items on apps and in-stores.
So, Koko, you’ve been chatting on LetGo with Bri, who wants to buy the Kitchen Aid you posted for sale. You’ve agreed in LetGo messenger on transaction logistics. Go from your chat screen with Bri to formalize the details of a secure transaction.
TASK 3
To set the scene, you are Bri, a 22 year old girl on holidays in NY, looking to buy a Kitchen Aid for your friend who is hosting you.
So, Bri, you have decided that you want to buy Koko’s Kitchen Aid. She sent you a Let$pay contract for approval, let Koko know you accept the conditions for your transaction. FAST FORWARD. It’s the day of the exchange, you are with Koko at the previously-aligned location and she hands you the Kitchen Aid, which looks great! Complete the transaction with Koko.
NOTE: We ended up switching Jeff for Bri in our last iteration so that we involved our secondary persona as a buyer.
These are the most important insights we got from two rounds of usability tests with our InVision prototype:
After many iterations, it ended up looking like this
But… In the middle of this process we had a brief meeting with our instructors (playing the role of LetGo stakeholders). They really stressed the idea of charging a service fee for every transaction. Our 3% fee over credit card payments was not profitable enough. Since we conjectured from our previous research that people wouldn’t be willing to pay a service fee for every single transaction, we thought that we needed more data to prove so. We sent out a quick survey to confirm our suspicion. And we certainly did so!!
However, we found out that people would be willing to pay a small fee for a secure financial transaction. So our recommendation to our stakeholders was to JUST charge a service for Let$Pay transactions and this would be assumed by the seller since he is the one making a profit. Implementing this service fee, based on stakeholders’ input, would be a next step of our design process.
Some other steps that we considered during our design process that we could implement are:
- Create a system based on completed transactions (a.k.a honored contracts) that would create a transaction history for every user. This would increase accountability and trust
- Penalty fees when contract is broken by one of the parties or the item is not in good condition. This could also be a source of profit for LetGo
- Tutorial enhancement: users really need to know how Let$Pay works in order to trust it!
Our design concept of Let$Pay acting as a middleman between seller and buyer would increase the trust among users. They would have access to a quick and secure payment method. At the same time, stakeholders could contemplate the idea of charging a small service fee when users select Let$pay to complete a transaction. Users seem to be willing to pay this fee in exchange for a financially secure experience.
Ready to let go of LetGo and kickoff my new project!!
