Multi-brand design system: when I designed one design system for 3 global brands

Signify had just bought Cooper Lighting and faced a challenge: unifying its B2B portals. It was the B2B e-commerce for people who buy lighting at scale: customers, agents who sell to the end customer, distributors and lighting design firms, from the project on the floor plan all the way to the order.

Sales, purchasing, order management and customization lived in 4 legacy systems, each with its own language and user profiles. Buying still happened over email: the customer asked the agent, the agent asked Signify, the pricing team approved, and the quote went back by email.

I joined the project, internally called Paragon, in 2021, through Tech Mahindra. A strategy consultancy had done the business strategy and handed it over for implementation. I owned the final design vision, meaning where the project wanted to land visually and structurally, and I led a team of 7 product designers.

Components

744

Tokens

186

Brands

3

What the project didn't have

The project ran apart from the rest of the company and didn't even have a dedicated design library in Figma, let alone a design system. Signify had systems in other projects, but they didn't talk to each other, and this would be the company's first multi-brand one. The developers' framework was UI5, rigid about responsiveness, and Figma didn't have variables yet.

One of those limits showed up in the input. The screens already carried a lot of information, and fields often had little room to exist. The default UI5 input would make everything heavier. I took my own design, with the label inside the field, always visible and in bold, and the developers customized the component. With the label inside, the screen feels like everything is in its place. It came cheap: they built it once and agreed without pushback.

Before opening the library, I aligned the picture with the head of design and took apart the brand material that existed, which wasn't complete for every brand. I talked to the developers to learn their language and the limits of UI5. Then I wrote design principles and inventoried the components in production and in Figma.

With the inventory in hand, the work had two problems ahead: making one system serve 3 brands and, later on, getting my own team to use the library.

Three brands on one platform

The platform had to serve Signify, Cooper Lighting and Genlyte, and only Signify had tokens ready. The work the consultancy had left also fell below the identity's minimum and the website already live, in colors, typography and page structure.

I built a single design system, with a theme for each brand. I started from Signify's tokens and built Cooper Lighting's and Genlyte's from scratch, from the public website and each brand's identity manual. I redid the colors and typography, and redesigned the page structure around what the product needed.

I started before Figma had variables, with a single file built by hand, item by item. It switched the skin of the 3 brands in a few clicks, with almost no element redrawn. When variables arrived, the switch became a single click, I sped up and closed a robust version of the library, with the tokens as variables.

I weighed separate libraries and dropped the idea. The platform was practically identical across the 3 brands, and only the theme and a few very specific screens changed. I also followed the architecture of Signify's other systems, so ours would be easy to plug into them if they were ever unified.

The team wasn't using the library

The resistance to the system came from my own team, who kept using components that didn't exist in the library. Part of it was unfamiliarity with the tool: often the designer just didn't know how to customize an item that was already a component.

I reviewed every screen before handoff, flagging what was outside the library, and trained the team in Figma. For what was missing, I created a Figma file I called the parking lot. Designers dropped the component they had made there, and I reviewed it, fixed what was off-standard and promoted it to the library.

1. New component
2. Parking lot
3. My review
4. Library

Before handoff, every screen went through the same review.

Around the system, I ran its governance, with a changelog and versioned releases, and created the team's workflows: requesting a new component, validating and auditing screens, handoff and a post-development acceptance checklist.

In about 2 months, the team was building screens with the system alone and requesting what they needed. The price showed up in time: the system took about 2 years to become solid, because I was the only one looking after it while also handling all of the team management. And the project changed direction midway, which made me redo a few things.

I tried to stop off-system components with a rule and couldn't. The review worked because leaving the system always meant redoing a lot of work, and the team learned that in practice.

Leading the team, then getting hands-on

At first, my role was heavy on management: recurring feedback, 1:1s, design critique, development plans on my own initiative, input into performance reviews and team meetings. I calibrated what the team stood on: the design system, the team routines and the design vision of where we wanted to go.

With the team more independent, I joined the core squad to design the main features, without fully letting go of leadership. Staffing was the account's call, and over time the team shrank to me and 2 other designers.

The first front was the product configurator, the core of the business. We tested a few versions with real users (I ran the sessions together with another person on the team), and the configurator was one of the things customers praised most until I left. The track grew to cover practically the whole e-commerce, with price negotiation inside the platform instead of over email.

The result

The 4 systems became 1 platform, used on 3 continents by customers, agents, distributors and architects. Each brand has its own portal, with its own name; Cooper Lighting's is live as the PRISM Portal. From inside one portal, an agent, for example, switches to another brand's portal to find that brand's products. The design system lived through all 5 years I spent on the project.

There was no metrics dashboard, so I measured with what I had: design tasks closing in Jira and my own time in the squad. Once the patterns matured, the time to design and deliver screens dropped by 50% to 70%. In the accessibility audit, contrast and typography almost always passed, because the library was built on those rules from the start.

Before · simple flow3 days

With the patterns ready1 day

The team gained decision-making autonomy, started communicating asynchronously and redid less work.

What I would do differently

It was a market I had never worked in, and it took me a while to understand what the company did. There were several insecurities, and because of them I put little of my product vision and visual refinement into it, even though I had the autonomy to do so.

There was also no clear roadmap of features and screens, cascaded by delivery priority, and the work got somewhat lost. That was a mistake of mine and of the project's management. I would set a baseline on day one, to show the before and after in numbers, and I would push for more contact with the design team outside the project.