You have built a beautiful, accessible palette in PaletteRx. You have exported it to your builder. The project launches. Six months later, a new developer joins and starts introducing random hex codes because nobody told them the palette existed. Sound familiar?
The Minimum Documentation
At minimum, document these for each color: the hex value, the role name, the CSS variable name, one sentence describing when to use it, and one sentence describing when not to use it. This turns a swatch into a decision-making tool.
Usage Examples
Show each color in context: "Primary Blue is used for CTA buttons, active navigation states, and link text. It is NOT used for large background fills, decorative borders, or body text." Include screenshots or component examples where possible.
Accessible Pairings
Document which color pairs pass WCAG AA and AAA. PaletteRx Step 3 gives you this information. Translate it into documentation: "Primary Blue passes AA against Light Base (6.1:1) and Dark Base (8.2:1). It does NOT pass against Supporting Teal (2.3:1)."
Where to Publish
The best documentation lives where developers already look: in the codebase (as comments in the CSS variable file), in a Notion/Confluence page linked from the project README, or in a dedicated style guide page on the site itself.
PaletteRx's Generic JSON as Documentation
PaletteRx's Generic JSON export includes hex, HSL, RGB, role assignments, and names for every color. This structured data can serve as the source of truth for your documentation. Import it into your documentation system and it stays synchronized with your actual palette.