OmniRetail's Design System
Building One Design Language For Four Product Teams
By 2024, OmniRetail's design work had split across four product teams, Retail (Omnibiz), Distribution (OmniHub), Manufacturer (OmniOne) and Payments (Omnipay), each shipping on its own timeline, with its own interpretation of what a "primary button" should look like. Omnione is the design system I built to give all four one shared language, without slowing any of them down.
As Senior Product Designer and Design Manager, I owned the system end-to-end: auditing what already existed, defining the token structure, building the component library in Figma, and getting engineering to adopt it in code, not just admire it in a file.
Summary
Omnione is OmniRetail's design system, built to unify UI across every product the company ships: the Omnibiz retailer app, OmniHub, OmniOne, Omnipay, and the internal tools running alongside them. Before Omnione, each surface had its own visual language, because each was designed and built independently under deadline pressure, with no shared source of truth to pull from.
Token System
2-Tier
Foundation tokens feeding semantic, usage-level tokens.
Components
60+
Built and documented in the shared library.
Variants
2,300+
Across states, sizes, and product-specific needs.
My Responsibilities Included
Pattern Audit
Auditing existing UI patterns across all four product surfaces to find what was already duplicated or diverging.
Foundation Layer
Owning the foundation layer (colour, typography, grid, table rows and columns, and the sidebar): the pieces every other designer had to build their own library section on top of.
Atomic Structure
Structuring the system on atomic design (Foundation, Atoms, Molecules, Organisms, Templates) so the dependency order let four teams build in parallel instead of blocking on each other.
2-Tier Tokens
Defining a 2-tier token system (foundation tokens for raw values, semantic tokens for usage) so colour, spacing, and type could update from one source.
Table Column System
Designing the table column system: variants for text, status labels, leading icons, avatars, icon-only, title style, sortable headers and row actions, all extended as new use cases surfaced across the teams.
Engineering Handoff
Working directly with engineers to define the Figma variables they built tokens from, so the system matched in the browser, not just in Figma.
Problem
After a successful fundraising, four teams, four interpretations of the same interface. The cost was not only visual: it showed up in rebuilt components, inconsistent engineering specs, and users learning the same pattern twice.
Divergent Visual Language
Every surface had shipped its own buttons, spacing scales, and component behaviour, because each was built independently under deadline pressure.
Rebuilding Basics
Every new screen meant rebuilding basic UI from scratch, because there was nothing shared to pull from.
Inconsistent Handoff
Engineers received slightly different specs for the same "component" depending on which designer built the screen, creating avoidable back-and-forth.
Process
- 01 Audit Catalogued existing patterns and duplication across all four product teams.
- 02 Define Settled the token structure first, then validated it against real screens from each surface.
- 03 Build Composed the library in phases, primitives first, then patterns, piloting each on one surface before rolling out.
- 04 Adopt Partnered with engineering on the code library, then set up governance so the system kept growing without me gatekeeping it.
Solution
A single component library, structured so each team could keep moving at their own pace while pulling from the same foundation. Tokens first, components second, adoption third, in that order, because the order is what made it survivable.
Tokens First
Audited existing patterns across the Retailer App, Omnipay, and internal tools to find what was already duplicated or diverging. Defined a token structure (colour values, semantic tokens for usage, type scale, spacing, and elevation) so the foundation could update in one place.
Components Second
Built and documented the component library in Figma, from primitives (buttons, inputs, tags) through composed patterns (cards, tables, empty states).
Adoption Third
Worked directly with engineers to translate tokens into code, so the system matched in the browser and not just in Figma. Set up a lightweight contribution process so other designers could propose new components without forking the system.
Outcome
Teams Unified
4
Retail, Distribution, Manufacturer and Payments on one shared language.
Handoff Time
−40%
Reduction in design-to-engineering handoff once teams built against tokens.
Rebuild Cycle
Ended
Teams pulled from the library instead of rebuilding primitives per screen.
The Surfaces It Had To Serve
OmniRetail isn't one app. It's an operating system for each side of the trade, retail, distribution, manufacturing, plus the payment rail underneath and the internal tool that administers all three. Any design system here had to serve four teams whose users have almost nothing in common except the data flowing between them.
Omni
Single Sign On
Retail Team
Omnibiz App · ROS
Distribution Team
OmniHub · DOS
Manufacturer Team
OmniOne · MOS
Payments Team
Omnipay App
Plus the internal tool
Trade Entity · internal management for ROS, MOS and DOS
The Decision
I built the component library in phases rather than shipping it all at once. Token work is invisible progress compared to a shiny new component set, but it avoided the component-rework cycle, had we started with components, every one of them would have needed rebuilding the moment the tokens landed.
Lesson Learnt
A design system is an agreement, not a file. The hardest part was never drawing the components, it was getting four teams to accept a shared constraint while each was under its own delivery pressure. What made it hold was sequencing and adoption, not craft: settling the foundation first so nobody was blocked, giving engineering tokens instead of screenshots, and leaving a contribution path open so the system could absorb new needs rather than be worked around. A library nobody can extend gets forked; one that's easy to contribute to gets defended by the people using it.
Other Projects