Total Wine & More
Designing a unified operations portal for 400+ retail locations
(Details)
(Challenge)
Replacing fragmented legacy tools with one coherent system
The Market Gap: Internal operations software in retail is chronically under-designed. Enterprise tools get built for compliance and function, not for the people who use them daily. At Total Wine & More, operations teams relied on a legacy desktop application, Catalog Pro, built on Oracle's Apex — that forced users to jump between multiple disconnected apps to complete a single task. There was no unified space, no role clarity, no consistent language. Just fragmentation wrapped in an outdated UI. The Strategic Opportunity: Create a single operations portal, Atom, that would replace the fragmented legacy ecosystem. Not just a visual refresh, but a rethinking of how 400+ store locations interacted with the tools that run their business: inventory, pricing, supplier management, compliance, and more. A platform where users would always know where they were, what they could do, and why. My Role: I led the project end-to-end at Globant, from defining the research approach and conducting stakeholder and user interviews, to auditing the legacy system, documenting findings, and delivering the first stage designs. I worked directly with business and operations stakeholders to translate complex, multi-department requirements into a coherent product and design foundation.
(Goal)
Turning a fragmented ecosystem into a single source of truth
The goal was never just to modernize the UI. The deeper ambition was to give operations teams — across hundreds of locations, a platform that matched how they actually worked. That meant understanding not just what the legacy system did, but what it failed to communicate: which roles could do what, which tasks could be done in bulk, what had expired, what needed approval. We approached the redesign as an infrastructure problem as much as a design problem. Atom had to consolidate everything into one coherent portal while remaining flexible enough to serve users with very different roles and workflows, from store managers to suppliers to corporate merchandising teams.
(Solution)
Product Priciples
1. Role-aware by design: the system should always surface the right actions for the right user, not expose everything to everyone. 2. Actions belong to the data: contextual actions should live next to the data they act on, not hidden in menus. 3. Bulk is a first-class behavior: for operations teams working at scale, bulk creation, editing, and approval flows aren't edge cases. They're the default. 4. Consistency as infrastructure: a unified design language across all modules reduces the learning curve every time a user switches context.
Research as the Foundation
The core hypothesis: the legacy system's problems were invisible to users because they had adapted to them. Interviews alone wouldn't be enough , we needed to audit the system ourselves. I ran stakeholder and user interviews across departments, using a script designed to map not just what people did, but how they moved across systems and where friction silently accumulated. Questions covered role and responsibilities, cross-department interactions, daily SRM workflows, data extraction habits, and supplier communication patterns. The legacy audit confirmed what interviews hinted at: Catalog Pro displayed 172,622 rows in a single flat table with no filtering, no role indicators, no feedback states, and broken UX conventions including modal-on-modal behaviors. Bulk actions didn't exist. UX writing was inconsistent. Visual hierarchy was flat, everything competed for equal attention.
Product Architecture
Atom launched as a unified web portal organized around six major operational domains: Assortment Management → Finance & Accounting → Merchandising → Supply Chain → Store Operations → Pricing. A persistent top-level navigation replaced the app-switching of the legacy system. A global notification bar handled system-wide alerts. Every module followed the same interaction patterns, users only had to learn the system once.
Three Key Product Design Decisions
1. Redesigned Data Tables (Powered by Role-Awareness) The SRM (Suggested Retail Minimums) module, one of the most-used and most-broken parts of the legacy system, became the design foundation. The new table introduced item-level status indicators, clear approval states, price zone tagging, and date visibility. Bulk actions (Delete, Download, Approve/Unapprove, Extend) moved into the table header, accessible in one click. This proved that a data-heavy interface doesn't have to be cognitively heavy when information hierarchy is intentional.
2. Explicit Feedback States The legacy system gave users almost no feedback. Actions completed silently, or failed silently. The redesign introduced success toasts for completed actions, inline validation on forms, and a system-wide notification bar for critical alerts. Small decisions, massive trust impact.
3. Component-Level Behavior Documentation For the price zone creation flow, a core SRM workflow involving multi-state selections across hundreds of locations, I designed a dynamic multi-box grid where each state/region is an expandable container holding location chips. Box heights grow to match the tallest box in the row, with 16px spacing and 12px margins. This was documented as a formal component specification for the design system, treating behavior rules as a design deliverable, not an afterthought.
(Impact)
Business Outcomes
✅ First-stage design foundation delivered and approved for Atom ✅ Legacy audit documented, 8 critical UX failures identified and addressed in the redesign ✅ Next stage scoped: full discovery for the next software branch greenlit after first stage completion
User Engagement
Research unlocked hidden problems: Users had adapted to broken UX, the system audit revealed failure modes nobody named in interviews but everyone worked around daily Role clarity restored: The platform now communicates user permissions by design, eliminating the confusion of an undifferentiated interface Bulk workflows enabled: Bulk creation, editing, approval, and download, previously impossible, became primary interaction patterns in the redesign
(Next)
