Information architecture study for the design of automated category pages for the Rakuten marketplace

One of the great difficulties of market places (e-commerces that work from other e-commerces) is information architecture. Like Amazon, there are a multitude of competitors with the same project: Selling an immense catalog of products in one place and one of the biggest victims of this business model is precisely the organization of all these items.

Problem

In Rakuten specifically, an aggravating factor was the small number of people managing what was for sale and what should be taken offline. It was not uncommon to find categories with wrong information, bugs on pages, nonsense content hierarchy, or broken links. In short, a small team and a complex catalog always results in a bad user experience.

My role in this small project was the Information Architect. I was responsible for researching and designing the solution that solved both customer and business problems.

In earlier versions of the category pages, there was very little intelligence. Product selection was manually inserted (and removed) from the html. There was no admin to manage page content and in the end we had a slow and error-prone upgrade process. Over time, many categories end up outdated or left out with wrong links and other problems. Also, it is important to note that there was no company interest in building a CMS at that time.

At the same time, the headquarters of the international company began to demand a standardization in the market places, not only in Brazil but in several countries with the brand. So that all had similar functionalities (but adapted to the country in question)

So the only viable solution was to automate the process.

Solution

We propose the creation of a generic template that encompasses the maximum possibilities according to what the user was looking for, so each product category of the marketplace would follow the rules of the template to display the content. We defined rules for categorizing content according to international demands and what users were looking for.

Since there was no way we could test the operation with real customers before construction, the safest solution was to modularize as much as possible. In addition to facilitating implementation (which could be used elsewhere in the marketplace) the modules would be built gradually. Conversion rates, number of pages up to purchase, and metrics linked to the search would guide the decision to keep or remove each one.

The page still contained space for customization. But customization restrictions would ensure that we would have fewer errors and more correct content was in production.

Note: When I left the company, this project was under development. So I have no information about the implementation and results.

Anyway, I believe that we should design the content of massive sites according not only with the use, but also with the ability to produce (and update) correct content and in an intelligent way.

Final Screenshots