Designing Vestiaire Collective’s private messaging feature
Our journey to enable our community with a safe user-to-user chat.
What is Buyer-Seller Chat?
Are you a fellow user of the Vestiaire Collective app? In that case, you’re probably used to checking your messages in your notification center. Internally, we call this space buyer-seller chat.
Buyer-seller chat is Vestiaire Collective’s private messaging feature on desktop and mobile. It is the go-to place for buyers and sellers to communicate about products for sale and orders in progress. Since its early days, it has become a key feature of the experience to boost transparency and conversion.
Our teams completed many design and development iterations to make the chat as safe and user-friendly as it is today. This article will shed some light on how we came up with the solution that is now live on Vestiaire Collective.
We hope you’ll take away some useful lessons from our failures and successes for your own projects.
So without further ado, let’s get started!
Defining the needs
The private messaging feature is one of the most critical features that Vestiaire Collective launched in 2020. Our members had been in need of this kind of feature for a long time.
Restricted interaction capacities
Before buyer-seller chat became available, our members had to use the comment sections on product pages to ask for more product details. The flow was a bit cumbersome. Plus, real-time communication was impossible for comments moderated by our teams.
The other way our members could connect was via our negotiation rooms, called Make Me An Offer (MMAO), which allow our buyers and sellers to propose discounts on their items. Here again, members were very limited in their interactions because they could only exchange prices.
Business challenges: staying competitive while maintaining our safety standards
Most Marketplace platforms offer a private messaging feature as their primary interaction tool. Consequently this became an expectation for all users, and not having it put us behind in terms of feature parity.
Another concern was the risk of marketplace circumvention. The role of a marketplace platform is to allow safe transactions and to protect both sides of the platform. Sellers need to be paid and buyers need to receive the item they paid for.
Multiple questions remained that we could not answer unless we launched the new chat to market:
- Since Vestiaire Collective is a global platform, could it limit the risk of people taking their trades outside the marketplace?
- Vestiaire Collective’s average basket size is significantly larger than the competition. Would selling out of the platform be consequently riskier for both our buyers and sellers?
- We provide control and authentication of our products. Shouldn’t that be a sufficient reason to keep sales on the platform?
Product challenges: UX coherence and efficient development
On top of those business questions, we also ran into product development challenges in developing such a feature without going for a complete revamp of the app:
- How could we make our Make Me An Offer feature coexist with a private messaging feature?
- What control mechanism should we implement to monitor potential marketplace circumvention?
- Should we build the entire feature in-house or use a third party?
The design phase
One of my favorite quotes that I remember from my design class is, “a good design answers the brief”. For this project, the brief was “to allow buyers to start a chat and enable sellers to answer a chat without touching a single piece of the current Make Me an Offer feature code.”
The requirements immediately put challenging constraints on the design team, which was already considering blending the two experiences. Blending the experience of chatting and making a price offer would make perfect sense if we had to build the feature from scratch, but that would have led us to touch so many pieces of our architecture that the project would have taken months.
Funnily enough, what we thought was a constraint actually ended up being an important feature. Dissociating the Make Me An Offer feature from the private messaging feature would allow us to enable one or the other for different users and be more nimble in deciding certain rules.
The technical solution
While our design team was working on the mockups, our engineering team and our product manager looked at third-party solutions. As exciting as it sounded for the engineering team to develop such a feature, we also had some expectations regarding time to market and were convinced that finding a backbone would help us gain time.
We decided to shortlist two vendors and spent two sprints building a basic proof of concept with the providers to decide which one would be the right solution to create a feature that we knew was likely to stay for a while. We definitely did not want to choose the wrong architecture, so we gave the time to our Front end, Back end, and Mobile engineers to play with the solution and decide which option they would feel most comfortable building on.
We based our comparisons on the following characteristics:
- Scalability
- The coding language used
- The available features
- The reactivity of the third-party tech team
- The price of the solution
A few months after launching the feature, we were very happy about our decision and, more importantly, about the process we put in place. When working on such a project, it is essential to obtain approval from all stakeholders, so everyone feels engaged in delivering the best product possible.
This was also a good example of how important it is to deepdive on all the technical aspects of a third-party partner. A private messaging feature can potentially deal with thousand of messages simultaneously. The coding language of the service is important in order to make as much of a saving as possible on IT infrastructure. Any increase of load on our partner infrastructure would inevitably result in additional costs on our side. We would be tied to a partner that couldn’t scale without impacting our ROI. This could be the topic of another post: how infrastructure cost is often forgotten when designing a feature or engaging in commercial activities.
Focusing on the most impactful KPIs from Day 1
As with every new product initiative, setting the proper KPIs is the first step to success. Within Vestiaire Collective, we tend to have different stakeholders for initiatives impacting our daily active users or conversion. Since such a feature could impact both engagement and conversion, it was even more vital for us to define the key metrics we would follow up on to iterate on our MVP. Do we want to create a feature that brings buyers and sellers back to the platform on a daily basis? Or do we prefer to optimise it to help sellers sell faster?
We settled on two main success metrics related to conversion: the adoption and success rate, which we defined as follows.
We also built a monitoring dashboard to examine proxy metrics that helped us monitor marketplace circumventions. One good example is the number of products taken off the platform after a chat was started.
We were ready to launch our product iteratively and be aware in real time of how it was impacting our business positively while making sure we were managing risk.
Managing the risks
As described above, launching this product was planned to bring value to our users while simultaneously introducing the risk of more transactions happening outside the platform.
We ran a few brainstorming sessions with our engineers, designers, product managers, and business stakeholders to consider the different options to manage this hazard.
One might think that bringing added value to users would encourage them stick to the platform and prevent sales from happening outside of it. However, we could not preclude this from happening to some users. Not only are circumventions a source of revenue loss for the company, they are also a threat to our members, who trust us as a safe and controlled marketplace.
Making a transaction secure and preventing counterfeit products from being sold on the platform is the core of our business. Therefore, we started to think about a few features that would at least create a safety net to prevent misbehaviour.
Dictionary search
The first one we put in place was a dictionary-based flag mechanism. Here is how it worked in a nutshell:
- A user wrote a message
- Our algorithm checked the message against a dictionary of inappropriate words
- If we detected unacceptable words, our solution would remove the input and replace it with a statement explaining the reasons.
The first iteration relied on quite a strict dictionary. It evolved manually and we later added a layer of automation to make it smarter at catching the most inappropriate words in every language while allowing all appropriate messages to go through.
This dictionary became the backbone of more features that we then started to add.
Automated user bans
We began to ban users who broke our guidelines multiple times and automatically sent emails to educate them about the good practices around using our buyer-seller chat.
Reporting harmful messages
We also included a report option. We were very positively surprised about the number of members from our community who were proactively denouncing misbehaviour. They significantly contributed to helping us strengthen our engine and making our private messaging feature safer and safer.
As stated before, keeping the chat separate from our Make Me An Offer feature enabled us to turn it off for given users while still allowing them to make and receive offers. Merging the two features would have made that more complicated. This was an excellent example of how a constraint can actually turn into a nice feature.
Conclusion
We opted for a canary deployment strategy, releasing the update incrementally to ever-growing subsets of users starting at the end of summer 2020. Two years after the launch, up to 25% of our transactions are already happening with a private message. On the other hand, the number of conversations that we judged inappropriate was below 3% at the time of the launch. As a result, buyer-seller chat proved to bring more benefits than drawbacks, and our sellers praised the feature as it made them more likely to sell.
Ultimately, this confirms that solving a user’s problem and making their life easier should drive every product development process.
What do you think we should add to this feature?
If you have any questions about our processes and how we made it happen, feel free to drop us a comment.
We are always on the lookout for product folks to share the ride. Visit us here.
