Handle Token Exceptions

Back to Devoured - October 12, 2026

DEVOURED

Handle Token Exceptions

Design frontenddevops Design Tokens Substack

Hardcoded design values should only exist as tracked 'exceptions' with a clear owner and expiration date to prevent long-term technical debt.

What: A system for managing design exceptions requires every hardcoded value to be logged in a register with a reason, scope, approver, and expiration date. Once the date passes, the exception must be converted into a formal design token or removed.

Takeaway: Create a `exceptions.json` file in your design system repo today to track any hardcoded values, ensuring each has an `expiresAt` field and an assigned owner to guarantee they are cleaned up.

Decoder

Design Token: A single source of truth for design decisions (like colors or spacing) that abstracts implementation details across platforms.

Original article

Hardcoded values become valid token exceptions only with a reason, a defined scope, an owner, and an end date. Without a date, they're permanent technical debt. Valid cases include time-boxed campaigns, tokens awaiting release, and urgent accessibility fixes. A register tracks each exception's location, value, reason, approver, and expiration date, and when the date arrives, it's promoted to a token or removed.

Explore all 71 articles in today's digest