How to design one component many brands can reuse without making it generic

To design a component several brands can reuse, decide what it holds constant before deciding how it looks. Find the shape every brand or case shares, make its states, frame and actions identical, and give the real differences one bounded slot. Design tokens then carry each brand's colour, type and logo, but they cannot rescue a component whose structure was settled for only one brand.

Theming is the part of a multi-brand design system that standards and tools now serve well. The harder decision, and the one this page is about, is what the component is.

Theming decides how a component looks, not what it is

Brand theming has become a well-supported problem. On 28 October 2025 the Design Tokens Community Group, a W3C community group, announced the first stable version of its specification, with brand themes and light and dark modes "without file duplication" among its new features. Its Resolver Module shows a brand modifier with two brand contexts beside a light and dark theme modifier, and says why it exists: alternate contexts "are susceptible to combinatorial explosion". It is a community group report, not a W3C Standard, but the group says more than ten design tools and open-source projects support it or are implementing it.

Two media groups with several titles show the same approach. News UK's NewsKit design system uses its theme so that "the brand identity" can be managed "from a single location across multiple products", through foundations, presets and component defaults (NewsKit theme overview). At Condé Nast, according to frontend developer Mason Wendell, a single token can hold a different value for each brand: the token "prominent text" refers to a different font for each brand (Figma, 2020).

All of this answers how a component looks for each brand. None of it decides which parts every brand gets, which states the component has, or where one brand's needs may differ. A card can be themed perfectly and still be the wrong card for the second brand that tries to use it.

Two ways a shared component fails

When a second brand or context needs something the component lacks, there are two quick fixes.

A variant for every case. Each new brand, sport or market gets its own prop, variant or copy. Each request is easy to grant, and the component stops being one thing. Independent options multiply: two on-or-off options give four combinations to design, test and document, and three give eight. The token standard names this problem for token values; component options follow the same arithmetic, and no token file catches it.

One generic component. The opposite fix keeps a single component by removing anything specific to one case. It is easy to maintain and fits everyone loosely. The cost moves to the reader, who gets less than they came for.

Both fixes avoid the same decision. One says yes to every difference; the other says no to all of them. Neither settles what the component is.

Hold the shape constant and give the differences one slot

The method has four steps.

1. Find the shape every case shares. Not the visual style but the structure of the job: the states the thing passes through, what a person needs in each, and the actions available.
2. Make that shape identical everywhere. The same states, the same frame and the same actions in the same places, for every brand and case.
3. Give the real differences one bounded slot. One area of the component may change by case, within limits the system sets.
4. Test the model against the hardest cases before calling it shared. If the hardest case fits inside the same states, the model holds. If it does not, you have learnt something about scope before any brand ships it.

This applies an old software-engineering idea to interface components. In 1998 James Coplien, Daniel Hoffman and David Weiss, writing from Bell Labs, described scope, commonality and variability analysis in IEEE Software. A commonality is "an assumption held uniformly across a given set of objects"; a variability is true of only some of them. In their device example the commonality is a standard interface and the variability is the device-specific control code behind it, and the cost of adding a new device depends on how well it conforms to that interface. In a shared component, the states and frame play the part of the interface, and the slot holds what differs.

Slots now exist on both sides of the design-to-code handoff. In the HTML Standard, the `slot` element "defines a slot": a place in a web component where content supplied from outside is shown. In Figma, slots are areas inside a main component where designers add and arrange content without detaching the instance; the component owner can offer a list of preferred instances and set minimum and maximum layer counts, which warn rather than block. Use those limits. A slot with no limits is a generic component by another route.

One match card for seven sports

At Tcules, we worked as an embedded design partner with the editorial, product, growth and platform teams at Ringier, the Swiss media group; by January 2026 we had worked on more than thirty projects together. Its brands, among them Blick, cash.ch and Bilanz, share technology and a design system, so a component designed for one can appear on all of them. That raises the bar for every design request: a card, a page or an email has to work for the brand that asked for it and for the brands that may use it next.

Blick's match widget was designed first for football and ice hockey. The brief added handball, tennis, Formula 1, alpine skiing and Schwingen, and each keeps score differently: tennis counts sets and games, Formula 1 lists positions and time gaps, and skiing ranks racers across two runs.

We weighed three directions, which match the two failures and the method above:

We chose the third. Every sport shares the same three states. Before the event, the card shows the start time and a link to more information. Live, it turns green, carries a live label and shows the running score, period or lap. Afterwards, it shows the final result and, where one exists, a highlights video. Only the score area changes from one sport to the next.

The hard cases tested the model. Races with a full field instead of two opponents, qualifying sessions and multi-stage events each needed their own score layout, and each fitted inside the same three states. For Formula 1 and skiing, the score area became a ranked top three with time gaps. For tennis, it became a row per set.

Once the shape held, it travelled. The same cards fed a compact sport calendar for the home screen. The same approach shaped other shared components, such as an image gallery designed once for mobile, desktop and full screen, and a recipe page built to work for every brand; the Blick+ offer page layout was built to be reused across brands. We set out the design decisions and the way we worked in our Ringier case study; we claim no adoption, engagement or subscription results for this work.

A four-question test for any component request

Before building or extending a shared component, ask four questions. The answers show whether the request is for a shared component or a local one.

Then take the hardest case you can name for the next brand and draw it inside the shared states. A full field instead of two teams, a multi-stage event, a plan list that grows from two plans to three: if it fits in the slot without changing the states, the shape holds.

When there is no shared shape

The method is allowed to say no. Coplien and his co-authors show that changing the set changes its commonalities, and that reducing its size generally increases what its members share. If the hardest case will not fit inside the shared states, there are two honest answers: narrow the scope, so the component serves these brands rather than every brand, or accept that the case needs a different component. Either is better than a variant that breaks the shape, or a slot so open that the component holds nothing constant.

Not every component needs the strictest version either. In the same Figma article, Mae Capozzi, a former senior software engineer at Harry's, is described as trading complexity for flexibility, and she says she does not think "that there is a one-size-fits-all solution". The shared-shape method earns its cost on components that several brands use for the same job.

Where this sits in a design system

At Tcules, we treat this as one decision inside a larger system. One of the questions our Design Systems work asks is which variations are legitimate rather than drift, and every shared component has to answer it. The four questions above answer it for one component. For the system as a whole, see what to build and in what order, where your team sits on the maturity model, and how to audit a design system to find which components have already split by brand.