Um jeito mais fácil de anunciar nos marketplaces: -45% tickets

Papel: Product Designer

Responsabilidades: Discovery, definição de produto, prototipagem, testes de usabilidade e handoff

Impacto: Redução de ~45% nos tickets de suporte relacionados a criação de anúncios | Taxa de sucesso de 100% na tarefa principal do teste de usabilidade

Período: ~3 meses (Q1 2022 — Discovery → Teste → Beta)

Time: Michel (Product Designer) + Product Owner + Customer Success + Engenharia

Contexto: Ideris — HUB de marketplaces que conecta vendedores a 25+ marketplaces para gestão de estoque, vendas e anúncios

O Problema: Um Fluxo que Gerava Mais Dúvidas do que Anúncios

No primeiro trimestre de 2022, o processo de criação de anúncio na plataforma da Ideris registrou um aumento significativo de tickets no suporte — representando 65% dos tickets abertos em janeiro e 69% no mês seguinte.

Em parceria com o time de CS, fizemos a triagem desses chamados e constatamos que a esmagadora maioria era relacionada a tentativas de criação de anúncio sem sucesso. Os erros mais comuns tinham uma causa raiz em comum: informações preenchidas incorretamente pelo usuário, que a plataforma não impedia nem sinalizava.

Ou seja, o problema não era o usuário. Era a plataforma que não guiava o usuário.

Figura 01: Cliente relata ao suporte que a plataforma não cria o anúncio no marketplace e não indica o erro ocorrido.

Figura 02: Análise do erro realizado pelo desenvolvedor constatando que houve uma falha na configuração por parte do usuário da categoria preenchida, um erro que poderia ser contornado com uma boa usabilidade.

O Gap: Plataforma vs. Marketplace

Em parceria com o PO e os desenvolvedores, mapeamos os requisitos mínimos para criar um anúncio. A comparação revelou um desalinhamento claro:

A plataforma exigia mais passos do que os próprios marketplaces — e ainda distribuía esses passos em lugares diferentes da interface, sem uma sequência lógica.

Entrevistas: Confirmando com Quem Usa

Para entender como os sellers realmente operavam, realizamos entrevistas para mapear painpoints. Os achados foram reveladores:

Dor principal: Dificuldade em completar todos os passos necessários para criar um anúncio — sendo a criação e mapeamento de categorias e atributos a etapa de maior fricção.

Comportamento inesperado: Usuários criavam anúncios diretamente nos marketplaces e depois importavam para a Ideris apenas para controle de estoque. Em outras palavras, estavam usando ferramentas externas para contornar as dificuldades da plataforma.

Sentimento geral: Usuários se sentiam perdidos, sem uma arquitetura de informação consistente que os guiasse pelo processo.

Síntese: 3 Problemas Centrais

Após a etapa de discovery, consolidamos os achados em três problemas principais:

1. Usabilidade confusa — Muitos passos necessários, espalhados em diferentes lugares da plataforma, sem sequência lógica clara.

2. Frustração silenciosa — A plataforma não comunicava se os passos foram concluídos corretamente, e ao fim do processo o anúncio simplesmente falhava — sem explicar o porquê.

3. Evasão para ferramentas externas — Com o processo difícil, sellers criavam anúncios fora da plataforma e só usavam a Ideris para gestão de estoque — o que representava risco de churn e subutilização do produto.

A Estratégia: De 6 Etapas Fragmentadas para 1 Fluxo Unificado

O que tínhamos antes

Para criar um anúncio na plataforma, o seller precisava completar 6 etapas em telas diferentes, sem qualquer indicação de progresso ou sequência:

Cada etapa tinha sua própria complexidade e requisitos. O seller precisava saber, por conta própria, que "Criar Categoria" vinha antes de "Mapear Categoria", que precisava de um "Modelo de Anúncio" antes de criar o anúncio final, e assim por diante. Não havia nenhum guia, stepper ou feedback de progresso.

Alinhamento com o Time

Após análise e discussão com produto e engenharia, definimos que a solução precisava atender a três critérios:

1. Eliminar etapas desnecessárias — O novo fluxo não deveria exigir a criação separada de categorias, atributos e modelo de anúncio. A quantidade de processos precisava diminuir drasticamente.

