Pick your colours from a UI library’s palette, not from a colour picker, because every hue has a narrow range where it looks vivid and the shades in those palettes are already adjusted for screens. Then skip the online palette generators and build your palette from a checklist instead: one primary colour, a few accents with jobs, and eight to ten greys.
People have got weird about colour in AI-built apps. The advice going round is “avoid purple”. Purple is a whole colour. Nobody avoids a whole colour.
What makes an app look cheap is not which hue you chose. It is two habits that are easy to fall into when you are picking colours for the first time. Drop them, and most of the battle is won.
1. Don’t pick colours with a colour picker
A colour picker hands you millions of colours and tells you nothing about any of them. Dragging around until something looks about right is how most people start, and it is the reason so many apps end up a muddy version of the colour they meant.
The problem is easier to see once you know how a colour is described. Designers talk about colour in HSL: its hue (which colour it is), its saturation (how vivid it is) and its lightness (how light or dark).
The three dials of HSL. Every colour you will ever pick is a position on each one.
Every hue has a sweet spot: a narrow range of saturation and lightness where it looks vivid and like itself. Move away from it and green goes swampy, yellow goes brown and violet goes grey. The sweet spot sits in a different place for each hue, because our eyes see some hues as brighter than others. A colour picker gives you no help finding it, and you will not land on it by accident.
Each hue from dark to light at full saturation. The marker is where Tailwind sets the main shade, and it sits somewhere different on every strip.
Then there are the shades. An app needs light and dark versions of each colour, for backgrounds, borders and text, and the obvious way to make them, sliding the lightness up and down, leaves them washed out. Lighter and darker shades only look alive if the saturation is pushed up as the lightness moves away from the middle, and the hue is allowed to drift a little towards a brighter neighbour as the shade gets lighter and a darker one as it gets darker. [1]
The same teal as nine shades, twice. Sliding the lightness alone leaves the ends flat; raising the saturation towards the ends keeps every shade looking like the colour.
You do not need to learn any of this, because someone has done it for you. The popular UI libraries, the toolkits developers build interfaces from, each publish a full palette with the shades already worked out for screens. I use Tailwind’s; Google’s Material and Radix are also good. Pick one, use its colours, and the sweet spots and the shades come with it.
Tailwind's palette: twenty-two colours, each in eleven shades with the sweet spot and the shade curve already applied. Material and Radix publish the same kind of thing.
2. Don’t use an online palette generator
The online palette generators are the other trap. They give you five swatches that sit nicely together on the page and leave you to work out which one is the button, which is the warning and what the text goes on. Build an app from those five and it ends up looking something like this.
A tasks screen built from the five swatches a generator gave. Every element is fighting for attention, and nothing wins.
An interface needs more colours than five, and most of them are not colours at all. Here is the checklist I work through instead, shown on an invoices screen where each colour earns its place in turn.
One primary colour, maybe two. It goes on the key buttons and on whatever is active: the thing the user is being asked to do, and the tab or row they are on. Nothing else gets it, which is what makes it mean something.
A few accent colours with jobs. Red for errors and anything dangerous, such as a failed payment or a delete. Yellow for warnings, such as a card about to expire. Green for good news, such as a trend going the right way. Then one secondary accent for the odd thing that needs to stand out and is none of those, such as a New badge. Each accent appears only when its job comes up. [1]
Eight to ten greys. From nearly black to white: text, secondary text, icons, lines, backgrounds and the page itself each take a different one. This is the part a five-swatch palette leaves out entirely, and it is what gives an app its polished look. Pull the greys from the same library as your primary colour, so they share its temperature.
The checklist on one screen: grey first, then one primary colour where the action is, then an accent only where it has a job, and ten greys doing most of the work.
That is the whole method: one primary, a few accents with jobs, a run of greys, all taken from a palette whose shades were made for screens. Purple is welcome.
Sources
Adam Wathan and Steve Schoger — Refactoring UI, the chapter on colour.
Where the shade method and the accent-colour jobs come from: saturation kept up as lightness moves away from the middle, a small hue shift towards a brighter or darker neighbour, and the finding that an interface needs far more greys than colours. The graphics on this page are my own; the book’s are better.
The book’s website.