Overview
Scaling UX across several B2B commerce brands is not primarily a question of producing more designs. It is an operating-model problem between teams.
The challenge
When I began building a UX practice within a multi-brand commerce organization, UX work had historically been handled largely through external contracts. That model could deliver individual projects, but it created a structural problem: when contracts ended, design files, personas, customer knowledge, and the reasoning behind experience decisions were not consistently retained as organizational knowledge.
The company was not simply losing design assets. It was losing critical context that gave insight into personas across different touchpoints.
My role
I established a small internal UX team within the omnichannel organization with a different objective: create durable experience ownership that could support multiple product teams and brands over time.
The team was intentionally small. Rather than embedding one designer into every product team, we operated as a shared UX capability responsible for experience direction, interaction patterns, customer knowledge, and design quality across the commerce platform.
As the organization expanded, that model allowed four UX team members to support seven product teams, four major brands, and a unified white-label experience.
That required the team to think beyond individual screens and build an overarching experience on the platform.
Key decisions
One of the most important decisions was separating customer/persona behavior, workflow logic, and interaction rules from brand-specific visual expression.
Different brands did not always need identical interfaces. They served different customer groups, internal sales users, and operating contexts. But many underlying tasks were the same: finding products, managing orders, navigating account information, completing purchases, or interacting with shared commerce capabilities.
If every brand solved those tasks independently, the organization accumulated duplicated design work and unnecessary variation within the platform.
Decision 01
Document reusable patterns before a design system existed
Before a formal design system existed, we began identifying reusable patterns in Figma and documenting where behaviors should remain consistent.
Consistency was documented in Figma ahead of a formal design system.
Decision 02
Make exceptions explicit
Exceptions were allowed when product or customer needs justified them, but they became explicit decisions rather than accidental divergence.
Standardize the experience logic where possible, while allowing controlled variation where the business required it.
The solution
The operating model also had to work within the reality of software delivery.
UX could not operate as a separate upstream activity that handed designs to development and moved on. The team integrated directly into the existing ticketing and release process so design work could align with product priorities, engineering capacity, and delivery schedules.
As ticket volume increased, we adopted a Kanban model to manage intake across multiple product teams. This gave the UX team a clearer way to prioritize work, expose constraints, and avoid becoming an uncontrolled design-request queue within the rapid development model.
Figma also became more than a design tool. I helped establish it as the source of truth for experience assets and increasingly for teams outside UX. Centralizing those assets reduced dependence on individual contributors and external vendors while improving continuity of product knowledge.
Impact
The result was not simply greater visual consistency but a proven operating model for the team.
The operating model allowed a small UX organization to support several commerce brands without recreating the same experience decisions repeatedly. It also created the organizational foundation for a dedicated design-system capability focused on standardization, reusable components, and faster onboarding of additional brands.
Most importantly, experience knowledge became an organizational asset instead of something that disappeared when a project, vendor relationship, or individual engagement ended.
Scaling UX across brands does not mean forcing every experience to look the same. It means deciding deliberately what should be shared, what should vary, who owns those decisions, and where that knowledge lives.
That is what allows a small UX organization to support a growing digital platform without scaling headcount at the same rate as complexity.
Because of confidentiality requirements, this case study cannot show the actual design system, brand identities, or proprietary implementation details. Impact metrics have also been omitted, so the examples focus on the strategy, architecture, operating model, and design decisions behind the work.