Interface-Ready Colour
Enough range for states, not three brand colours.
A customer sees the marketing site once and the product every working day. SaaS branding therefore has to work inside an interface — where colour has to carry meaning, contrast has to be accessible, and a brand palette designed for a hero image becomes actively unusable.
A brand that only works on a marketing page is a brand your customers barely see.
Enough range for states, not three brand colours.
Because the product is used all day.
Error and success are not brand decisions.
At interface sizes, not display sizes.
Marketing and product sharing tokens.
Four things a marketing-only identity does not provide.
Discuss Your Brand →Tints and shades for surfaces, borders and states.
Text on every background, meeting contrast requirements.
Success and error colours distinct from brand colours.
Which most products now need and most palettes do not support.
An identity that works in the product and on the site.
The design system itself is covered by design systems services.
Start from what the interface needs, then extend outward to marketing.
What colours and states the product requires.
A full range with accessible pairings.
States that do not depend on brand colours.
For a favicon and an app bar as much as a website.
From the same tokens.
An interface needs dozens of values, and a marketing palette supplies three.
Surface colours at several levels, border colours, text colours at two or three weights, hover and active states, disabled states, focus indicators, and semantic colours for success, warning and error.
A brand palette of three colours plus black and white cannot supply that, so the engineering team invents the missing values ad hoc — and they diverge across features.
Supplying a full range at the branding stage prevents that, and it is a small amount of extra work at the point the palette is being decided.
Because error and success need to be unambiguous, and tying them to brand colours makes them ambiguous. A product whose brand colour is red cannot use red for errors.
Users read these colours by convention, and a brand-driven deviation costs comprehension for a gain that nobody notices.
Defining them as a separate set, derived for accessibility rather than for brand consistency, avoids the argument entirely.







SaaS branding builds an identity that works inside a software product as well as on a marketing site — a full interface palette, accessible pairings, separated semantic colours and type that works at small sizes.
Because an interface needs dozens of values — surfaces, borders, states, semantics — and a marketing palette supplies three. The engineering team then invents the rest, inconsistently.
No. Users read success and error by convention, and tying them to brand colours creates ambiguity. Define them as a separate accessible set.
Most products now do, and it should be designed rather than derived by inverting the light palette, which produces poor contrast and muddy colours.
Branding defines the tokens; a design system turns them into components. Doing them together avoids the palette being reinvented at implementation.
Still deciding if saas branding is right for you?
Talk to UsA brand palette arrives with three colours, black, white and a couple of greys. It is well chosen, it works beautifully on the marketing site, and it is signed off.
The product needs a disabled state, three surface levels, a border colour, a focus ring, and distinct treatments for success and error. None of those exist, and features ship weekly.
So each developer picks something reasonable, and eighteen months later the product contains fourteen greys, four blues that were all meant to be the brand colour, and an error red that nobody chose.
Show us your product and your brand palette. We will tell you what the interface is missing and where colours have diverged.
