Zebrands · ZePOS · Dec 2024 – Apr 2026
I redesigned how stores sell, not just the screen.
Lead designer of Zebrands’ POS for 200+ stores: I aligned Business, Payments and Engineering on the rules holding it back. Launched at Buen Fin 2025 with no downtime.
Each stone is a metric from this case.
Fewer sync errors
Support tickets: from 43 to 12 in four weeks
Per order, down from 4–6 min
Stores launched with no system downtime
Context
Zebrands is an omnichannel retail company operating in Mexico and Brazil. Its point of sale, used in more than 200 physical stores, relied on a centralized ERP for critical sales operations. That dependency across catalog, payments, shipping and customer data meant slow performance, frequent errors and friction for the people selling.
During Hot Sale in June 2025 the system was down for more than 5 hours. The work that followed focused on decentralizing the ERPNext services and redesigning the selling experience on top of that new foundation. I led the redesign with a team of frontend, backend, architecture and technical leadership.
My rolethe bridge between teams
I was the lead designer on the project, with a part-time design colleague, in a team of 18 and with no dedicated Product Manager. My job was less about drawing screens and more about getting aligned the people who decided how the system worked:
Design & research
- Field research in stores: interviews, observation and ticket analysis
- Flows for catalog, cart, shipping and payment
- Design system and design reviews
Cross-team alignment
- Payment and stock rules between Business and Payments
- Service decoupling with engineering (Event Storming)
- Presented and defended the designs to Business, the CPO and the CTO
Operations & launch
- Root-cause diagnosis with Sentry and Grafana
- Progressive rollout: pilot, validation and full flow
- Trained 500+ store employees and provided Portuguese materials for Brazil
Business rulesthe bottleneck that wasn’t in the interface
Business and Payments had different ideas about how a sale should work. Until that was settled, no design could fix the errors or the tickets.
Which single or combined payments allow the order to be created?
Both payment policies and stock policies came into play.
In store, the seller can sell into negative stock, but payments must meet certain rules.
When can the order be created, and against what availability?
What I did
- I brought Business and Payments together to draw edge cases side by side and put the rules of the game on the table.
- With the other designer I built the training material that explains the agreement to the people selling.
The rule we landed on
There are two kinds of payment: asynchronous and synchronous. They can be combined (for example, async + sync), but only some combinations allow the order to be created.
- The order is not created until every payment is approved.
- If a TPV, Terminal or PIX payment is pending, the order cannot be created: the seller retries, or deletes the payment and chooses another method.
Decisionswhat I fought for
Availability visible across the whole flow
I argued for showing availability on every product card, in the cart and in the shipping and payment flows. Since stores can sell into negative stock, that opens different shipping and delivery combinations, and sellers had to keep them in mind at all times. Before, they had to leave the POS to check. I presented it to Business, the CPO and the CTO, and it shipped.
Design System independent of the ERP
A design system that didn’t depend on ERPNext’s release cycle. It unblocked the team’s speed and let us iterate in parallel without relying on the legacy architecture.
Performance over complexity
Designing for intermittent connectivity. Prioritizing load times and stability before adding features, in stores with limited network infrastructure.
How I explained it and how it looked
Architecturefrom a centralized ERP to decoupled services
All services depended on a single ERP, creating bottlenecks and shared failures.
UX research identified the critical dependencies and helped engineering evaluate service decoupling.
- 1
Research
I mapped the seller journey and identified friction points and system dependencies.
- 2
Event Storming
With engineering, I connected user flows, business events and technical dependencies.
- 3
Decoupling decisions
We evaluated which services to separate, how they should communicate and what had to stay centralized.
Independent services, fewer dependencies, more resilience and better performance.
How research and engineering shaped the solution.
Operational impactbefore vs after
Performance
Errors & tickets
Trust & adoption
Source: Grafana (July 2025 measurements), Sentry and support tickets. Sentry was added when the ERPNext services were decentralized. pp = percentage points.
Design decisions behind the improvement
- An ordered catalog with complete, self-contained information
- A cart with visual order that can be edited
- Availability states, including whether a product is coming soon
Result: sellers no longer leave the POS to check availability in the source of truth.
The POS was rolled out progressively — pilot stores → validation → full flow — reaching 200+ stores before Buen Fin 2025 with no system downtime. Tickets fell from 43 in week one to 33 in week two and 12 in week four (−72%); the early ones centered on coupons and on modular products that could not be added to the cart.
Evidencebefore and after of the critical flows
- Slowness — the catalog creates operational bottlenecks
- Overloaded with discontinued products
- Optimized search with multiple filters
- Only active, relevant products
- Overload of non-essential information
- Falta de elementos para el flujo critical
- Intuitive card design with improved architecture
- Visual support for relevant product features
- Overload of non-essential information
- Falta de elementos para el flujo critical
- Improved information architecture
- Fast, smooth checkout
- Flujo critical en un solo modal sin salida
- Insufficient feedback during calculation steps
- Fully redesigned flow with real-time configuration
- Integrated inventory services
- Disorganized payment methods with no hierarchy
- Feedback insuficiente en procesos criticals
- Simple, step-by-step guided flow
- Clear, real-time states
What this project changed in how I design
Business rules are design too
Harmonizing misaligned rules removed bottlenecks that no interface could have solved, and taught me that my best tool was getting teams to draw the edge cases together.
“Every architecture decision is an experience decision.”
Melany Olivares