Uma investigação, não um painel
O Walmart Marketplace é o lado de terceiros do Walmart.com. O Pricing Room é a plataforma interna onde os agentes da própria Walmart configuram e controlam as regras que decidem se a oferta de um seller pode ser vendida no site.
- Papel
- Senior Product Designer — discovery, arquitetura da informação, design de interação, prototipação, documentação, handoff e QA.
- Parceiros
- PM, Engenharia, Dados, SAM/Partner Support, Content Design e Design System (PX).
- Norte
- Um analista deveria conseguir dizer por que um item caiu, e corrigir, sem abrir uma segunda ferramenta.
Em 30 segundos
- 01 · Problema
- O suporte investigava ofertas despublicadas em ferramentas fragmentadas e frequentemente escalava ao time de preços.
- 02 · Decisão
- Desenhar a investigação, não um painel: o motivo primeiro, depois as ofertas, os limites com a fonte deles, e a correção na mesma página.
- 03 · Resultado
- A resolução média passou de 12 para 2 dias; os escalonamentos, de 27% para 19%, três meses após o MVP. As metas eram 1 dia e menos de 10%.
O problema
Uma regra de preço despublica o item de um revendedor no Walmart.com, e a corrente que vem depois tem quatro elos. O seller procura no Seller Center, não acha motivo nenhum e aciona o suporte. Um SAM ou um Partner Support investiga à mão, entre o Pricing Room e várias outras plataformas internas, onde o mesmo número pode aparecer duas vezes com dois valores e nenhum deles diz qual regra pegou. Cada analista tem o próprio caminho por essas ferramentas, então duas pessoas chegam a duas respostas sobre o mesmo item. Quando a evidência acaba — em 27% das vezes acabava — o caso vai para o time de preço, os únicos que leem a regra na fonte. Cada elo soma dias, e o item fica fora do site em todos eles.
Um caso, passo a passo
01 / 06
Antes · Depois
O mesmo trabalho, em duas telas
O dado que o analista precisava estava espalhado por quatro ferramentas, e a própria página do Pricing Room colocava todos os limites numa lista só, cada um com o mesmo “motivo do valor atual” ao lado. Nada dizia qual deles tinha derrubado o item.
Antes — o Pricing Room antigo
Depois — o redesenho
O que mudou
O motivo
Antes: cinco preços-teto, cada um com a mesma frase embaixo.
Depois: uma linha dizendo qual regra despublicou a oferta, no topo da oferta.
Os números por trás de um limite
Antes: um valor, sem como saber de onde veio.
Depois: o benchmark, a âncora e “ver fórmula” ao lado do número.
Mudar um preço
Antes: campos de override vazios, sem ideia do efeito.
Depois: uma calculadora contra o benchmark, e um override com prazo.
A restrição
Analistas de preço, SAMs e Partner Support trabalhavam um item por vez, sob pressão de tempo, com o dado espalhado por várias ferramentas. Nenhuma delas ia deixar de existir, os limites por trás de um preço — teto, Buy Box, piso — eram de outros times, e qualquer mudança tinha que aguentar o volume do marketplace.
A decisão de design
A tela organiza uma investigação: o que saiu do ar e por quê, as ofertas dos sellers, os limites e suas fontes e, então, a correção disponível. Motivo, fórmula e fonte ficam próximos da decisão que apoiam.
Triagem por gravidade
As ofertas são ordenadas pelo tamanho do desvio, acima do teto, abaixo do piso ou inelegível para o Buy Box, então o pior caso fica no topo da lista.
Agir onde se decide
As regras são calculadas a partir de uma âncora competitiva e editadas ali mesmo, com os limites atuais e propostos lado a lado, proteções no override e um prazo nele, para que uma correção temporária não vire permanente no silêncio.
Como eu soube
O discovery foi uma revisão de PRD e de dados, a jornada atual mapeada de ponta a ponta, leitura de tickets reais, entrevistas com todo mundo da cadeia, e shadowing com SAMs, Partner Support e os desenvolvedores de preço enquanto trabalhavam um caso. Cinco coisas voltaram sempre: dado fragmentado, retrabalho, inconsistência entre analistas, falta de clareza sobre por que o item caiu, e a escalação como padrão. Depois o desenho foi revisado continuamente, em testes com usuários, em rodadas de design critique, e junto com Content Design, o time de Design System, PMs e engenharia.
O compromisso
Explicar regras, referências e ações disponíveis ocupa espaço vertical. O design equilibra esse contexto com leitura rápida e comparação; o portfólio não estabelece o efeito desse equilíbrio por nível de experiência.
Resultado
- As metas, definidas antes do trabalho
- Levar o tempo médio de resolução de 12 dias para 1, e as escalações para o time de preço de 27% para menos de 10%.
- O que aconteceu, três meses depois do MVP
- A resolução média passou de 12 para 2 dias; os escalonamentos, de 27% para 19%, três meses após o MVP. As metas eram 1 dia e menos de 10%.
- O que isso quer dizer
- A revisão registra menor tempo médio de resolução e menos escalonamentos. Nenhuma das metas foi atingida integralmente. São resultados do time: não comprovam dez dias recuperados em cada caso nem isolam o efeito do design.
O que eu errei, e o que eu faria em seguida
Quatro coisas da retrospectiva do próprio projeto. A calculadora de preço-teto funcionou, e essa parte da aposta pagou. Por que tanto ticket ainda escala segue sem explicação, e é o fio que eu puxaria primeiro: o desenho responde “por que isso caiu”, e as escalações que sobraram são provavelmente outra pergunta. O time de Design System deveria ter entrado antes; chamá-lo tarde custou uma consistência que eu tive que defender depois. E a cobertura de dados embaixo é fina. Os algoritmos de match não dão aos SAMs e ao Partner Support material suficiente, então às vezes a ferramenta explica com segurança um número que merece menos confiança do que aparenta.