Letgo
A firsthand account of feature integration for a secondhand marketplace app
Background
Our stakeholders briefed us to facilitate the safety of in-person transactions by allowing buyers and sellers the option of in-app payments. They mandated:
Project Length: Two Weeks
Teammates: I collaborated with Will Cruthers, Evan Tyerman, & Inma Varandela.
Tools:
Methods: Mind Map, Screener Survey, User Interviews, Empathy Map, Affinity Map, User Personas, Problem Statements, MoSCoW Matrix Feature Prioritization, User Flow, Low-Fi & Mid-Fi Usability Testing.
My Roles : Researcher, Interviewer, Designer, Copywriter, Tester.
Initial Assumptions
The first step of my team’s discovery process was topic mapping, which helped us generate the following initial assumptions about Letgo and its users:
(1) people used letgo to get rid of clutter and/or unwanted items
(2) people using letgo were on a budget
(3) users might have issues trusting the second party in an exchange of goods, regardless of if they were the buyer or seller.
User Research
To assess and build on our aformentioned hypotheses, we generated a survey screener to recruit participants and conducted 6 interviews to understand how and why letgo users behave, think, need, struggle, and feel about buying and selling secondhand goods.
Interviewees: Age 23–34, 5 females, 1 male.
We were intentional about learning as much as we could about each user, beyond secondhand goods, as this would help us develop a rich persona and truly empathize with the people we were designing for.
Synthesis
Affinity mapping allowed us to mine insights and key user behavior patterns, including:
(1) Lack of trust for second party
(2) Inability to guarantee second party’s accountability when making a transaction, both for quality of item and actually showing up to make an exchange
(3) Frustration with time spent communicating with the second party to coordinate a sale
(4) Budget-consciousness while shopping.
User Personas
We extracted key insights and common behavior patterns to generate two primary user personas:
“I don’t think of things as pre-owned, I think of them as pre-loved” -user
Problem Statement
To narrow our design focus we crafted a problem statement around our insight and persona’s problems and goals:
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?
Now, we were ready to start ideating!
Ideation
We conducted two Design Studios. In each session we:
- Identified user scenarios to define the problem
- Diverged and sketched solutions individually
- Pitched ideas to the group
- Critiqued group members’ sketches
- Iterated and refined initial sketches, “borrowing” the best ideas generated by the group
- Converged sketches into “best solution”
Our two Design Studios yielded myriad features, which Prioritized on a MoSCoW Matrix. Priority was expressed as a function of how essential and expensive each feature was:
- M: Must have this requirement to meet business needs
- S: Should have this requirement if possible but project success does not rely on it
- C: Could have this requirement if it does not affect anything else in the project
- W: Would like to have this requirement later but it won’t be delivered this time
We were diligent about keeping both user and business goals top of mind as we conducted feature prioritization, which also helpd us avoid “featuritis.”
Design Concept
We heard from users they were comfortable with electronic payment IF there was TRUST. So, it was imperative that our design concept helped build user trust. To do this we setup Letgo to act as a middleman between buyers and sellers who were executing digital financial transactions.
We named this new feature let$pay.
Now that we had aligned on how best to prioritize features to support our design concept, we developed a user flow so we could begin sketching low-fidelity paper wireframes.
Testing, Testing Results, and Iteration
Paper Prototype Testing
2 out of 2 users completed the assigned Task Scenario of going from the Letgo chat feature into setting up logistics of a transaction, playing the role of the seller, Koko. However, we found a few key steps of the process were unclear and took users extra time to navigate or were misinterpreted.
Screen 1
- Added “Send” button to be consistent with Letgo chat screen. In testing, users reported that the only obvious action to take was to click “Next Steps.”
- Added “Deal” button to move from messages into coordinating exchange logistics.
Screen 3
1. Changed “paid via” to “payment method” as “payment via” refers to how users chose to link their let$pay account to their bank or credit card, and this information would not be shared with the second party. the terminology “paid via” was also confusing to users.
2. Split bottom “send contract and calendar reminder” button into two serparate buttons as each has a unique functionality. We opted to move the “calendar reminder” to the next screen as it had a recap of the contract logistics.
Screen 5
- “We’re sure he’ll agree” language did not instill confidence in users that the buyer would accept the contract. Replaced this with more matter-of-fact copy, “Your Contract Was Sent to Jeff for Approval” so it was clear to users they had just completed the task of sending a contrac tot he buyer and were awaitng buyer’s approval of the contract.
- We found this a more intuitive screen to add a calendar invitation feature to because it could be placed next to contract details of when and where users were going to meet up to make the exchange.
Mid-Fidelty Testing
We created a digital prototype using Sketch and Invision and has users repeat the same task scenario from the paper wireframes. 5 out of 6 users completed our task scenario and understood the concept of the let$pay contract. However, as they completed the task, users reported they didn’t fully understand the let$pay process and, more specifically, the role letgo played as a middleman in electronic payment transactions between buyers and sellers. We iterated our design, focusing on developing a tutorial to more simply and clearly explain to users the logistics of the let$pay process.
In the second round of mid-fidelity prototype testing, users were introduced to the let$pay tutorial. 3 out of 4 users understood the concept of let$pay. However 2 out of 4 users did NOT chose let$pay when given the option of selecting a payment method, citing a lack of trust for this new system that required them to link their credit card and/or bank account. We iterated our design, focusing on building user trust.
Additional Research
Our stakeholders’ brief mandated a service fee on ALL transactions. However, based on our user research, my team hypothesized that this would be problematic, especially for CASH transactions. We developed and deployed a survey to over 30 users who told us:
(1) They’d be unlikely to pay a small service fee on ELECTRONIC transactions:
(2) They’d be even more unlikely to pay a small service fee on CASH transactions:
(3) They’d be more willing to pay a fee to ensure a secure financial transaction:
Based on what we heard from users and with their best interest in mind, we recommended to stakeholders that they implement a service fee ONLY on let$pay transactions, caveating service fees would deter some users, regardless.
Prototype
Next Steps
Our team recommended further iteration and usability testing after aligning with the stakeholders on approach for implementing service fees. Areas of design to focus on include a user rating system and penalty fees, both of which would help instil accountability in both buyers and sellers, as well as tutorial enhancement to assess users’ trust level of the new let$pay system.