Building Better Colour Scales for Design Systems: A Case for OKLab
In design systems, colour has to do a lot. It supports brand identity, adapts across platforms and themes, meets accessibility standards, and still feels expressive and coherent. Yet the tools we use to manage colour haven’t kept up with that complexity.
A colour scale (or colour ramp) is a progression of variations from a base hue. When multiple ramps are combined to serve a product or brand, they form the foundation of colour variations, an essential tool in any design system. But building ramps that scale, adapt, and stay visually consistent across platforms remains a persistent challenge.
Only recently have newer colour models, like OKLab, begun to offer a more dependable foundation. OKLab is a perceptually uniform colour model, which means that changes in its values better align with how we actually perceive colour. This makes it particularly well-suited for generating consistent colour scales that feel natural to the eye, and for assembling those scales into systems that scale well and behave predictably. While there are other perceptually uniform models, OKLab stands out for being both intuitive and relatively easy to work with. It strikes a rare balance between mathematical precision and practical usability, making it especially relevant to the needs of design systems today. This article explores how the OKLab model can help solve long-standing problems in digital colour design, tracing the evolution from early print workflows to modern, perceptually consistent colour scales, and why many models commonly used today still fall short.
CMYK
Opacity-based
Lab
CAM-02
HSL
OKHSL
When colour was static: print, CMYK, and spot systems
For much of the early 20th century, visual design was largely black and white. Printing colour was expensive, technically unreliable, and used sparingly. When colour did appear, it was often added manually or through some labour-intensive methods like multi-pass lithographic processes. There was no such thing as a structured system of colour variations. If a commercial artist (as communication designers were then called) wanted red or blue, they’d choose a swatch from a supplier, cross their fingers, and hope it printed close to what they had in mind. Systematic colour variations were practically nonexistent, and the idea of building a scalable colour palette wasn’t yet part of the work process.
That began to change in 1906, when the Eagle Printing Ink Company introduced what we now recognize as the CMYK process — multiple inks used to create a broader range of colours through subtractive mixing. This marked the beginning of standardized, full-colour printing and created an opportunity for a more reliable way to reproduce colour in print.
But CMYK came with its limitations. It was very much print-bound and variation-poor. Creating tints (lighter versions of a colour) typically meant mixing in white, while shades (darker versions) were made by adding black. These adjustments were often done through halftone screening, by diluting the ink, or sometimes using completely separate swatches. Every variation had to be treated as a unique, standalone hue.
This is also how Pantone has historically approached colour. Rather than having a systematic approach to calculating scales, Pantone defines tints and shades as a distinct, arbitrary numbered swatch. There’s no assumption of a relationship between them; each value is isolated, with no logical connection to a base — in fact, there isn’t really a base that is defined as such. This made colour specification straightforward for printers but meant that designers couldn’t easily generate ramps or expand palettes without referencing entirely new swatches.
Pantone swatches
Opacity-based
CMYK-based
Some designers tried to work around these limits by faking tints and shades digitally — tweaking opacity, layering colours over black or white, and implying a kind of internal structure that wasn’t really there. It was a step toward more flexible palette building, but the results were often unreliable and hard to reproduce in print. At the end of the day, these older systems, whether it was CMYK’s mechanical mixing or Pantone’s rigid swatches, were never designed to scale. They made colour printable, yes, but not programmable. There was no logic, no structure, and no real way to build coherent, expandable colour systems. For much of the 20th century, colour was something static: picked, printed, and hoped for, not something designers could truly shape or control.
Digital design and the rise of HSV/HSL
As design moved to screens, colour began to be defined by light rather than pigment. RGB, an additive model where red, green, and blue light combine to create other colours, became the foundation for digital displays. It’s powerful and flexible, but unintuitive. To make it more usable, design software introduced alternate models built on RGB, namely HSV (Hue, Saturation, Value) and HSL (Hue, Saturation, Lightness).
As design moved to screens, colour began to be defined by light rather than pigment. RGB, an additive model where red, green, and blue light combine to produce a broad spectrum of colours, became the foundation for digital displays. It closely matches how screens emit light, making it efficient for digital display, but unintuitive for human perception. In an attempt to make it more usable, an alternate models were built on based on RGB in the late 1970s, namely HSV (Hue, Saturation, Value) and HSL (Hue, Saturation, Lightness). These aimed to align more closely with how humans see and describe colour.
These models gave designers sliders for adjusting hue, brightness, and saturation, making colour easier to explore and manipulate. But despite being more user-friendly, they were not perceptually uniform. That meant numeric changes didn’t line up with how we perceive colour differences. For example, increasing the “lightness” value in HSL could shift the hue in surprising ways. In HSV, equal steps in Value didn’t result in equal steps in perceived brightness. Saturation behaved inconsistently depending on the hue. Colour scales built with these models often felt jagged or uneven. Variations didn’t hold together, and contrast was unreliable.
HSL
✘ Uneven perceptual steps
✘ Lightness often shifts hue
✘ Requires significant hand-tuning
OKHSL
✔ Colours transition smoothly
✔ Hue remains stable
✔ Easy to generate and maintain
To address these limitations, some designers turned to more perceptually uniform models developed by the CIE (International Commission on Illumination). Introduced in the 1970s, models like CIE Lab and CIE LUV aimed to reflect human colour perception more accurately. However, these models proved difficult to use in practice. Few tools supported them natively, and converting between RGB and Lab/LUV often introduced rounding errors, making a reliable implementation challenging.
Moreover, while CIE Lab was designed to be perceptually uniform, its uniformity is only approximate. It performs reasonably well for small colour differences but tends to break down with large colour shifts, very dark tones, or highly saturated colours.
Lab (L changes, a*/b* fixed)
✘ Light tints lose chroma
✘ Steps feel uneven
✘ Colour shifts unexpectedly
Lab (Optimized by Leonardo)
✘ Hue may drift subtly
✘ Harder to edit/adjust
✘ No logical naming structure
CAM-02(Ch) (Leonardo)
✔ Consistent visual weight
✘ Requires full scale regeneration
✘ No logical naming structure
Still, the idea that colour should be treated as a perceptual space rather than just a numerical one had begun to resonate with many. It became critical in the 2010s, as big design systems such as Material from Google, Spectrum from Adobe or Gestalt from Pinterest began treating colour as a functional component rather than a decorative tool or a means of expressing brand voice.
Designers now had to build colour scales that could support dynamic themes, meet accessibility standards, and scale across frameworks. These scales needed to be flexible, logically structured, and visually coherent. Yet despite the growing complexity, most teams continued to rely on familiar models like HSV or HSL. They’d often generate base values programmatically, then manually tweak the results, exporting dozens of colour stops, adjusting each visually, and refining them through trial and error. This process worked, but it was labour-intensive, subjective, and difficult to scale.
In some cases, teams refined this approach into a craft. Take Gestalt, Pinterest’s design system, which presents a seemingly consistent colour scale. There’s no public documentation of the underlying colour model, so it’s reasonable to guess that the scales were fine-tuned by hand using HSL or a similar model — an approach that, while effective, leans heavily on human judgment rather than perceptual science. Without a mathematically uniform foundation, even small changes or additions can introduce inconsistencies, making maintenance and expansion an ongoing challenge.
Hand-tuned (e.g., Gestalt from Pinterest)
✘ Arbitrary naming
✘ Requires a lot of manual effort
✘ Relies on subjective judgment
OKHSL
✘ Naming follows perceptual lightness
✔ Scales systematically
✔ Easy to generate and maintain
In contrast, some teams with greater resources have pursued more scientific and scalable solutions. Adobe, for example, reengineered its Spectrum design system using CIECAM02-UCS, a perceptually uniform colour model from CIE, that better reflects how people see colour. This shift required significant investment — months of research, testing, and cross-functional collaboration. As part of the effort, Adobe developed Leonardo, an open-source colour scale generator designed to make their perceptual model more accessible to teams without similar resources. But even this model isn’t perfect. While it creates scales that are mostly perceptually uniform, the underlying calculations behind how they are generated aren’t very clear and straightforward. As a result, it’s nearly impossible to manually expand or adjust a colour scale created with Leonardo — any changes typically require regenerating the entire scale from scratch. Attempting to modify a CAM02-based colour scale, or pretty much anything generated in Leonardo, regardless of colour space, often disrupts its structure, demanding full recalibration and redefinition of its colour variations.
Perceptual uniformity meets practicality: OKLab
The limitations of HSV and HSL, combined with the complexity of earlier perceptual models like those from CIE, made it clear we needed a better tool — something that aligned with perception and could be used without specialized tools or expertise. In 2020, Swedish engineer and visual computing researcher Björn Ottosson introduced OKLab: a perceptually uniform colour space that is simplified and optimized for modern use (fun fact — “OK” doesn’t seem to stand for anything).
The OKLab model ensures that equal steps in its coordinate space correspond to equal steps in perceived colour difference. That makes it ideal for generating smooth, natural-looking colour scales from a base hue, simply by adjusting numeric values. Unlike CIELab, OKLab is easier to compute and to implement. To support more intuitive workflows, Ottosson also introduced OKHSL and OKHSV models that mimic the familiar structure of HSL and HSV, but with perceptual logic derived from OKLab. These models behave much more predictably: hue stays consistent throughout all values of saturation/lightness, and saturation reflects actual perceived hue intensity.
In my own experience of building and fine-tuning colour scales with OKHSL, the process begins by selecting a hue and saturation, then generating variations by moving along the lightness axis. This is where the OK Color Picker becomes especially useful. It lets you precisely adjust OKHSL values and quickly evaluate how those changes translate to perceptual differences.
For a quick start, you can also use Leonardo’s colour scale generator, which includes OLKab and OKLCH as colour space options. However, it’s important to note that Leonardo’s scales usually vary all parameters, not just lightness, which makes it less ideal for creating structured scales for design systems. My best guess is that this behaviour reflects the original purpose in data visualization, where the goal is often maximum contrast, not consistent structure. If you begin building your scales in Leonardo, you’ll likely need to fine-tune them manually.
Once the structure of a scale is set, I use names based on lightness values — like blue-25, blue-35, and so on. This kind of naming convention makes the system easy to read, extend, and maintain. If I need to add a value like blue-75, it fits naturally between existing colours without breaking the naming logic or scale structure. In contrast, many existing systems — like Spectrum from Adobe or Gestalt from Pinterest — use numeric values that don’t correspond to perceptual attributes. That can make the system harder to evolve or prove proof for future uses. You can see this approach in practice in this case study: Colour System Redesign: Vancouver Island Health Authority.
OKLab-based models solve many long-standing issues in colour scale design. They finally made it possible to generate consistent colour scales without needing a lot of resources or going through a ton of trial and error. Variations make sense, transitions feel smooth, and colours hold together across different use cases. Finally, the structured, lightness-based naming approach provides clarity and scalability.
However, OKLab doesn’t solve everything. There are multiple challenges in its use and implementation, and one of the most persistent is contrast accessibility compliance. Current standards like WCAG 2.x rely on luminance math based on sRGB, which doesn’t reflect human perception. As a result, colours that appear clearly distinct in OKLab may still fail automated contrast checks. Until more perceptually accurate models, such as the upcoming WCAG 3.0, are widely adopted, designers will need to navigate that disconnect manually.
Tooling remains another challenge. While support for OKLab is steadily improving, it’s still not natively integrated into most design platforms. Currently, only a handful of colour pickers are available, and most software doesn’t yet treat OKLab as a first-class citizen. Still, there’s reason to be optimistic: the model is open source, extremely well documented, and backed by an active community, which suggests that broader adoption will likely happen soon.
In the end, what OKLab offers is more than just another colour model. It marks a shift away from intuition-driven design toward something more perceptually grounded and structurally sound. For modern design systems, it opens the door to colour strategies that are not only easier to scale and maintain, but also more aligned with how we actually see.
Interactive Tools
OK Color Picker: OKHSL/OKHSV with visual sliders and real-time preview
OKLCH.com: OKLCH colour picker & converter as it compares to LCH
Articles & Documentation
Generating Colour Palettes for Design Systems by Matthew Strom
Official documentation on the Oklab model and on Okhsl, Okhsv colour spaces by Björn Ottosson
