Forge NEXUS: 4-Tier Variable Architecture
The Forge reference apps needed more than a component library. They needed a variable-driven design system that could turn visual decisions into reusable product logic. The wider context was Deltatre’s Hybrid / NEXUS proposition, but my role was focused on the structure underneath the interface. I worked on the creation of the variable architecture. The aim was to define how design decisions should be named, layered and inherited, so the system could support theming, dark mode, reference apps and future product variation without relying on manual overrides.
1. Problem
The existing design system had strong component-level thinking, but it needed a clearer foundation.
When a system only operates at component level, every decision sits too close to the interface. A button owns its own colour. A card owns its own surface. A widget owns its own border. A hero owns its own overlay.
That can work for one product.
It does not scale across multiple clients, brands, modes and platforms.
For Forge, this created a familiar design-system risk: an explosion of styles. Similar patterns could start to drift because there was no structured relationship between raw values, brand expression, product meaning and component implementation.
The problem was not only consistency.
It was differentiation.
Clients need their products to feel ownable. A platform cannot feel cookie cutter. It needs to support recognisable brand expression while still protecting the integrity of the product system underneath.
That tension is especially complex in sport.
A single experience may need to carry a main client brand, sponsor brands, team identities, competition branding and campaign treatments. Those layers need flexibility, but they cannot be allowed to override the system at random.
The design system needed more than consistency.
It needed controlled flexibility.
2. Context
Forge sits within a broader product ecosystem.
The reference apps needed to demonstrate how editorial content, live and on-demand video, sports data, navigation and commercial modules could come together in a premium sports experience.
The Hybrid / NEXUS context made the system requirements sharper. The product needed to support multiple platforms, multiple clients and multiple types of fan experience. It also needed to remain flexible enough for different brand treatments while keeping implementation manageable.
This meant the system had to solve two competing needs.
It had to create a repeatable product foundation.
It also had to allow each client implementation to feel bespoke.
In sports products, brand expression is rarely singular. The main product brand may sit alongside sponsor colours, team colours, league identities, tournament branding and editorial campaign treatments.
Without a clear variable architecture, those needs quickly become exceptions.
A sponsor module gets a one-off treatment.
A team page introduces unmanaged colours.
A competition campaign changes the visual hierarchy.
A client asks for more brand presence and the component layer absorbs the pressure.
Over time, the system becomes harder to govern.
That meant the design system could not be built only from screens.
It needed a variable architecture.
A raw colour needed to be separated from a theme decision.
A theme decision needed to be separated from semantic meaning.
Semantic meaning needed to be separated from component behaviour.
That became the basis of the 4-tier model.
3. My role
My role focused on creating the variable structure for the Forge reference app design system.
I worked hands-on with Figma variables, token hierarchy, naming logic and component mappings. I also used AI as part of the workflow, combining NotebookLM research synthesis with ChatGPT-assisted prototyping.
NotebookLM helped me compare collected design-system resources, identify recurring principles and test whether the architecture aligned with wider industry practice. ChatGPT helped me rapidly explore token structures, naming options and front-end mappings.
The design decisions remained mine.
AI was used as a thinking and prototyping partner, not as a replacement for judgement.
I helped organise the system around four layers:
Primitive
Theme
Semantic
Component
This structure created a clear chain of responsibility.
Primitive values hold the raw materials.
Theme values define brand expression.
Semantic values define product meaning.
Component values define implementation behaviour.
The work was deliberately practical. It was not just about naming tokens. It was about deciding where product decisions should live.
4. Process
The process started with research and audit.
I collected examples from design-system books, public design systems, token specifications and practical UI guidance. I used those references to identify repeated patterns: how mature systems separate raw values from semantic intent, how they support theming, and how they maintain a usable bridge between design and code.
That research reinforced a simple point.
A design system becomes valuable when it reduces repeated decision-making.
Without a system, designers spend too much time moving pixels, repeating explanations and manually correcting inconsistencies. With a system, decisions are captured once, named clearly and reused through the product.
I then reviewed the Forge structure through the lens of variable ownership.
What is the raw value?
What is the brand expression?
What is the product meaning?
Where is it applied in the interface?
Which layer should flex for client differentiation?
Which layer should remain stable to protect product consistency?
Those questions helped define the four layers.
A colour scale belongs at primitive level.
A brand accent belongs at theme level.
A surface role belongs at semantic level.
A button hover state belongs at component level.
This gave the design system a clearer logic.
It also made the system easier to explain.
5. Key design decisions
Build from primitives, not components
The primitive layer became the foundation.
This layer contains raw values: colour scales, neutral palettes, opacity, spacing, radius, elevation and type values. These values are intentionally context-free. They should not know whether they are being used by a button, card, overlay or navigation item.
That neutrality matters.
Primitives create stability. They give the system a controlled set of ingredients without forcing product meaning too early.
Use the theme layer to support differentiation and system constraints
The theme layer was essential because Forge needed to support controlled brand expression.
This was not just about changing colours.
It was about enabling client differentiation without creating a bespoke system for every implementation.
A client may need their site to feel premium, editorial, energetic, club-led, broadcaster-led or sponsor-led. A competition may need a distinct campaign treatment. A team page may need team colours. A commercial module may need sponsor expression.
The system needed to allow that flexibility without allowing every surface to become an exception.
A key constraint was that Forge only allowed a limited number of colours to be defined in the theme. This made the architecture more important, not less.
The system had to make those limited colours work harder.
The theme layer became the place where main brand colours, accents and key product tones could be defined centrally. Those values could then flow into semantic roles and component states.
This prevented brand styling from being scattered across the interface.
It also made theming more deliberate.
Use semantic variables to define intent
The semantic layer was the most important part of the architecture.
Semantic variables describe what a value does.
Surface.
Content.
Border.
Icon.
Action.
Overlay.
Focus.
Disabled.
Success.
Warning.
Error.
These are product roles, not visual descriptions.
A primitive value tells you what something is.
A semantic value tells you why it exists.
That distinction is critical in a scalable design system. It allows designers and developers to talk about intent rather than individual colour choices.
It also protects flexibility.
A theme can change, while the semantic role remains stable. That means the product can feel branded without changing the logic of the interface.
This is what helps prevent the system from feeling cookie cutter.
The same component can inherit different brand expression while preserving a consistent product model.
Keep component variables close to implementation
The component layer translates semantic intent into usable UI behaviour.
Buttons need default, hover, pressed and disabled states. Cards need surfaces, borders, metadata, image overlays and focus treatment. Sports widgets need hierarchy, status and supporting data states.
This layer makes the system buildable.
It gives developers practical mappings while preserving the intent defined in the semantic layer.
The aim was not to make every component independent. The aim was to make every component inherit from the right layer.
Design dark mode through the system
Forge reference apps are media-led.
They use video, photography, editorial layouts and data overlays. That makes dark mode a system requirement, not a cosmetic option.
The variable structure needed to support surface, content, action and overlay roles across light and dark modes without creating separate screen-level fixes.
This is where semantic variables became especially valuable.
The component behaviour could remain stable while the underlying semantic values changed by mode.
Use AI to test structure, not replace judgement
I used ChatGPT to vibe code the variable structure and explore how the system could translate from Figma logic into front-end implementation.
This was useful because a variable system can look coherent in a diagram but fail when applied to real UI states. AI-assisted prototyping helped test token inheritance, naming logic and component-state coverage more quickly.
The output was not treated as final.
It was reviewed, questioned and refined against the design-system goals. The value of the workflow was speed of exploration, not automated decision-making.
This also changed the way I worked.
Instead of using AI to produce a finished answer, I used it to generate options, expose gaps and pressure-test assumptions. The variable structure became more robust because it was repeatedly tested against real implementation scenarios.
6. Outcome
The work created a clearer variable-driven foundation for the Forge reference apps.
It moved the design system away from isolated component styling and towards a layered model of product decisions.
The 4-tier architecture supported:
clearer Figma variable organisation
controlled brand theming
client differentiation without bespoke rebuilds
better use of Forge’s limited theme colour model
semantic roles for product meaning
sponsor, team and competition brand flexibility
light and dark mode adaptation
component state mapping
stronger design-to-code handover
reduced manual overrides
faster exploration through AI-assisted prototyping
The system became easier to reason about.
Instead of asking which colour should be used, the team could ask what role the value needed to play, and which layer should own the variation.
That is a stronger design-system conversation.
7. Impact
The main impact was structural clarity.
The variable architecture gave designers a more reliable way to make decisions. It gave developers a clearer path from design intent to implementation. It reduced the risk of disconnected styling across reference apps, themes and product surfaces.
The wider impact was scalability.
Forge and NEXUS needed a design foundation that could support future product variation without creating new systems for every client or proposition. A variable-driven architecture made that possible.
It allowed the product to stay flexible while keeping the design language controlled.
It also supported a more commercially useful model.
Clients could have stronger brand differentiation without pushing the platform towards one-off design work. Sponsor, team and competition identities could be accommodated through the system rather than treated as exceptions.
That is the value of a mature variable architecture.
It gives clients room to feel bespoke while giving product teams a structure they can maintain.
For me, the project reinforced the importance of hands-on systems craft.
Design systems are not only made from components. They are made from decisions: where those decisions live, how they inherit meaning, and how safely they can change.
A good variable structure turns design intent into product infrastructure.
