Sarah, 22, works at Tampines. She recently bought a new iPhone and decided to sell her old iPhone in Carousell. Once she listed, she got good offers and some meh offers from few buyers. She chatted with one buyer Jim, and felt it's a good deal and she accepted Jim's offer. The iPhone got immediately reserved for Jim and they closed the deal later offline. Sarah doesn't have to tell other buyers the item is reserved for Jim, and neither does Jim have to worry that if he for sure confirmed a deal with Sarah. Happy, fun marketplace.
How did we help Sarah?
Carousell is a C2C Marketplace app expanding from South East Asia. The product focuses on casual sellers, like people with a day job or school to de-clutter their space by start selling.
Who I worked with?
I closely worked with Alla, The Product Manager, Andrius, The VP of product, and amazing Core-Marketplace Scrum team to make this possible.
Web and Mobile Web.
How Long did it take?
A little over a sprint (2 weeks). We work in sprints, and as a designer, I work ahead of the engineering sprint.
At carousell, our OKRs direct us to focus on one big problem every quarter. One of the problems we choose was inline with Search relevancy.
A small intro on how people buy & sell in Carousell: Carousell is a marketplace where sellers can list their item, and let buyers find it, then they deal and close the transaction offline (at that time). Buyer finds an item interesting, engage with the seller to see if it meets the buyer's expectation, arrange for delivery/meet-up and meet the seller and close the deal. Once the transaction is done, the item is marked as sold by the seller and both buyers can leave each other feedback.
Initial team brainstorm: When we started to work on our problem statement, we quickly realised it's a very broad problem statement.
There are different ways to approach the problem. We explored some possible directions on how we solve the problem and decided to do team brainstorming - One of the ideation process where we start in the beginning of the quarter where everyone in the scrum team, engineers, designer, PM, EM brainstorm on possible directions and come up with as many solutions as they can in short time.
One such direction is to hide listings of items which are likely to get sold.
Team brainstorm stresses on the point that ideas can come from anyone and not just from product people.
During our quantitative research, we found out that buyers engage with sellers, only to get disappointed by sellers saying the item is reserved for someone. Because of the nature of the transaction in carousell, sellers and buyers often wait to meet at the convenient time to finish the dealing in case of the meet-up. During this interim period, there are a lot of listings which were about to get sold, still shown to thousands of buyers.
We observed that users tend to mark their items as reserved by editing the title and adding some notion that it's reserved. This is one of the time I felt that most users are smart and they actually start applying smart solutions to their problems, ahead of us. Our initial research validated this problem and the direction we are taking to solve this problem.
How might we framing: Based on the research, we ideated on one possible
how might we? question that directs us towards a solution.
The solution by definition also helps buyers to find relevant listings, where those sellers are likely to close the deal. How might we questions are the easiest way to not jump to solution, but still be open minded about what's the best possible way to solve it.
Mapping Listing states
Based on our flow about how buyers and sellers transact inside the platform, the state diagram for listings goes similar to this.
User journey mapping
I mapped out the journey for sellers and buyers to see how might we enable reserved state in the flow
When we begin iterating on this definition, we found ourselves converging with ideas for both user journey.
When we begin iterating on this definition, we found ourselves converging with ideas and increasing the scope of the solution.
Our initial solution covered for both sellers and buyers. Since reserved state is a state change for the listing from active to reserved, our original version of the solution was defined in a way of effective communication between sellers and buyers to show transparency and commitment. The underlining theme is that both buyers and sellers are notified when the listing is reserved.
A seller cannot be accepting offers from a lot of people if they have only one item. So the initial idea also revolved around tying up the reserved state to only
When I finished the wireframe and estimated the effort to implement, it felt like a huge project and heavily relying on managing different states for different users.
One of the best parts about working with the product manager is the focus they bring in to the ideation process. When we converged to solve the problem, we also tried to solve transparency and commitment as part of this solution. While those problems are real, it might be just a baggage for us to solve for now. So we went to the drawing board again and saw what is crucial to the journey and mapped out this journey.
How items gets reserved?:
When the seller accepts an offer from buyer, we auto reserve the item. This state change might require some understanding for users, so we prepared a elaborate on-boarding for the users.
Buyer backed away or deal didn't go well? Sellers can unreserve anytime. The quick chat actions give the way to unreserve the item anytime. Sellers can also unreserve the item from the edit listing page available for each listing.
What happens after an item gets unreserved?
It goes back to the marketplace and continue to wait for new offers and chats
When an item gets reserved, the item needs to look different to give a cue that it's not sold, but not available too. I ideated on this problem to come up with a visual design for Reserved State.
How Reserved state looked in various important parts of the app?
But being reserved for long time is not sold. We nudged them to act on their reserved listing. A reserved listing is a sitting duck. We used push notifications to remind our sellers to make decision. Since there could be more than one listing that was reserved, we decided to take them to the profile page where they can see all the listings.
We tried to design this solution with casual sellers as our target audience. We realised this feature might affect our merchants, who are selling a lot of units through one listing. We gave these Merchants a way to opt out from settings!
Validation - User testing
I did a small user testing with five internal users at Carousell. I mocked up ahi-fidelity marvel prototype to see how sellers feel about item getting auto reserved. Among them were few users who were both buyers and sellers, so they gave me valuable feedback from both standpoint which was interesting and also something I learnt about internal user testing — Users tend to have more experience with the app, than an ideal user, and as much as possible, do actual user testing.
Based on that valuable feedback, I went and iterated on the design. There were few details that were not clear, so I iterated the copy and made the design much more understandable with a better on-boarding.
Conclusion and observations
The launch was quite big, because it affected all markets and pretty much all users. The number of cases we need to test during QA was pretty huge and we were super overwhelmed by few edge cases we missed. Never the less, it was a significant update to our users and the one that made a huge impression on that quarter's OKR!
How? Reserve state moved the listings out of the marketplace faster. Because of this, the issue of buyers finding a listing that's reserved for someone else just disappeared. Buyers are getting less disappointed and sellers continue to get exposure and value!
Few positive observations:
- Sellers and buyers feel more committed when the item is reserved. This built more trust into the community and marketplace.
- Reserve state marks the beginning of the end of the transaction. There was a sense of delight to see item reserved. There is an anticipation of money and there is a closure of decluttering. I was happy to hear these interesting points during a different user testing sessions
- Having more Yellow(Reserved) or Red(Sold) badges in listings on Seller's profile page have an effect on their credibility.
Few negative observations:
- Reserving is not still committed enough. Reserve state doesn't fix all the offline behaviours of buyers and sellers.
- Items stay reserved until the seller comes back to that listing or chat. The journey I designed lacked the nudge that makes the seller come back and mark the item as sold
Case studies from my work & fun Projects