One design language for three products

Overview

We were two designers responsible for three operational products. Each one had its own development team, its own users and its own context: some screens are used on a phone in the field, others on a large screen in a control room.

Over time, every product had grown its own buttons, inputs, colors and patterns. Our job was to bring them under one roof: a single design system that all three teams could build from, while each product kept its own identity.

The products are confidential, so the names and content on this page are neutral stand-ins. The interactive examples are rebuilt from the real design tokens and component structure.

The challenge

Three products, three teams and two platforms meant the same question was being answered again and again: what does a primary button look like here, how does an input show an error, which gray is the secondary text?

• Different contexts. Two products are dark, mobile-first and used on the move. The third is a light web system for managing data in large tables.
• Different teams. Each development team kept its own version of the UI, so a fix in one product never reached the others.
• One family. Users move between the products, so they had to feel like one family: same patterns, same behavior, same language.

The goal: design a component once, and let it adapt to every product, platform and theme without being redrawn.

One core, three themes

The heart of the system is a three-layer token structure in Figma variables. Components never use raw colors. They point to semantic tokens, and each product maps those tokens to its own palette.

Because of this structure, adding a new product, or a new theme, means mapping one set of semantic tokens. No component has to be touched.

One component, every scenario

The most interesting decisions were about single components. We would take one element, a button or an input, and follow it through every place it appears in all three products until it could handle every scenario on its own.

1. AuditCollect every version of the component across the three products, on web and mobile.
2. Define the anatomyAgree on the parts, the properties and the states, and what each one is for.
3. Build it onceBuild one component set with variants and properties, connected to tokens instead of fixed colors.
4. Test it in contextDrop it into real screens of all three products, in light and dark, and fix what breaks.
5. Document and hand offWrite down usage rules and share them with all three development teams.

The button

The primary button set alone grew to 79 variants. In practice, a designer or developer only needs to answer four questions: which product, which size, which type and which state. Try it:

Two rules kept the set small enough to use. Hover and pressed states are derived from the brand color instead of being picked by hand, so they work in any product. And success and destructive colors come from the shared alert tokens, so "delete" looks the same everywhere.

The input

Inputs carry more of the work in these products: forms are long and often filled in on the move. Instead of separate components for every case, one input has properties that can be switched on and off.

Foundations

Under the components sit the foundations every product shares: color with dark mode and contrast checks, typography, iconography in five sizes, elevation and blur.

Typography

All three products use Heebo, chosen for its clear Hebrew and Latin letterforms and its readable figures. The products are right-to-left, so every component was built and tested for RTL first.

Color and contrast

Every text color was checked against its background, with contrast ratios documented next to each swatch. Alert colors are shared across products so status always means the same thing.

Working with developers

A design system only works if the people building the products use it. Being only two designers for three teams, we had to make the library easy to find, easy to read and easy to trust.

• One library, one source of truth. All three teams worked from the same file, organized from foundations to components to patterns.
• Names that match the code. Token and property names were written so developers could map them directly to their own variables and props.
• Shared documentation. Usage rules and specs were shared across the development teams, so a decision made with one team reached the other two.
• Two designers, one voice. We split ownership by component, reviewed each other's work and agreed on rules before building, so the library stayed consistent.

Outcome

The three products now share one design language, while each keeps its own theme. Development became easier: teams build from ready components instead of recreating them, and documentation is shared between them instead of living in three places.

What I learned

• Structure beats screens. The token layers did more for consistency than any single screen we designed.
• Start from the hardest case. Designing a component for its most demanding scenario first made the simple cases come for free.
• A system is a service. Documentation and conversations with developers mattered as much as the components themselves.