The Heather Colour System: Category Hues Applied
The Heather Colour System: Category Hues Applied
What changed
The four category hues defined in the last release are now in use. Where the interface needs to tell one category from another, an account type, a contact type, the provenance and scope of a categorisation rule, a matched key in an import, a plan tier, it now draws on four quiet hues, a teal, a steel blue, a plum and a rose, with the category always named in words and the hue sitting beside the name as a second cue. The last interactive blues have retired onto heather, so a single accent identity now carries the whole surface. With this, category, status and accent speak one shared language, the one the last release set out.
Why it matters
Telling categories apart is a different job from signalling status, and it needs a different kind of colour. Status colours make claims, paid, owed, needs attention, and the heather accent draws your eye to what matters, so none of them is free to also mean “this is an asset” or “this is a verified rule” without muddying both. The category hues are deliberately quiet and deliberately without verdict: a hue here tells you two things belong to the same group, never that either is good, settled or wrong. That separation is what lets you scan a column of account types or rule scopes at a glance and trust that the colour is grouping, not judging.
The principle from the last release holds without exception here. No category is ever carried by colour alone: every type, scope and provenance level is named in text, with the hue only ever the second cue, so the grouping survives a colourblind reader, a poor screen or a quick glance. The hues also keep their distance from the marks reserved for proof. A rule labelled verified shows its scope in a quiet hue; it does not borrow the standing that belongs to a proven figure. A category cue groups, it never certifies.
Proof and impact
Every category hue meets the WCAG AA contrast standard against the surface it sits on, in both the light and the dark theme, and that is checkable rather than asserted: sample any hue and its background and the ratio holds. The rule that no category is carried by colour alone is a rule of the colour specification, inherited by every new control, so it cannot be dropped one screen at a time, and a hue that does not clear its contrast target does not enter the system.
There is no change to the API and no change to your data. This is the interface you see, not the kernel beneath it. There are no breaking changes.
What is next
This completes the category, status and accent migration, the user-facing heart of the colour system. The surface that carries your status, your accents and your categories is now one documented palette, and it becomes the foundation the rest of the interface is built on from here. A few elements in the dark theme are still being brought fully onto the system and can read with slightly lower contrast until they are; they carry no status or meaning, and that polish is next in line.