Color Picking Workflow

Moving color from mockup to production is a workflow, not a one-off eyedropper click.

Step 1: Anchor on brand tokens

Start from the design system’s primary, neutral, and semantic scales—not random hex from a screenshot compression artifact.

If marketing handed you a PNG, confirm the color against the official brand PDF or Figma library before coding.

Step 2: Sample carefully

Browser eyedroppers read one pixel. JPEG banding, subpixel antialiasing, and retina scaling can lie.

Sample a flat fill region, or read values directly from the design file. When sampling a live site, disable zoom and check light/dark mode variants separately.

Step 3: Convert and record all views

Store canonical hex (or OKLCH) in tokens, then derive:

• RGB for canvas/chart APIs
• HSL for theme generators
• Contrast-safe text pairs documented beside backgrounds

A converter keeps the numbers consistent when designers ask for “the same blue in HSL.”

Step 4: Verify contrast and states

For each interactive component, check default, hover, focus, and disabled pairs. Focus rings often need a third color that still passes contrast on both default and hover fills.

Capture failing ratios in the review ticket—not only “looks fine on my laptop.”

Step 5: Ship as CSS variables

:root {
  --color-primary: #2563eb;
  --color-primary-hover: #1d4ed8;
  --color-on-primary: #ffffff;
}

Components reference semantic names (--color-on-primary), not raw hex sprinkled in modules.

Handoff checklist

Item	Done when
Token name agreed	Design + eng use same --color-*
Contrast documented	AA met for text pairs
Dark mode	Separate table or overrides listed
Non-CSS surfaces	Email/PDF hex exported

Key takeaway

Treat eyedropper tools as measurement instruments in a documented pipeline—sample, convert, verify contrast, publish tokens. That is how teams stop #2563EB from becoming five slightly different blues in production.