Design Tokens and Style System

Token purpose

Tokens make repeated design decisions easier to review. Use them for colors, typography, spacing, radius, borders, shadows, button states, product badges, notices, and checkout helpers so future Theme Assistant work does not invent new styles for every prompt.

Source of truth

Start from the active theme and real WooCommerce pages before asking for new token recommendations. The Store Design Kit tutorial shows how to collect existing storefront patterns, while WooCommerce Store Design Kits explains commerce-specific safeguards.

Change discipline

Token changes should include affected components, intended usage, contrast notes, responsive caveats, and rollback behavior. Do not let a token refresh silently restyle checkout, account, cart, or product visibility cues without approval.

Owner and cadence

• Primary owner: designer or developer, with site-owner approval for production visual impact.
• Review cadence: before publishing, after theme updates, and after cache or WooCommerce template changes.
• Escalate when token changes would restyle revenue-critical components, brand-critical surfaces, or accessibility-sensitive states without review.

Production checklist

• Collect current colors, typography, spacing, radius, component states, product badges, notices, and checkout helper patterns before proposing token changes.
• Review contrast and WooCommerce state visibility before approving token-level CSS.
• Capture the affected URL, target selector, intended visual outcome, reviewer, and rollback note for every meaningful visual change.
• Review mobile, desktop, keyboard focus, reduced motion, contrast, checkout, cart, account, and navigation behavior before publishing.

Acceptance checks

• Token changes have named affected components and do not silently restyle revenue-critical flows.
• Design decisions are reusable across future Theme Assistant prompts and client presentations.
• The proposed CSS or presentation output can be traced to a specific page, component, and design goal.
• The reviewer can reject, revise, or roll back the change without guessing which selectors were affected.

Common mistakes

• Refreshing tokens globally without checking checkout states, product badges, notices, account pages, and contrast-sensitive components.
• Publishing broad CSS from a single preview without checking logged-out, mobile, checkout, account, and cache states.
• Using external design references as production assets instead of review context.

Related operations

• Build token context with the Store Design Kit tutorial.
• Review WooCommerce Store Design Kits.
• Use Responsive and Accessibility Review before visual publishing.
• Use Client Presentation Workflow when an agency needs client approval.
• Use Publishing and Rollback for Theme Changes before approving production CSS.
• Use Multi-Page Consistency Checker before broad component updates.
• Use Design Tokens and Style System before token-level changes.