L-Scale: A Lightness-First Colour System
Overview
This design system uses a lightness-first color model in which colors are addressed by perceptual lightness (L) before hue or saturation. Rather than organizing color as ramps or palettes tied to a specific medium, brand, or language, the system treats color as a coordinate space grounded in human perception.
The result is a system that is:
- structurally stable
- medium-agnostic
- culturally inclusive
- operationally resilient
- expandable without breaking history
Core Principles
Lightness is the primary invariant
Lightness governs:
- visual hierarchy
- contrast and legibility
- accessibility outcomes
- grayscale survivability
- print fidelity
Therefore:
- Lightness defines structure
- Hue expresses identity within a lightness register
- Saturation is a tertiary modifier
Hue and saturation may vary; lightness must not lie.
The lightness scale is discovered, not declared
The L-scale was derived empirically through multiple experiments, each based on different assumptions:
- Linear vs perceptual spacing
- Screen-first vs print-first anchors
- Mid-tone bias vs endpoint bias
- Contrast maximization vs tonal smoothness
Each experiment produced a valid ramp with different strengths and weaknesses. Steps were retained only where meaningful perceptual distinctions existed.
The final system contains 13 lightness registers from L0 to L100 (inclusive).
Adding additional steps would reduce perceptual discrimination rather than increase usable resolution.
Not all hues are valid at all lightness levels
Hue identity has a limited lightness domain.
For example:
- Yellow ceases to read as yellow below a certain lightness
- Brown is not “dark yellow” and must be treated as a distinct hue family
- Light brown (e.g. sand) is not a lightened brown, but a separate perceptual category
The system clips hues where their identity fails rather than inventing implausible variants.
Missing values are intentional.
Completeness does not imply obligation
The reference scale includes:
L0(pure black) — required for printL100(pure white) — required for substrate definition
Usage is context-dependent:
- Web may clip at
L13 - Print may rely on full black/white
- Grayscale ramps may omit white (background role)
The scale is complete; contexts choose where to operate within it.
Naming System
Lightness-first addressing
Colors are named using the following structure:
L{number}{HueName}{Saturation?}
Examples:
L37→ neutral gray at lightness 37L37blue→ blue expressed at lightness 37L55canaryYellow→ canary yellow at lightness 55L64violet80→ violet at lightness 64 with saturation variant
Uppercase L
An uppercase L is used intentionally:
- It denotes a system constant
- It is visually unambiguous (
L≠1,l, orI) - It remains legible across typefaces, print, tables, and code
Suffixes (e.g. _hex, _rgb) may reference representations, not identity.
Benefits of the L-Address Naming Model
Structure before style
Unlike palette-based naming (
blue-500,primary-light), L-addresses encode structure, not intent.L37bluedescribes where the color lives perceptually- It does not imply hierarchy, importance, or branding role
- Usage is defined elsewhere, not embedded in the name
This prevents semantic drift over time.
Expansion without invalidation
The system supports address stability under growth.
A minimal system might contain:
L0L40redL100
This is a complete, valid system for a print-only context.
When expanding to web:
- New L-registers may be added
- Neutral grays may be introduced
- Additional hues may appear
- Existing addresses (
L40red) remain valid and truthful
Expansion adds coordinates; it does not rewrite history.
Safe coexistence during migration
During system evolution:
L40redandL37redmay coexist- Both are valid, distinct addresses
- Visual clashes are acceptable short-term migration risks
No collisions occur because identity is explicit.
Migration becomes iterative and intentional rather than destructive.
Cheap calibration when identity is preserved
If two colors share the same lightness and identity:
- The hex value may be globally redefined
- One commit updates all usages
- No semantic migration is required
- This is a calibration change, not a conceptual one
Honest naming prevents semantic ambiguity (and cultural drift)
Ramp-driven color systems inevitably produce names that are structurally valid but perceptually ambiguous. These names arise when a hue is pushed beyond the lightness range in which its identity remains stable, forcing meaning to be carried by adjectives rather than perception.
Common real-world examples include:
- “light red”
Is this:
- pink?
- coral?
- rose?
- a desaturated scarlet?
Different cultures and domains answer this differently. The name does not encode a perceptual truth.
- “dark yellow”
Often resolves to:
- ochre
- olive
- mustard
- brown-adjacent tones
At low lightness, yellow ceases to read as yellow at all. The adjective attempts to preserve a category that perception has already abandoned.
- “light purple”
Commonly interpreted as:
- lavender
- lilac
- violet
- periwinkle
These are distinct perceptual categories in many languages, collapsed into one English modifier.
- “dark blue”
In English, this may mean:
- navy
- indigo
- midnight blue
In other languages (e.g. Italian), these are not variants of the same color category.
- “muted green” / “soft green”
These terms conflate:
- saturation change
- lightness change
- sometimes even hue shift
The modifier carries too much responsibility.
These names are not wrong linguistically — they are underspecified structurally.
Why these ambiguities occur
Ramp-based systems assume:
- Every hue can be meaningfully lightened and darkened indefinitely
- Identity survives continuous interpolation
- Adjectives can preserve meaning across perceptual boundaries
In practice:
- Hue identity has lightness limits
- Past those limits, new perceptual categories emerge
- Language becomes strained trying to maintain continuity
This results in names that are:
- context-dependent
- culturally biased
- difficult to localize
- unstable over time
How the L-address model avoids this entirely
The lightness-first system removes ambiguity structurally:
- Lightness is explicit (
L37,L85) - Hue names are categorical, not adjectival
- If a color no longer reads as its name, it receives a new name, not a modifier
Examples:
L85skyBlueinstead of “light navy”L27navyinstead of “dark blue”L55pinkinstead of “light red”L46oliveinstead of “dark yellow”
The system prefers new nouns over stretched adjectives.
This aligns naturally with:
- cross-cultural color vocabularies
- translation and localization
- accessibility and pedagogy
- long-term system stability
- “light red”
Cultural implication (the blue problem revisited)
English collapses many perceptual categories into “blue.” Other languages do not.
For example, Italian distinguishes:
- blu → dark blue / navy
- azzurro → light / sky blue
Ramp-based naming forces non-English speakers to reinterpret their own perceptual categories to fit an English gradient model.
The L-address model avoids this:
L27navyandL85azzurrocan coexist- Both are perceptually honest
- Neither is forced to be “a variant” of the other
The coordinate remains invariant; naming becomes a culturally contextual layer.
Naming as an inclusion mechanism
By decoupling structure from language:
- Multiple naming vocabularies can coexist
- Localization becomes aliasing, not redesign
- Cultural color models are respected
- No rendering indirection or manual mapping is required
This is especially important in software, which is already heavily biased toward North American and English assumptions.
The system does not require everyone to think about color the same way.
Localization, migration, and structural refinement
Localization and cultural refinement are handled through aliasing, deprecation, and mechanical remapping, rather than renaming or reinterpretation. Because color identity is addressed by lightness-first coordinates, culturally specific naming can be introduced as aliases (e.g.,
L85azzurroalongsideL85blue) without breaking existing usage or invalidating history.Overlapping or culturally broad terms may then be deprecated with simple, explicit guidance (e.g., “
bluereplaced byazzurro”), while automated tooling flags deprecated tokens during pull requests. Since lightness coordinates are explicit, overlap and replacement paths are mechanically obvious and do not require subjective judgment or design arbitration.This same mechanism supports large-scale system migrations. Deprecated lightness registers (e.g.,
L40) may be remapped to their nearest canonical neighbors (e.g.,L46) across all hues simultaneously (L40 → L46,L40red → L46red), preserving perceptual intent without forcing engineers to reinterpret color identity. Hue categories are never substituted (e.g.,redis not replaced withcrimsonorscarlet), even when numeric similarity exists.Because remapping operates at the level of L-bands rather than individual colors, migrations are predictable, automatable, and auditable. Visual discrepancies become localized signals rather than systemic failures, enabling gradual convergence without blocker meetings, manual audits, or large-scale refactors.
Colour Space
L-Scale v2 is built on OKLCH, a perceptually uniform color space designed to reflect how humans experience color differences.
Lightness (L) is treated as the primary ordering axis.
Colors are placed at valid perceptual coordinates rather than generated by adjusting numeric parameters.
Summary Principles
Define the perceptual space completely; use it selectively. Lightness defines structure. Hue expresses identity. Saturation modulates character.
Names must never lie about perception.
If a color requires an adjective to remain believable, it likely represents a different perceptual category and should receive a distinct name.
This system is not a palette.
It is infrastructure for color reasoning.