2. Prevenir erros na origem — O sistema deveria assegurar o preenchimento correto das informações, impossibilitando falhas na criação por erros do usuário nos campos obrigatórios.

3. Ser fácil de aprender e usar — A experiência deveria eliminar a necessidade de o seller buscar formas alternativas de criar anúncio fora da plataforma.

Trade-off: Velocidade vs. Escopo

Um ponto que discutimos com engenharia foi o escopo de refatoração. Redesenhar o fluxo inteiro de uma vez significaria um projeto de meses. A decisão foi focar primeiro no fluxo de criação do anúncio — a ponta mais dolorosa para o usuário — e iterar nas etapas anteriores (mapeamento de categoria, modelo) em fases seguintes.

Isso nos permitiu entregar valor mais rápido sem comprometer a qualidade da solução principal.

Desenvolvimento: Duas Propostas, Uma Decisão

Explorando Caminhos

Com os critérios definidos, desenhei duas propostas de solução:

Proposta A — Fluxo Linear (Single Page) Um processo em uma única tela, baseado na experiência de criação de anúncio que encontramos nos próprios marketplaces que os sellers já usavam. Todos os campos visíveis de uma vez, com scroll vertical.

Proposta B — Fluxo Step by Step (Wizard) Um processo dividido em etapas claras, focando a atenção do usuário nas tarefas de cada fase. Cada step valida os dados antes de permitir avançar, prevenindo erros no preenchimento.

Alinhamento com os Devs (Antes dos Testes)

Antes de investir tempo em testes de usabilidade, alinhei com o time de desenvolvimento quais seriam os impeditivos e complexidades técnicas de cada proposta. Esse passo foi intencional — não faz sentido testar algo que não pode ser construído no prazo.

O feedback da engenharia apontou que ambas as propostas eram viáveis, mas a versão step by step tinha vantagem técnica: permitia validação por etapa, o que reduzia a chance de o seller chegar ao final com dados incorretos — exatamente o problema que gerava os tickets.

Com base nesse alinhamento, decidimos criar o roteiro de teste para a versão step by step.

Testes de Usabilidade

Amostra: 8 clientes selecionados estrategicamente:

• 4 representando o perfil que sustenta o MRR
• 1 com maior ticket médio
• 1 cliente aleatório
• 1 usuário da versão legado da plataforma

O teste foi dividido em 5 tarefas:

O que os testes revelaram

Apesar da taxa de sucesso alta na tarefa principal (100% na criação do anúncio), levantamos 2 pontos de atenção que geraram ajustes:

1. Seleção de imagens — O modelo proposto quebrou o fluxo que os usuários já estavam acostumados na versão antiga de criação do modelo de anúncio. Foi necessário ajustar o padrão de interação para reduzir a curva de aprendizado.

2. Navegação entre etapas — Identificamos a necessidade de adicionar botões explícitos de "continuar" e "voltar", evitando preenchimento acidental em etapas erradas.

A Solução Final

A solução focou em guiar o seller por cada etapa da criação, fazendo com que ele se concentre apenas nas tarefas relevantes de cada fase. O fluxo step by step com validação por etapa garantiu que erros de preenchimento fossem capturados antes da submissão final — eliminando a principal causa dos tickets de suporte. Teste aqui.

Resultados: Delivery e Validação

Estratégia de Lançamento: Beta Controlado

Optamos por um lançamento em beta para clientes que trabalhavam com um único marketplace (Mercado Livre). Essa decisão foi estratégica — nos permitiu testar todas as regras de negócio de um marketplace antes de escalar para os outros 24 que a plataforma integrava.

Durante o beta:

• Acompanhamentos e reuniões de feedback com os clientes selecionados
• Monitoramento de tickets junto ao time de suporte para validar se os objetivos estavam sendo alcançados

Impacto nos Tickets de Suporte

Após o rollout completo para todos os usuários, estruturamos junto ao time de suporte um acompanhamento das aberturas de chamados relacionados à criação de anúncio.

Antes (Q1 2022) — O cenário que motivou o projeto:

Depois (Q3 2022, pós-rollout):

Comparativo direto:

A validação por etapa do fluxo step by step foi o principal fator na queda de tickets por erro de preenchimento — o sistema agora impedia o seller de avançar com dados incorretos, eliminando a causa raiz da maioria dos chamados.

Impacto na Experiência