Building One Design Language For Four Product Teams

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.

I was responsible for:

• Auditing existing UI patterns across all four product surfaces to find what was already duplicated or diverging.
• 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.
• 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.
• 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.
• 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.
• Working directly with engineers to define the Figma variables they built tokens from, so the system matched in the browser, not just in Figma.
• Setting up a lightweight contribution process so other designers could propose new components without forking the system.

Problem

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.

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.

• 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.
• Built and documented the component library in Figma, from primitives (buttons, inputs, tags) through composed patterns (cards, tables, empty states).
• 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.

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.

Outcome

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.