An easier way to list on marketplaces: -45% tickets

DISCLAIMER: Sorry, dear reader: the project is real, but this text was written by AI and it's a pretty boring read… I'm rewriting my case studies with my own two handz, I just can't leave this page empty. It's still a great case — just a bit dull to read.

Role: Product Designer

Responsibilities: Discovery, product definition, prototyping, usability testing and handoff

Impact: ~45% fewer support tickets related to listing creation | 100% success rate on the main usability test task

Timeline: ~3 months (Q1 2022 — Discovery → Testing → Beta)

Team: Michel (Product Designer) + Product Owner + Customer Success + Engineering

Context: Ideris — a marketplace hub that connects sellers to 25+ marketplaces to manage inventory, sales and listings

The Problem: A Flow That Generated More Questions Than Listings

In the first quarter of 2022, the listing creation process on the Ideris platform drove a significant increase in support tickets — accounting for 65% of tickets opened in January and 69% the following month.

Together with the CS team, we triaged these tickets and found that the overwhelming majority were related to unsuccessful attempts to create a listing. The most common errors shared a root cause: information filled in incorrectly by the user, which the platform neither prevented nor flagged.

In other words, the problem wasn't the user. It was the platform that didn't guide the user.

The Gap: Platform vs. Marketplace

Together with the PO and the developers, we mapped the minimum requirements to create a listing. The comparison revealed a clear misalignment:

The platform required more steps than the marketplaces themselves — and spread those steps across different places in the interface, with no logical sequence.

Interviews: Confirming with the People Who Use It

To understand how sellers actually operated, we ran interviews to map their pain points. The findings were revealing:

Main pain: Difficulty completing all the steps required to create a listing — with creating and mapping categories and attributes being the step with the most friction.

Unexpected behavior: Users created listings directly on the marketplaces and then imported them into Ideris just for inventory control. In other words, they were using external tools to work around the platform's difficulties.

Overall sentiment: Users felt lost, with no consistent information architecture to guide them through the process.

Synthesis: 3 Core Problems

After the discovery phase, we consolidated the findings into three main problems:

1. Confusing usability — Too many required steps, scattered across different parts of the platform, with no clear logical sequence.

2. Silent frustration — The platform didn't communicate whether steps had been completed correctly, and at the end of the process the listing simply failed — without explaining why.

3. Escape to external tools — With such a difficult process, sellers created listings outside the platform and only used Ideris for inventory management — a churn risk and an underuse of the product.

The Strategy: From 6 Fragmented Steps to 1 Unified Flow

What we had before

To create a listing on the platform, sellers had to complete 6 steps on different screens, with no indication of progress or sequence:

Each step had its own complexity and requirements. Sellers had to know, on their own, that "Create Category" came before "Map Category", that they needed a "Listing Template" before creating the final listing, and so on. There was no guide, stepper or progress feedback.

Aligning with the Team

After analysis and discussion with product and engineering, we defined that the solution had to meet three criteria:

1. Eliminate unnecessary steps — The new flow shouldn't require creating categories, attributes and listing templates separately. The number of processes had to drop drastically.

2. Prevent errors at the source — The system should ensure information was filled in correctly, making it impossible for creation to fail because of user errors in required fields.

3. Be easy to learn and use — The experience should remove any need for sellers to look for alternative ways to create listings outside the platform.

Trade-off: Speed vs. Scope

One point we discussed with engineering was the scope of the refactor. Redesigning the entire flow at once would mean a months-long project. The decision was to focus first on the listing creation flow — the most painful part for users — and iterate on the earlier steps (category mapping, template) in later phases.

This let us deliver value faster without compromising the quality of the core solution.

Development: Two Proposals, One Decision

Exploring Paths

With the criteria defined, I designed two solution proposals:

Aligning with the Devs (Before Testing)

Before investing time in usability tests, I aligned with the development team on the technical blockers and complexities of each proposal. This step was intentional — there's no point in testing something that can't be built in time.

Engineering's feedback showed that both proposals were feasible, but the step-by-step version had a technical advantage: it enabled per-step validation, reducing the chance of sellers reaching the end with incorrect data — exactly the problem behind the tickets.

Based on that alignment, we decided to write the test script for the step-by-step version.

Usability Testing

Sample: 8 strategically selected customers:

• 4 representing the profile that sustains MRR
• 1 with the highest average ticket
• 1 random customer
• 1 user of the platform's legacy version

The test was split into 5 tasks:

What the tests revealed

Despite the high success rate on the main task (100% on listing creation), we raised 2 points of attention that led to adjustments:

1. Image selection — The proposed model broke the flow users were already used to from the old listing template creation. We had to adjust the interaction pattern to reduce the learning curve.

2. Navigation between steps — We identified the need to add explicit "continue" and "back" buttons, to avoid accidental input in the wrong steps.

The Final Solution

The solution focused on guiding sellers through each step of creation, so they only concentrate on the tasks relevant to each phase. The step-by-step flow with per-step validation ensured input errors were caught before final submission — eliminating the main cause of support tickets. Try it here.

Results: Delivery and Validation

Launch Strategy: Controlled Beta

We opted for a beta launch for customers selling on a single marketplace (Mercado Livre). This was a strategic decision — it let us test all of one marketplace's business rules before scaling to the other 24 the platform integrated with.

During the beta:

• Follow-ups and feedback meetings with the selected customers
• Ticket monitoring with the support team to validate whether the goals were being met

Impact on Support Tickets

After the full rollout to all users, we set up tracking with the support team for tickets related to listing creation.

Before (Q1 2022) — The scenario that motivated the project:

After (Q3 2022, post-rollout):

Direct comparison:

Per-step validation in the step-by-step flow was the main driver of the drop in input-error tickets — the system now kept sellers from moving forward with incorrect data, eliminating the root cause of most tickets.

Impact on the Experience