Skip navigation

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 print
    • L100 (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 37
  • L37blue → blue expressed at lightness 37
  • L55canaryYellow → canary yellow at lightness 55
  • L64violet80 → violet at lightness 64 with saturation variant

Uppercase L

An uppercase L is used intentionally:

  • It denotes a system constant
  • It is visually unambiguous (L1, l, or I)
  • 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.

    • L37blue describes 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:

    • L0
    • L40red
    • L100

    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:

    • L40red and L37red may 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:

    • L85skyBlue instead of “light navy”
    • L27navy instead of “dark blue”
    • L55pink instead of “light red”
    • L46olive instead 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
  • 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:

    • L27navy and L85azzurro can 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., L85azzurro alongside L85blue) without breaking existing usage or invalidating history.

    Overlapping or culturally broad terms may then be deprecated with simple, explicit guidance (e.g., “blue replaced by azzurro”), 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., red is not replaced with crimson or scarlet), 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.