Token rationalisation
The source audit covers the Sass and documentation in
Energy-Saving-Trust/Design-System.
Values were extracted from 135 Sass files at commit
211b72b3f556e54e0131ba4eae968770085608c7.
The objective was to preserve recognisable EST design decisions without converting implementation accidents into permanent public API.
Colour
The five primary colours from the existing repository are retained and supplemented by the seven secondary colours supplied from the palette CodePen. Each is exposed as a 50–900 primitive ramp so the same values can be transferred predictably to Figma. Semantic tokens still expose only colours with a defined purpose.
| Source finding | Decision |
|---|---|
Deep blue #15487a, clear sky blue #aadce1, deep rose #b7133a, honey yellow #ffaf0a, grassy green #65a346 |
Retain as primary brand primitives at step 500. |
| Forest green, deep orange, bright blue, rose, apple green, light yellow and blush | Retain as secondary primitives, but do not invent semantic roles for them. Correct source spelling forrest-green to forest-green. |
| CodePen tint/shade steps | Store resolved colour values rather than Sass functions, making builds and Figma exports deterministic. Treat these RGB-mixed ramps as indexing conveniences, not perceptually uniform scales. |
Eleven-step grey ramp from #f4f5f6 to #0e0f11 |
Retain; use the UK spelling grey consistently. |
Both $gray-* and $grey-* names |
Remove duplicate aliases. |
| Bootstrap indigo, purple, pink, orange, teal and cyan families | Drop: they are Bootstrap defaults, not EST design decisions, and are unused by the documented system. |
#1f201f, #212529 and #e9ebed one-off literals |
Consolidate to the closest established neutral token. |
$primary and $secondary both mapped to grey 900 |
Keep separate semantic action roles, but allow them to reference shared primitives. |
| Green and yellow brand colours used as status colours | Keep as borders/brand accents; use darker semantic foregrounds where the brand colour fails text contrast. |
Grassy green has only 3.05:1 contrast against white and honey yellow has 1.84:1. They are not
general-purpose text colours. The rationalised success foreground is the existing darker green shade
#3d622a; warning text uses neutral grey 900.
The neutral ramp remains the curated repository ramp rather than being regenerated around grey 500.
Its light and dark endpoints are more useful for interface surfaces and text, and replacing it would
create broad visual churn without adding a meaningful capability. Information surface changes from
the old one-off #e1edfa to generated deep-blue 50 (#e8edf2) for a coherent palette.
Typography
Poppins and weights 300–700 are retained. The previous fixed 17px root is removed: body text uses
1.0625rem, preserving the intended 17px appearance while respecting the user’s root-size setting.
The old heading values included H4 at approximately 19px and H5 at approximately 21px. The new scale repairs that inversion:
| Level | Desktop | Mobile |
|---|---|---|
| H1 | 42px | 35px |
| H2 | 33px | 27px |
| H3 | 25px | 23px |
| H4 | 21px | 21px |
| H5 | 19px | 19px |
| H6 | 17px | 17px |
Spacing and shape
The old code mixed Bootstrap’s 1rem-derived scale with frequent 10px, 20px, 30px and 40px literals. The new spacing primitives use a 4px base and provide 4, 8, 12, 16, 20, 24, 32, 40, 48, 64 and 80px-equivalent steps. Component migration will map old values to the nearest intentional step and record exceptions rather than silently rounding them.
Border radii are rationalised to 4px, 6px, 8px, 16px and 32px plus a full radius. The old global
.35rem value and scattered 5px values become a single 6px medium radius.
Focus, motion and layout
The existing dual-colour focus treatment is retained: a 2px white inner ring and 4px grey-800 outer ring. This remains visible on both dark and light surroundings.
Repeated transition durations are consolidated to 150ms, 200ms, 350ms and 600ms. Existing Bootstrap breakpoints—576, 768, 992, 1200 and 1400px—are retained for compatibility.
Deliberately deferred
Component dimensions, icon sizes, complex shadows and embedded SVG assets are not foundation tokens. They will be assessed when their owning component enters the MVP. This prevents one-off values such as date-picker cell sizes or header heights from masquerading as reusable foundations.