From Brand Guidelines to Design System

Introduction

In 2023, Zeigo was acquired by Schneider Electric and folded into a newly formed portfolio of decarbonisation products. The brand team kept the Zeigo name as an endorsed brand spanning the portfolio — and the legacy product I had been designing for two years became Zeigo Power.

A refreshed brand came with that transition. Marketing compiled new guidelines and handed them over. What didn't come with the handoff was any equivalent translation into the product layer: no tokens, no system, no behavioural patterns. I was the sole designer on Power, and the work described here ran for six months alongside ongoing product work — using the rebrand as a moment to put a foundation underneath the product.

This case study sits alongside Increasing the Uptake of Renewable Energy, which covers Zeigo Power as a product. This one covers the layer beneath — the visual identity and design system that made the product's surface coherent.

The Problem

Power had been built without a system. Two years of product work had accumulated inconsistencies — components varying across surfaces, padding applied differently from screen to screen, colour usage diverging between what design had specified and what engineering had implemented.

Handover documentation was verbose because each release had to re-justify spacing, colour, and border decisions from scratch, and engineering carried the cost of that in post-release revision. The tech team described labelling as one of the hardest parts of their role — inconsistencies arising from "strange" conventions they didn't have a shared vocabulary to push back on.

There was no formal brief — I treated this as foundational work the product needed, and hoped the wider portfolio might adopt it as it formed.

The Approach

I built the system's primitives first — leaning on mature design systems rather than inventing from scratch — and applied them back to the product afterwards. Auditing Power's inconsistencies first would have produced a system shaped by accumulated compromise; building the primitives independently kept the application phase a clean translation.

Schneider Electric had a parent-level design system, but Zeigo's endorsed brand status gave the portfolio licence to define its own visual language. Icons were the only meaningful inheritance.

Key Design Decision: Application as Source of Truth, Figma as Reference

The source of truth for the system lived in the application, not in Figma. Tokens, components, layout patterns — the canonical values were in code; Figma held a reference.

The workflow followed from that: changes were proposed in Figma, raised as tickets, applied in the application, and the Figma library was brought back into alignment afterwards. The library was a working copy — it existed so designers could compose screens against an accurate reference, not so it could define values downstream. Storybook sat alongside the application — designers could see components in their built form without going through Figma.

Figma's native variables didn't exist yet, so the Figma Tokens plugin offered the only shortcut: maintain token JSON inside Figma, push it to GitHub, let Figma define the values the application consumed. We experimented with it — the plugin shortened the route for proposing changes, not the direction of authority.

Key Design Decision: Inherit Structure from Mature Systems

Each primitive was anchored to a different reference. Radix — recommended by engineering — provided the foundation for colour: scale structure, naming numerics, built-in light and dark mode handling. Carbon informed spacing and the typographic scale. Nordic Health contributed naming conventions. BBC GEL provided the model for typography labels — size, weight, and line-height combined into named roles. Inter was the font choice, picked for clarity at small sizes, which mattered for Power's data-dense surfaces.

Colour: Radix and Prism

Colour was the first primitive I tackled — it sat between marketing, who had handed over the brand guidelines, and engineering, who had a strong view on the library underneath. Resolving colour first meant the rest of the system could be built against a foundation both sides recognised.

Marketing's input was three anchor hues — Zeigo Purple, Zeigo Light Blue, Zeigo Light Purple — provided as single values, not scales. I renamed them inside the design system to Trendy Pink, Picton, and Cloud Burst because Zeigo Purple and Zeigo Light Purple were too close to read apart at a glance, and I wanted the brand names to sit cleanly alongside the rest of the raw palette.

Marketing kept their own names; the renames lived only in the digital system. In retrospect nothing was gained from that — a zeigo- prefix on the original names would have done the same disambiguation without forking the vocabulary.

Engineering's recommendation was Radix, and once I looked at it properly the choice was easy to defend. The Radix team had done the contrast and step-usage research we didn't have time to redo, and the twelve-step scales shipped with parallel light and dark variants per hue — dark mode was a structural property of the palette, not something bolted on later. That paired-theme architecture is what made the rest of the colour work tractable.

My first attempt at the brand scales was to build them by eye in Figma. It looked right at a glance but didn't hold up — hue, saturation, and brightness were drifting between steps in ways the scale couldn't absorb. Prism, GitHub's open-source colour tool, solved this properly.

I sampled the HSL shape of an equivalent Radix scale and used the brand colour itself as the baseline, producing brand-aligned scales that held the same shape as the rest of the system. Light and dark variants were generated together, so each brand hue arrived in the system as a paired theme rather than a single value waiting to be matched.

One of the brand hues didn't quite resolve against the Radix shape — its lightness, hue, and saturation sat between steps 11 and 12, and forcing it into either neighbour distorted the scale. The pragmatic fix was an additional 11.5 step at the primitive layer, holding the exact brand value as a usable token for branded surfaces. The anomaly stayed contained to primitives; dark inherited the 11.5 variant alongside it.

Generating light and dark together at the primitive layer turned out to be the system's most important property. Every layer above the primitives inherited a dark variant by default — including the 11.5 — so the guess-work that usually makes dark-mode brittle never had to happen.

Above the raw scales, six semantic families grouped them into the categories the system used — Primary, Accent, Neutral, Danger, Success, Warning. Radix also published guidance on how each step in its scale was intended to be applied, which gave design a clear mapping from the semantic scale into the component tokens — the component layer wasn't being invented from scratch.

