Product Variations for Sellers

Product Variations for Sellers

SaaS, E-commerce

Variations is a complex project that I arrived at the most complex state of its execution. By applying conceptual design and progressive enhancement, we managed to improve some of the incumbent model.

The Incumbent State

The legacy architecture of Mercado Libre's parent-products was a pretty standard one: One product, different variations of the same product (color, size, fabric, etc). This is a model which generally matches the real world: you buy a sneaker and you choose the size and color, but same product.

Problem at Hand

This legacy architecture changed in 2023. The business goal was to clear stranded stock or add different pricing strategies for specific sizes or colors. So, now Color A / Size 1 was a product itself, Color B / size 1 was anotherone, and so on. This new architecture was similar to how Amazon works. But the tradeoff was that it triplicated the number of listings and tasks that sellers needed to manage. That's when I arrived to the project.

Challenges emerged from the problem

01

Mental Model Overlap

02

Broken Findability

03

Wrong UI

04

Increased Workload

05

No recovery

Challenges emerged from the problem

01

Mental Model Overlap

02

Broken Findability

03

Wrong UI

04

Increased Workload

05

No recovery

Challenges emerged from the problem

01

Mental Model Overlap

02

Broken Findability

03

Wrong UI

04

Increased Workload

05

No recovery

Framing the problem

My aim was to tackle this as a mental model issue, not just a design or UI problem. The error was to completely change a mental model that matches the real world for sellers and buyers. So, my take was a middle ground: keep the original mental model but start slow and incrementally to a set of controls (UI) that served the business.

Conceptualization

Making sense of both mental models was key to understanding where we could dial back and where we must push. The original mental model (slide 1) was a strong foundation to come back to. Meanwhile, the new model (slide 2) was clearly a more complex structure, just by looking at it.

The Designed Solution

My approach was to solve the problem by going back to the original model. That meant the interactions and the visual hierarchy where as close as the original mental model, but adding little controls or UI expressions to the original state, serving the business. It was the opposite of the first iteration.

The Original Mental Model

You can see now that the original version of the listings management was a close resemble to the real world. One product, one selling price and different colors or sizes. Of course, this had limited capabilites for the business.

The First iteration (the one that needed fixing)

This design was an approach to make independent products out of each variation in order to assign specific pricing, shipping or promos to each color. Although this helped the bussiness, it dramatically increased the user workload, findability and learnability.

Our solution was the middle ground

Our approach was to return to the parent-child mental model, but adding controls for flexible pricing strategies. We nested again the colors to a single identifiable parent, and added slow and simple actions such as adding price, free shipping and more features.

Outcomes

Adoption grew from 9% to 27% of eligible sellers, including Nike. Rollout stabilized enough to ship to new markets and categories. CX inquiries remained elevated, probably because two coexisting models continue to create friction, particularly for small and local sellers.