Una investigación, no un tablero
Walmart Marketplace es el lado de terceros de Walmart.com. Pricing Room es la plataforma interna donde los agentes de la propia Walmart configuran y controlan las reglas que deciden si la oferta de un seller puede venderse en el sitio.
- Rol
- Senior Product Designer — discovery, arquitectura de información, diseño de interacción, prototipado, documentación, handoff y QA.
- Colaboradores
- PM, Ingeniería, Datos, SAM/Partner Support, Content Design y Design System (PX).
- Norte
- Un analista debería poder decir por qué cayó un artículo, y corregirlo, sin abrir una segunda herramienta.
En 30 segundos
- 01 · Problema
- Soporte investigaba ofertas despublicadas entre herramientas fragmentadas y escalaba al equipo de precios.
- 02 · Decisión
- Diseñar la investigación, no un tablero: primero el motivo, después las ofertas, los límites con su fuente, y la corrección en la misma página.
- 03 · Resultado
- La resolución media pasó de 12 a 2 días; los escalamientos, del 27% al 19%, tres meses después del MVP. Las metas eran 1 día y menos del 10%.
El problema
Una regla de precio despublica el artículo de un revendedor en Walmart.com, y la cadena que sigue tiene cuatro eslabones. El seller busca en Seller Center, no encuentra motivo y contacta al soporte. Un SAM o un Partner Support investiga a mano, entre Pricing Room y varias plataformas internas más, donde la misma cifra puede aparecer dos veces con dos valores y ninguno dice qué regla se aplicó. Cada analista tiene su propio recorrido por esas herramientas, así que dos personas llegan a dos respuestas sobre el mismo artículo. Cuando la evidencia se acaba — el 27% de las veces se acababa — el caso va al equipo de precio, los únicos que leen la regla en su fuente. Cada eslabón suma días, y el artículo está fuera del sitio en todos ellos.
Un caso, paso a paso
01 / 06
Antes · Después
El mismo trabajo, en dos pantallas
El dato que el analista necesitaba estaba repartido en cuatro herramientas, y la propia página de Pricing Room ponía todos los límites en una sola lista, cada uno con el mismo “motivo del valor actual” al lado. Nada decía cuál había bajado el artículo.
Antes — el Pricing Room anterior
Después — el rediseño
Qué cambió
El motivo
Antes: cinco precios techo, cada uno con la misma frase debajo.
Después: una línea que dice qué regla despublicó la oferta, arriba de la oferta.
Los números detrás de un límite
Antes: un valor, sin forma de saber de dónde sale.
Después: el benchmark, el ancla y “ver fórmula” junto al número.
Cambiar un precio
Antes: campos de override vacíos, sin idea del efecto.
Después: una calculadora contra el benchmark, y un override con plazo.
La restricción
Analistas de precio, SAMs y Partner Support trabajaban un artículo por vez, con presión de tiempo y el dato repartido en varias herramientas. Ninguna iba a desaparecer, los límites detrás de un precio — techo, Buy Box, piso — eran de otros equipos, y cualquier cambio tenía que aguantar el volumen del marketplace.
La decisión de diseño
La pantalla organiza una investigación: qué se despublicó y por qué, las ofertas, los límites y sus fuentes y, luego, la corrección disponible. El motivo, la fórmula y la fuente acompañan la decisión que respaldan.
Triaje por gravedad
Las ofertas se ordenan por cuánto se desvían, sobre el techo, bajo el piso o inelegible para el Buy Box, así que el peor caso queda en el tope de la lista.
Actuar donde se decide
Las reglas se calculan desde un ancla competitiva y se editan ahí mismo, con los límites actuales y propuestos lado a lado, protecciones en el override y un plazo, para que una corrección temporal no se vuelva permanente en silencio.
Cómo lo supe
El discovery fue una revisión de PRD y de datos, el recorrido actual mapeado de punta a punta, lectura de tickets reales, entrevistas con toda la cadena, y shadowing con SAMs, Partner Support y los desarrolladores de precio mientras trabajaban un caso. Cinco cosas volvieron siempre: dato fragmentado, retrabajo, inconsistencia entre analistas, falta de claridad sobre por qué cayó el artículo, y la escalación como norma. Después el diseño se revisó de forma continua, en pruebas con usuarios, en rondas de design critique, y junto a Content Design, el equipo de Design System, PMs e ingeniería.
El compromiso
Explicar reglas, referencias y acciones disponibles ocupa espacio vertical. El diseño equilibra ese contexto con la lectura rápida y la comparación; el portafolio no establece el efecto de ese equilibrio por nivel de experiencia.
Resultado
- Las metas, fijadas antes del trabajo
- Llevar el tiempo medio de resolución de 12 días a 1, y las escalaciones al equipo de precio de 27% a menos de 10%.
- Lo que pasó, tres meses después del MVP
- La resolución media pasó de 12 a 2 días; los escalamientos, del 27% al 19%, tres meses después del MVP. Las metas eran 1 día y menos del 10%.
- Qué significa
- La revisión registra menor tiempo medio de resolución y menos escalamientos. Ninguna meta se alcanzó por completo. Son resultados del equipo: no prueban diez días recuperados en cada caso ni aíslan el efecto del diseño.
En qué me equivoqué, y qué haría después
Cuatro cosas de la retrospectiva del propio proyecto. La calculadora de precio techo funcionó, y esa parte de la apuesta rindió. Por qué tantos tickets siguen escalando sigue sin explicación, y es el hilo del que tiraría primero: el diseño responde “por qué cayó esto”, y las escalaciones restantes son probablemente otra pregunta. El equipo de Design System debería haber entrado antes; llamarlo tarde costó una consistencia que después tuve que defender. Y la cobertura de datos por debajo es delgada. Los algoritmos de match no le dan a los SAMs y a Partner Support material suficiente, así que a veces la herramienta explica con seguridad un número que merece menos confianza de la que aparenta.