Spacing, Typography, Naming

Spacing came directly from Carbon. The typographic system followed BBC GEL — including its vocabulary. Named roles like Canon, Paragon, Pica, and BodyCopy combined size, weight, and line-height into composed tokens, with -bold and -semi variants on each.

Naming followed a three-part taxonomy drawn from a simplified read of Nathan Curtis with cues from Nordic Health — an Object (Component or Element), a Base (Category and Property), and a Modifier (Variant, State, or Scale). The first cut was more verbose — fully qualified names like --zeigo-power-button-primary-disabled — but engineering only ever used the simplified elements, so the system met them where they were. --color-font-disabled reads as Category (color) / Property (font) / State (disabled), and the same shape extended through state and variant modifiers (__hover, _compact) where components needed them.

Key Design Decision: A Semantic Alias Layer — and Where It Met Engineering

The token architecture had four layers, not two. Raw hex values fed into a Core layer that preserved Radix's named scales (color-mauve-12, color-blue-9). Above that, a Semantic layer abstracted those scales into purpose-led families (color-neutral-12, color-primary-9). Above that, a Component layer named tokens by where they were used — color-font, color-font-disabled, color-border. Each layer let the one below it shift without breaking the contract above. The 11.5 step lived only in the raw primitives — the Semantic layer above it mapped against the standard twelve, so Primary, Accent, and the rest stayed legible to engineering's existing Radix-shaped mental model.

This was where the system met its limit. Radix's own documentation describes how each step of its scale should be applied to components — step 6 as a border, step 9 as a solid background. Engineering had absorbed that pattern and reached past the Component layer, applying step semantics at the Core or Semantic level.

A border that should have consumed color-border was being set directly to color-neutral-6. Nothing was technically broken, but the abstraction wasn't being used the way it was designed: a four-layer chain was collapsing into one. It's a gap I'd close differently if I were starting again — by treating engineering's mental model as a co-equal input to token design.

Layout Patterns

I tokenised two layout patterns — --layout-feature and --layout-split-detail — to absorb the most common page structures. Feature — left-hand navigation, header with page title, consistent padding across the content region — was the standard for primary surfaces. Split Detail extended Feature with a second left panel for contexts where a list sat alongside a detail view. Interaction patterns were left undefined at this layer.

Components: A Working Reference, Not a Library

A small set of basic components lived in Figma — tags, callouts, toasts, profile blocks, segmented controls, form inputs, file uploads, dropzones — enough to let screens be composed against the tokens without rebuilding primitives each time. They were kept deliberately shallow. Any change followed the same route as a token change — documented, ticketed, applied in code, then brought back into the Figma library afterwards.

A second, narrower set covered Zeigo-specific shapes that recurred across the product — AppBar, Offer Cards, Index Card, TenderHeader, ProgressJourney. These stayed intentionally basic too, broad enough to be picked up across wider Zeigo efforts without encoding behaviour the application would have to argue with later. Anything past the basics I designed on top of a screenshot of the live application rather than reconstructing it in Figma — faster than maintaining a parallel surface, and honest about where authority sat.

Stakeholders

The audiences were internal. Marketing handed off the brand and stepped back. Engineering was the most-affected user and the closest collaborator — suggesting libraries, surfacing implementation constraints, and shipping against the system while design owned the conventions. Other designers across the wider Zeigo portfolio were the audience the work didn't reach: as the portfolio formed, other products carried their own interpretations of the brand, and the work I'd done was offered, not adopted.

Results

The system shipped and applied across Zeigo Power within six months. The concrete deliverables were a raw palette with semantic alias tokens; naming conventions for colour, spacing, border radius, and typography; parallel light and dark mode support; and the two named layout patterns.

Screens read as one product for the first time, and the padding and layout drift that had accumulated over two years resolved in the surfaces that adopted the new patterns. Engineering handover documentation became shorter — components could reference shared primitives rather than re-justify each decision — and post-release revision dropped. None of this was measured. The signal was a general drop in revision tickets and direct feedback from engineering, who told me the shared conventions and documentation had made their work easier.

The cost of the system not reaching beyond Power became visible later, when I moved into the design lead role across the portfolio and saw the system-level breakdowns across products that would have needed overhauls to bring back into alignment.

Reflection

The single thing I would do differently is push for portfolio-wide framing at the start, rather than treating this as a Power-internal initiative to share outward once ready. Including wider partners — designers on other products, marketing, design leadership across Schneider's Sustainability division — from the first week would have changed the conditions for adoption.

Two challenges weren't addressed: accessibility, and standard behavioural patterns at the component level. Accessibility was the more conspicuous omission — the system was built without a defined contrast or focus-state framework, and colour scales weren't tested against WCAG criteria at the alias layer.

Component behaviour at the system layer — state transitions, validation flow, empty-state and error-state composition — was left to existing convention. The visual states existed; the rules for when and how they composed at the surface level didn't. Both were deliberate scope decisions given the time, but they're the layer that would now be the most valuable next step.

The clearest principle to come out of this work is that the source of truth has to live in the application, not the design tool. Figma as reference, not authority — that's what keeps design and engineering honest.

Foundations can be built quietly and well by a single designer with time and care. What they can't do is scale across an organisation without being held by a wider mandate. That's not a craft problem — it's a positioning problem, and one I'd treat differently next time.