Creating Colour Ramps 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’ve used to manage colour haven’t kept up with this complexity.
A colour ramp is a smooth, perceptually coherent progression of tints, shades, or tones from a base hue. When multiple ramps are brought together to serve a product or brand, they form a colour palette—one of the most important tools in any design system. But building colour palettes that scale, adapt, and stay visually consistent across platforms remains a major challenge.
Only recently have newer colour models, like OKLab, begun to offer a more reliable foundation. OKLab is a perceptually uniform colour model, meaning that changes in its values align more closely with how we actually see colour. This makes it especially powerful for generating smooth, consistent colour ramps that feel natural to the eye, and for assembling those ramps into palettes that behave predictably and scale well.
While there are other perceptually uniform models, OKLab stands out for being both highly intuitive and relatively easy to work with. It strikes a rare balance between mathematical precision and practical usability, which makes it particularly well-suited to the demands of digital design systems.
This article focuses on the OKLab model as a way of exploring how colour tools have evolved—from the fixed constraints of early print workflows to the unpredictable behaviours of digital colour systems—and why many of the models we still use fall short when it comes to building flexible, perceptually consistent colour ramps at scale.
When colour was static: print, CMYK, and spot systems
For much of the early 20th century, visual design was predominantly black and white. Colour printing was expensive, technically inconsistent, and used sparingly. If colour was included at all, it was typically applied manually or printed using multi-pass lithographic techniques—processes that were labour-intensive and far from flexible.
There were no structured colour palettes or ramp logic to speak of. If a designer wanted red or blue, they would select a swatch from a supplier, cross their fingers, and hope it would print close to their expectations. Systematic colour variations were practically nonexistent, and the idea of building a scalable colour palette wasn’t yet part of the workflow.
There were no structured colour palettes or ramp logic to speak of. If a commercial artist (what designers were called back then) wanted red or blue, they would select a swatch from a supplier, cross their fingers, and hope it would print close to their expectations. Systematic colour variations were practically nonexistent, and the idea of building a scalable colour palette wasn’t yet part of the workflow.
In 1906, 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 prepared, tested, and treated as a unique, standalone colour.
This is also how Pantone has historically approached colour. Rather than mathematically calculating ramps, Pantone defines each colour and its tints, shades, and tones as a distinct, numbered swatch. There’s no assumption of a relationship between them; each one is an isolated value with no logical connection to a base. This made colour specification straightforward for printers but meant that designers couldn’t easily generate ramps or expand palettes without ordering and referencing entirely new swatches.
Some designers attempted to address this limitation by simulating tints and shades through layering colours over white or black backgrounds—essentially adjusting opacity. This method implied a relationship between variations and the base hue, allowing for more fluid ramp creation without introducing each variation as a completely new colour. However, while visually useful in digital mockups, this approach didn’t translate reliably to print production, where transparency wasn’t a controllable property. It introduced unpredictability, and in many cases, tints produced using opacity looked like entirely different colours. Instead of preserving the integrity of the base hue, the result often diverged visually in ways that made consistent reproduction difficult.
Perhaps most critically, because every variation had to be treated as its own colour, there was no consistent naming convention to support palette logic. Any attempt to build colour ramps had to be constructed manually, and adding new colours to a palette could easily break its internal structure.
In other words, both process colour models (CMYK) and spot colours (Pantone) made it possible to reproduce colours consistently in print, but they weren’t built for scalability. As design moved into the digital era, where flexibility, accessibility, and dynamic theming became essential, the limitations of those older models became increasingly obvious.
Digital design and the rise of HSV/HSL
The shift to digital design introduced a way of working with colour based on light rather than pigment. RGB quickly became the foundation for screen-based work, offering flexibility but little intuitive control for designers. To make colour selection and manipulation more accessible, graphic software introduced alternative colour systems built on top of RGB: HSV (Hue, Saturation, Value) and HSL (Hue, Saturation, Lightness).
These colour systems allowed designers to adjust hue, saturation, and brightness using sliders, making it easier to explore variations, generate ramps, and escape the limitations of print-specific values. But while HSV and HSL improved usability, they came with their own problems. Neither system is based on a perceptually uniform model, which means that numerical changes often don’t match how we perceive colour differences. Shifting the “lightness” value in HSL, for instance, can unexpectedly alter the hue. In HSV, equal steps in Value don’t result in equal steps in perceived brightness. Saturation also behaves inconsistently across different hues, which makes ramps feel uneven and unpredictable. Colours that looked fine in isolation often fell apart when placed in ramps—transitions felt jagged, variations lacked harmony, and contrast was unreliable.
To deal with these problems, some people started looking at more perceptually grounded colour models developed by the CIE—the International Commission on Illumination. In the 1970s and 80s, two of those models, CIELAB and CIELUV, gained attention from designers and developers who wanted more control over how colour actually looks, not just how it’s encoded. In theory, these models made it possible to build better, more consistent colour ramps without the distortions common in HSL and HSV. But in practice, they were hard to use.
Despite their perceptual advantages, Lab and LUV were not easy to work with. The mathematics behind them was extremely complex, and few design tools supported them natively. Manipulating values in these spaces felt foreign. Moreover, converting between RGB and Lab or LUV introduced rounding errors, which made a reliable implementation even more difficult.
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 merely a decorative tool or a means of expressing brand voice. Colours and their variations now had to support dynamic themes, meet accessibility standards, and scale across entire frameworks. They needed to be flexible enough to cover all functional states, adapt to accessibility modes, and, on top of that, perform the usual task of expressing brand identity across a wide range of visual contexts. At the same time, they had to remain organized in a way that made them easy to understand and apply consistently across platforms
The complexity of perceptually uniform solutions such as those from CIE allowed the big companies to utilize their modelling in their design systems (like Adobe uses CAM02 from CIE to create colour ramps for their design system Spectrum) most teams still relied heavily on HSV or HSL, generating base values programmatically and then adjusting everything by hand. Designing usable colour ramps meant exporting dozens of colour stops, tweaking each one visually, and iterating through rounds of testing until the results looked and felt right. Even the most advanced systems often ended up with custom palettes that were shaped more by intuition than logic, refined through labour-intensive trial and error.
But even once you arrived at a perceptually consistent palette, you faced another challenge: naming conventions. After so much manual correction, the original numerical values no longer made sense. Designers had to create custom naming schemes or indexing systems to reflect visual relationships rather than underlying logic. It was a workable solution, but not a sustainable one. The real friction came when these palettes had to evolve or expand. In that case, the designers were left with two poor options: either to break the existing naming convention to introduce new colours, or remove and replace colours to preserve the structure. Neither approach scaled well. Colour systems became fragile and increasingly difficult to maintain. Even with strong design ops support and rigorous documentation, colour management remained one of the most manual and time-consuming parts of building a design system.
Perceptual uniformity meets practicality: okLAB
The shortcomings of HSV and HSL, along with the complexity of earlier perceptual models like CIELAB and CIELUV, made it clear that we needed a colour model that made sense both to the eye and to the machine. In 2020, Swedish engineer and visual computing researcher Björn Ottosson developed such a model: OKLab. Drawing on the strengths of CIELAB but simplifying it for modern use, he introduced a perceptually uniform model that was far easier to work with. (Fun fact—“OK” doesn’t seem to stand for anything.)
The OKLab model ensures that equal steps in its coordinate space result in approximately equal steps in perceived colour difference. This makes it ideal for generating smooth, natural-looking colour ramps by simply adjusting values numerically. For designers, this removed much of the guesswork and brute-force iteration that HSL and HSV workflows demand. Compared to the dense math of CIELAB, OKLab is easier to compute, easier to implement, and well-documented. It’s also open-source, which has helped it spread quickly among designers and developers alike.
Knowing that designers were already familiar with RGB-based controls like hue, saturation, and lightness, Ottosson also introduced okHSL and okHSV—colour systems that mimic the structure of traditional HSL and HSV, but with perceptual logic derived from the OKLab model. These systems behave far more predictably. Hue stays consistent as it rotates. Saturation reflects actual perceived intensity across hues. Lightness and value sliders adjust brightness without shifting the hue unexpectedly. And for cases where designers need even finer control, OKLab also supports a cylindrical version called OKLCH, which lets you control lightness, chroma, and hue more precisely.
Together, these tools solve many of the long-standing frustrations with building and maintaining colour palettes. With OKLab and its related colour systems, you can generate consistent ramps from a base hue without relying on trial and error or constant visual tweaking. Because changes in the model correspond to how we actually perceive colour, ramps feel even, transitions look smooth, and colours hold together across a wide range of applications. This makes it far easier to build coherent, scalable palettes.
There are other benefits too. Equal value steps in OKLab produce equal visual differences, avoiding the distortions and perceptual gaps that happen in HSL or HSV. You can create colour naming schemes that stay logically consistent—like blue-60, blue-70, blue-80—and still reflect the underlying relationships between variations. When a palette needs to grow, you can insert new colours without having to rename or reorganize the whole structure. This makes colour palettes easier to maintain as a component of the design system, rather than something constantly patched or reworked.
That said, the OKLab model isn’t without limitations. The biggest issue is contrast. Current accessibility standards, like WCAG 2.x, use outdated math based on sRGB and luminance values that don’t match human perception very well. So even if two colours are distinct in OKLab, they might fail a contrast check. This creates a technical gap between what looks right and what passes compliance. Until WCAG 3.0 and its new APCA standard become widely adopted, that’s a limitation teams will need to work around.
There’s also tooling fragmentation. While support for OKLab is growing fast, many mainstream design tools still don’t support it natively. Using OKLab often requires plugins, custom scripts, or design tokens built outside the default software environment. But thanks to its open-source nature and strong community support, these gaps are actively being addressed.
In short, the OKLab model doesn’t make colour perfect, but it does represent a major leap forward. It moves colour from something approximate and manually managed to something perceptually grounded, scalable, and ready for the realities of present-day design.
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
