Catalog admin

Cutting a catalog update from 80 edits to 1 by redesigning around how the business grew

Global beverage company (NDA) · 2023 · 3 weeks

Product and category management had been carved up between two teams and two products, and the catalog architecture copied the whole product for every seller. I led design on the project, briefed to unify the two tools and make a new architecture of variants and items workable.

Context

I led design for two admin products inside a B2B marketplace that today serves 2.1 million buyers across 30 countries: the product manager and the category manager. A design assistant worked with me, and I supervised her on this project. Splitting those two products had been a business decision made before I arrived, and what I saw was that it had also cut our users' work in half.

We talked to users from a lot of countries, across the Americas, Europe, Asia and Africa, and the same faces kept showing up in both applications. Registering a product and placing it in a category worked like this back then:

A flow diagram of one operator crossing two applications to publish a product: creating it in the product manager, leaving the app, categorizing it in the category manager, and only then reaching the catalog.

The curious part is that nobody reported this as a problem. They had gotten used to it: after enough time, two tools sitting on the same task start to feel like two separate worlds, even though every conversation showed they were one flow.

When we asked what could be better in either app, they always named something small and local, like more filters or bulk editing, whatever would shave time off the day.

The business wanted to scale; the architecture we had did not

The catalog architecture we had could only tie one product to one seller. When a second seller wanted to sell the same thing, the way through was to duplicate the entire product and change the seller fields (seller ID, SKU). One country ended up with 80 sellers offering the same catalog, which is how we got a database listing more than 20,000 products while we actually sold fewer than 300 different ones.

A product list in the admin tool showing the same product repeated row after row, one per seller, each copy differing only by seller ID and SKU.

Now picture updating something general on that product, like the name, the photo or the category. It was expensive and it was risky: every copy was one more place where the data could drift.

The project only reached me when the board closed the expansion into new countries and onto partners with CHF 94.4 billion in annual revenue, a 2022 figure. A new model stopped being about cleaning inconsistencies or relieving the database: it was the condition for taking on partners with catalogs built at that size. The whole platform was migrating to a new design system at the same time, so it was a good moment to change something for real.

The board's requirement was specific: move from product as a single entity to what the biggest marketplaces (Amazon, Shopify, Mercado Livre) already do in their own way, which is product, variant and item.

Product — what is sold, no matter who sells it: name, description, brand, images. It exists once in the catalog.
Variant — a version of the same product that changes one measurable attribute: size, volume, color, flavor. Still the same product.
Item — the link between a variant and a seller. Price, seller and stock live here. Two sellers offering the same can are two items of the same variant.
Attribute class — the group of attributes that describes a type of product: width, weight, height, flavor. It changes with the product, and it was the only one of the four that already existed.

In our case every product needed at least one variant and one item before it could be sold. Rebuilding the architecture was only half of it: someone had to work out how the experience would follow the model. That part landed on me:

How do I make the user's life easier while I introduce more complexity?

The Bet

I bet on Tesler's Law*: this complexity was not going away, so I made the architecture carry it.

*Tesler's Law, or the conservation of complexity, says every system has an amount of complexity that cannot be reduced. It does not disappear, it only changes sides: either the system absorbs it, or it lands on the user's lap.

Product, variant and item were the irreducible part, because the business needed all three. The question left for me was simple: who was going to carry it.

How

I started by listing the entities that would now live in the same application, and the scope of each one.

Read it by color: every screen in the site maps takes the color of the entity it manages. The old tools, PIM and Category Admin, sit above the entities, and Catalog Admin sits below.

Then I picked the flows that mattered most. I had room to run the project the way I thought made sense, including how to split the fronts with the design assistant:

Product list
Product details
Variant details
Item details
Product creation
Category list
Category details

Before drawing a single screen, I went to look at how product registration works in Amazon Seller, Shopify and Mercado Livre. Not for the visuals, for the path.

A FigJam board comparing how Amazon Seller, Shopify and Mercado Livre walk a seller through creating a product.

One disclaimer matters here: our users are not their users. A zone or country representative on our side can manage categories, attribute classes and a good deal of product information. On a big marketplace, the most a seller can do is register a new product, sometimes categorize it, or announce that they are offering something the catalog already has.

Last, I settled on the principles that would guide the project:

Keep what works
Introduce complexity gradually, and only where it is needed
Make the new product structure talk to the categories

Proposal

Adding variants during product creation, after the redesign.

Before, one attribute change meant 80 copies to keep in sync. After, one.

That number is arithmetic of the model, and anyone can reproduce it on a database with duplicates. It did not come from production telemetry. What shipped alongside it: PIM and Category Admin became one tool, registration and categorization started happening in the same place, and the list got the filters the zones had been asking for.

It went live in 2024, behind a feature toggle, country by country, with gradual migration. I left the team during the rollout, so I do not know how far it got, and I would rather say that than estimate. Price stayed in another application: what came out of our flow was a product created and categorized, not a product ready to sell.

Reflections

I would build a global search. We were centralizing a lot of information, most of it nested, and the more you nest, the longer the walk to whatever you came for. A global, elastic search bar would let someone land on a category or a variant without navigating the interface at all, the way Slack, iOS, Google Drive and even the photos app on your phone already work.

If it were today, I would dissolve the item into the sellers: keep the three entities in the database and show the user a single action to link a seller.

I would rethink pushing the rule that every product needs a variant all the way up into the experience. Most products would have exactly one, which is a strange thing to call a variant when the word itself promises variety.

And I would go further down the product's path. Created and categorized was not the end of it: price still had to be added in another application. Out of scope or not, it would have been worth investigating whether we could bring price, and the other things that quietly affect the catalog, into the user's view.