Zola Weddings • Vendor Marketplace
Growing marketplace user engagement
An A/B test for sending multiple inquiries in one flow to recommended vendors in Zola’s marketplace
Background
Zola, a wedding startup, has been adding new features to its wedding vendor marketplace business to increase engagement between couples and vendors.
Psst…jump to the bottom to see more examples of marketplace projects I’ve done
Timeline
1 week to iterate on the design and handoff, plus additional rounds of fast follows.
Role
Sole designer working with our mobile product manager and dev team. Cross functional review with vendor business stakeholders
Skills
Competitor analysis, rapid iteration and prototyping, A/B testing, cross functional collaboration/
Introduction
The vendor marketplace business relies on couples inquiring with wedding vendors.
The more viable leads we can send to vendors, the more time and money both vendors and couples spend on Zola. Vendors pay to connect with promising leads, and couples that inquire with more vendors are statistically likely to use Zola for other tools and give Zola a higher NPS rating.
Goal
Build a new feature within the inquiry flow that lets couples choose multiple vendors and rapidly inquire with all. This sprint was part of an ongoing effort to continue to increase the number of inquiries to vendors from Zola couples. Any increase would be beneficial but we were shooting for at least 20% more inquiries on average.
The starting point
We had recently introduced a list of recommended vendors to couples after they send an inquiry.
When couples inquire with vendors on Zola, they have to answer a wedding preferences questionnaire. After submission, we presented them with a list of other recommended vendors (“couples who inquired with this vendor also inquired with”).
This screen was performing quite well, with about 20% of couples going straight into another inquiry flow and 75% tapping to look at another vendor.
The product team decided to build and test the multi-select > inquire capability upon this touchpoint in the flow.
We were excited to build a new type of inquiry that we could hopefully place in other parts of the user’s journey. And this point felt like the right opportunity since users were showing interest in our suggestions. Because the current experience was doing well though, we decided to A/B test the placement.
The Zola inquiry flow at the start of this project
Determining the scope and underlying logic
I diagrammed the updated flow quickly to get aligned on the the scope and logic.
It wasn’t exactly clear what the user would need to do to submit multiple inquiries. Would we allow the user to inquire with vendors who didn’t match their preferences, and therefore, ask them to update their answers? This would open up more vendors to choose from but seemed like too much friction UX-wise.
After bringing the discussion to the engineering team, we chose to only show recommended vendors who matched the users preferences exactly. This meant they wouldn’t need to fix any mismatches, and the tech LOE was about the same for either direction.
Iterating on the design of the flow
Iteration 1: Add an option to inquire with all vendors on the recommendation list
In the first mocks, I did a few versions where users could see a “Get a quote from all” option alongside the individual ones. From there, they’d be presented with a streamline selection screen to confirm which vendors, and then they’d move into finishing their inquiries.
Iteration 2: Present the multi selection as add ons after the user picks a vendor
This next iteration came from a vendor business stakeholder review: Why not present the same screen as an add on after someone chooses to get a quote from any vendor in the list? This means we can show the other vendors at an optimal time, when the user is already intent on contacting one of them, instead of having them choose on the initial screen which was not as natural of a placement.
Final iteration: Replace list with selection as a test
The two steps to getting to send the inquiry still felt a little bulky, and as a team we wondered if replacing the list screen altogether and only present the selections would be effective. However, this was slightly risky since the list screen was getting decent engagement, and the selection step alone displayed less information and smaller images.
Polishing the selection screen design
I looked at marketplace apps to improve the UI of the selection screen
The original mockup I was showing did make use of existing components, but the checkbox didn’t feel like it was calling enough attention to what we wanted the user to do. In addition, we couldn’t fit much metadata.
After looking at marketplace apps like Rover (pet care marketplace), I adjusted the selectors to appear more like large chips and squeezed in a couple more lines of information.
Launch, results, and fast follows
The test variation (replace list screen) won, but we still wanted to improve the numbers
The test variation one by 4% compared to the control, but only increased inquiries by 4% overall. However, we still had other updates and plans in our back pocket to improve these numbers. Our hypothesis, which we had guessed originally, was that there wasn’t enough info for users to feel comfortable jumping in.
Improvements we released over the next couple months
Implement AWS personalize APIs into recommendations engine and increase number of recommendations from 5 to 8
Add ability for user to tap the image thumbnail and open full image gallery
Adjust spacing and font size to accommodate a little more information
(Major update) Allow users to inquire with more vendor matches, which meant users might need to resolve mismatches if present and required error validation designs
Adding a gallery to the image thumbnail
Updating the flow to accommodate mismatches
Final outcomes
The fast follows altogether seriously improved the results with a 22% increase in inquiries sent!
Interestingly enough, allowing for mismatches saw the biggest improvement, likely because users were seeing a greater variety of vendors from before. Adding the thumbnail gallery helped a lot for venues in particular.
Project reflections
Hash out questions of logic early with engineering
It was difficult to picture the flow at the requirements gathering stage because of open questions around the results logic, validation, and mismatching. Talking things out with the engineering team helped us pick the right path to test with first.
Have improvements ready to go if possible
We recognized a few potential areas of improvement early on, but due to timing we wanted to get the experiment out quickly. I started designing the fast follows anyway soon after launch, so once the results came in we’d be ready to kick off more changes right away, and it turned out we needed them.
Team credits
Product Manager: Himadri Narasimhamurthy
iOS Engineer: Louis Tur, Virginia Cook
BE Engineer: Scott Zetlan, Dylan Hughes
Business Manager: Bhavi Vidyashankar, Maya Simon
Examples of other marketplace projects
Bring recommendations into other relevant placements.
I designed this carousel to be added ad hoc around the app. Placing it in the user’s inbox resulted in an increase in conversion across other vendor types, a key metric we were trying to impact.
Research on venue-stage users.
Based on previous tests and insights, I identified venue-stage users as a potential opportunity area. I conducted 5 interviews with users planning their weddings, created a journey map, and shared with Product. We came away with a fresh set of roadmap candidates.
Add review vendors flow and entry points throughout the app.
Zola had not yet prioritized star ratings and reviews at this point, so this was a mobile-first initiative to improve those numbers. Contributed to a jump in user-submitted vendor reviews.
Thanks for reading!