After rebuilding our serving platform and templates to get a cleaner, more flexible baseline, I designed a set of A/B tests and tracking enhancements to make sure that the UI we had built was the right one, and begin moving our project goals from pure financial results to solving user problems: finding the right item, finding the right version of that item, or starting your next mission.
I also began improving our partner experiences - once kicking off a rebuild of our email product: when asked to increase email engagement with march in email, we used a basic UX strategies to reveal (and fix) glaring issues that no visual design could solve alone.
A true story: I was hunting for some soccer cleats. I knew the brand (Adidas). I knew the model (X15.1). I knew the size (13). But which garish color was for me? (Spoilers: Lime green & black). That’s a fairly common shopping path for users - if they don’t come to eBay knowing the exact item, they come knowing something close and bounce between search and item pages. Rather than try to change user behavior, we designed a recommendations product to complement this behavior.
To get started, we knew that we didn’t actually know why the user viewed an item. We could infer it - but we didn’t really know. So, our first attempt tried to take the top 3 aspects for the item you’re viewing, and provide recommendations with aspect-value pairs as keys. It didn’t work - we simply didn’t have the structured data to surface this often enough in more than 1 or two categories.
However, when it did surface, it outperformed the existing content. Later, with a dedicated engineering team, we developed a strategy for generating recommendations - finding multiple values for the aspect most likely to be variable.
Our next iteration would involve multiple groups of multiple values in a mobile-optimized UI. We already new the existing pattern of tall, stacked grids at the bottom of the item page hurt us. Our different recommendation groups all blended together, if a user saw them at all. We knew our carousel pattern worked on desktop - users would scroll and engage with the larger recommendation sets; we knew that placing the right content at the right decision points (similar items below the item details to enable comparison, for example) would provide benefits that outweigh any negatives.
Next, we enhanced our carousels with buttons that would add additional rows of recommendations to the page, iterating to see what was possible (both legally and technically) and practical.
In prototypes, this worked great but in reality, the in-app performance was poor - too slow, too jumpy, and memory intensive. Our launch product focused on using our standard button style to toggle the different content sets.
The first priority of eBay’s post-purchase experience is to confirm your purchase. Otherwise, if the user is going to stay on eBay, our priority is to give our users direction to their next purchase. Yes, the user can begin a new search – what if they don’t already have something in mind?
The most important content derives from a simple reminders – if you’re already expressed strong interest in an item (but haven’t bought it or something similar) we offer a reminder. From there, we begin recommending items complementary to the item(s) you just purchased, our next most relevant key. Then we dig into past history – previously lost items, purchased, or watched items, before looking at browsing history. We tested UI options and content combinations, prior to settling on a set of recommendations that would be triggered based on user behavior, arranged by relevance and rarity.
Most users never see the entire set - but enough people see enough recommendations that we were able to increase our key financial and behavioral metrics on a page traditionally thought ‘too minor’ to matter.
In 2017, the merchandising team began working on eBay’s first algorithmic bundling product. I worked with product managers and developers to create a baseline experience - setting requirements and targets for what we recommend to users. As we’d never done anything on this sort of product, we knew we could create a decent baseline UI, but we had no idea what problems we’d generate while doing so.
Our initial mockups were really meant as conversation starters and reference points so we could have a discussion with users about what they actually expected in a bundle product, both from a UI perspective, and a recommendation perspective. What follows was created for a UER session with Australian users.
We focused on asking, "What makes a bundle valuable?"". What are basic expectations around sellers, condition, discounts, types of items/bundles (true accessories, or just frequently bought together, like collectibles).First, as expected, trust would be a huge issue: Who recommended these items? Why? Are they any good? Second, we began to form a starting point for bundles - most people expressed interest in items that were a true ‘accessory’ relationship or were critical for use with the original item (i.e. a PS4, controller, and a game, ice cream maker and supplies, etc) - especially if there’s not a specific discount or deal associated, and items needed to be immediately recognizable - which was a problem with the recipe book.
We learned a few other things about what made a good bundle - they generally expect the same seller, but as long as they arrive together, it’s not bad; additional items had to be cheaper and not double the total purchase cost (this was controversial, believe it or not), and condition mixing was regarded as extremely weird by shoppers.
And we learned a little bit about fitment: peopled assumed our recommendations fit 100% of the time and wouldn’t think to verify that compatibility, even in options where we didn’t have an explicit label - which sets a very high bar for a commerce experience that doesn’t have a universal compatibility table. So to revisit the question of ‘What could go wrong?’ – a while a 64GB SD card might be passed up in favor of a 128GB card, it doesn’t hurt eBay to offer it. But if we recommend a Canon lens for a Nikon camera - we look like idiots and destroy faith in the product.
We did a second round of UER in Germany looking at advance concepts for a multi-year goal, where we specifically targeted automotive users because these are complex, fitment-critical cases. In the worst-case scenario, instead of just looking dumb, we could actively cause significant injury or death.
First: Will users customize a bundle? We would always build de-selection into our UI. If you’re shopping for a PS4, and we recommend the latest Madden game but you’re more of a FIFA or Destiny fan, the cost of being wrong is pretty low. It would be better if users could select the right game then and there. This mockup was from a test with automotive users so it was more about the supporting the task at hand or the need for tools/consumables.
We also wondering if user would consider multiple bundles, and what level of information was required to understand the true differences between them? In this case, we studied seller provided bundles with discounts vs multiple task based - trying to find the breaking point between useful and interesting vs aggressive overload in terms of page presence and bundling info.
We had seen two other pieces of feedback previous: we were cluttering the item page with modules and users occasionally felt ‘pushed’ - before they were even sure they wanted the item, we were trying to get them to buy more stuff. So we proposed using overlays to supplement the success messaging, with varying degrees of invasiveness. We never really considered 3 or 4 as viable. We really were trying to provoke a reaction from users. It turned out though, that users were comfortable with a full screen overlay after a direct action, though the content in both 3 and 4 was too aggressive.
For our V1 product, we evaluated 2 UI patterns for mobile. First, we explored inline expansion, which was a minimal-info version.
We also explored a bundle-specific screen that would show far more information, and better support a ‘triggered’ placement. We initially went with the latter UI for EU legal compliance reasons, but what you may see in app is closer to the first UI.
This is a mockup of the EU desktop UI, which had additional text & legal requirements. This is similar to what you might see on-site, though like mobile, it’s undergone some re-skinning and tweaking as things have changed.
This was an alternate desktop UI we were exploring, which would show additional details if trust became a significant issue (likely not at the top of the page).