Zebrands · ZePOS · Dic 2024 – Abr 2026
Rediseñé cómo se vende en tienda, no solo la pantalla.
Diseñadora líder del POS de 200+ tiendas de Zebrands: alineé a Negocio, Payments e Ingeniería en las reglas que lo frenaban. Lanzado en Buen Fin 2025 sin caídas.
Cada piedra es una métrica del caso.
Menos errores de sincronización
Tickets de soporte: de 43 a 12 en cuatro semanas
Por orden, antes 4–6 min
Tiendas lanzadas sin caídas del sistema
Contexto
Zebrands es una empresa de retail omnicanal con presencia en México y Brasil. Su punto de venta, usado en más de 200 tiendas físicas, dependía de un ERP centralizado para las operaciones críticas de venta. Esa dependencia entre catálogo, pagos, envío y datos de cliente se traducía en rendimiento lento, errores frecuentes y fricción para quien vendía.
En el Hot Sale de junio de 2025 el sistema estuvo caído más de 5 horas. El trabajo posterior se centró en descentralizar los servicios de ERPNext y en rediseñar la experiencia de venta sobre esa nueva base. Lideré el rediseño con un equipo de frontend, backend, arquitectura y liderazgo técnico.
Mi rolel puente entre las áreas
Fui la diseñadora líder del proyecto, con una compañera de diseño a medio tiempo, en un equipo de 18 personas y sin Product Manager dedicado. Mi trabajo fue menos dibujar pantallas que poner de acuerdo a quienes decidían cómo funcionaba el sistema:
Diseño y research
- Investigación en tienda: entrevistas, observación y análisis de tickets
- Flujos de catálogo, carrito, envío y pago
- Design system y design reviews
Alineación entre áreas
- Reglas de pagos y de stock entre Negocio y Payments
- Desacople de servicios con ingeniería (Event Storming)
- Presenté y defendí los diseños ante Negocio, CPO y CTO
Operación y lanzamiento
- Diagnóstico de causas raíz con Sentry y Grafana
- Despliegue progresivo: piloto, validación y flujo completo
- Capacitación a 500+ empleados de tienda y materiales en portugués para Brasil
Reglas de negocioel cuello de botella que no estaba en la interfaz
Negocio y Payments tenían ideas distintas sobre cómo debía funcionar la venta. Mientras no se resolviera, ningún diseño iba a arreglar los errores ni los tickets.
¿Qué pagos únicos o combinados permiten continuar con la creación de la orden?
Aquí entraban políticas de pagos y también de stock.
En tienda el vendedor puede vender en negativo, pero los pagos tienen que cumplir ciertas reglas.
¿Cuándo se puede crear la orden, y con qué disponibilidad?
Lo que hice
- Reuní a Negocio y Payments para dibujar juntos los casos borde y poner sobre la mesa las reglas del juego.
- Con la otra diseñadora armé el material de capacitación que explica el acuerdo a quienes venden.
La regla que quedó
Hay dos tipos de pago: asíncronos y síncronos. Se pueden combinar (por ejemplo, async + sync), pero solo algunas combinaciones permiten crear la orden.
- La orden no se crea hasta que todos los pagos estén aprobados.
- Si TPV, Terminal o PIX tienen pagos pendientes, no se puede crear la orden: se reintenta o se borra el pago y se elige otro método.
Decisioneslo que defendí
Disponibilidad visible en todo el flujo
Defendí mostrar la disponibilidad en cada card de producto, en el carrito y en los flujos de envío y pago. Como en tienda se puede vender en negativo, eso abre combinaciones distintas de envío y entrega, y el vendedor tenía que tenerlas presentes todo el tiempo. Antes debía salir del POS para consultarlo. Lo presenté a Negocio, CPO y CTO y se implementó.
Design System independiente del ERP
Un sistema de diseño que no dependiera del ciclo de releases de ERPNext. Desbloqueó la velocidad del equipo y permitió iterar en paralelo sin depender de la arquitectura legacy.
Performance sobre complejidad
Diseñar para conexión intermitente. Priorizar tiempos de carga y estabilidad antes de agregar funcionalidades, en tiendas con infraestructura de red limitada.
Cómo lo expliqué y cómo se vio
Arquitecturade un ERP centralizado a servicios desacoplados
Todos los servicios dependían de un solo ERP, con cuellos de botella y fallas compartidas.
La investigación UX identificó las dependencias críticas y ayudó a ingeniería a evaluar el desacople de servicios.
- 1
Investigación
Mapeé el recorrido del vendedor e identifiqué fricciones y dependencias del sistema.
- 2
Event Storming
Con ingeniería, conecté flujos de usuario, eventos de negocio y dependencias técnicas.
- 3
Decisiones de desacople
Evaluamos qué servicios separar, cómo comunicarlos y qué debía seguir centralizado.
Servicios independientes, menos dependencias, más resiliencia y mejor rendimiento.
Cómo la investigación y la ingeniería dieron forma a la solución.
Impacto operativoantes vs después
Performance
Errores y tickets
Confianza y adopción
Fuente: Grafana (mediciones de julio de 2025), Sentry y tickets de soporte. Sentry se incorporó al descentralizar los servicios de ERPNext. pp = puntos porcentuales.
Decisiones de diseño detrás de la mejora
- Catálogo ordenado, con información completa y autocontenida
- Carrito con orden visual y posibilidad de editarlo
- Estados de disponibilidad, incluido si el producto llegará pronto
Resultado: el vendedor ya no sale del POS a consultar la disponibilidad en la fuente de verdad.
El POS se implementó progresivamente — tiendas piloto → validación → flujo completo — hasta llegar a las 200+ tiendas antes de Buen Fin 2025, sin caídas del sistema. Los tickets bajaron de 43 en la primera semana a 33 en la segunda y 12 en la cuarta (−72%); los primeros se concentraron en cupones y en productos modulares que no podían agregarse al carrito.
Evidenciaantes y después de los flujos críticos
- Lentitud — el catálogo genera cuellos de botella
- Sobrecargado con productos descontinuados
- Búsqueda optimizada con buscador y filtros múltiples
- Solo productos activos y relevantes
- Sobrecarga de información no esencial
- Falta de elementos para el flujo crítico
- Card design intuitivo con mejor arquitectura
- Apoyos visuales para características relevantes
- Sobrecarga de información no esencial
- Falta de elementos para el flujo crítico
- Mejora de arquitectura de información
- Checkout rápido y fluido
- Flujo crítico en un solo modal sin salida
- Feedback insuficiente en procesos de cálculo
- Flujo completo rediseñado con configuración en tiempo real
- Servicios de inventario integrados
- Métodos de pago desordenados sin jerarquía
- Feedback insuficiente en procesos críticos
- Flujo simple y guiado paso a paso
- Estados claros y en tiempo real
Lo que este proyecto cambió en mi forma de diseñar
Las reglas de negocio también son diseño
Armonizar reglas desalineadas eliminó cuellos de botella que ninguna interfaz habría resuelto, y me enseñó que mi mejor herramienta era sentar a las áreas a dibujar los casos borde juntas.
“Cada decisión de arquitectura es una decisión de experiencia.”
Melany Olivares