How to document interface colors for a handoff

A color handoff that says only “use the blue from the button” leaves room for guesswork. The button may have a different color when hovered, disabled, or focused, and a color sampled from a screen may not be the original design value.

Use the Color Picker to sample visible colors and get HEX, RGB, HSL, and other values. Then record what each color belongs to, which interface state it shows, and whether the value is sampled or confirmed from the design source.

Capture and record each interface color

1. Open the Color Picker in Chrome or Edge on a computer. It can pick a color from anywhere on the screen. Other browsers may offer a reduced version or none.
2. Open the page, app, or mockup you are documenting. Set it to the exact state you need, such as a button at rest, a selected tab, or an error message. Keep the same browser zoom and display arrangement for all samples.
3. Sample a plain area near the center of the element. Avoid text edges, shadows, borders, gradients, and areas covered by another element. These can show blended pixels rather than the underlying fill color.
4. Record the values shown by the tool, then add the component, state, property, and location. Repeat for each distinct color and each state that matters to the handoff.

For example, record a value as Primary button / hover / background fill / #1769AA / RGB 23, 105, 170 / HSL 207°, 76%, 38% / desktop. Treat that as a sampled screen value unless you have checked it against the design file or source code.

What the sampled color means

A flat area gives a consistent value

If the same flat area returns the same HEX value when sampled again, you have a useful record of the color that appears at that point on screen. HEX is convenient for sharing and often used in CSS. RGB describes the red, green, and blue channels, while HSL describes hue, saturation, and lightness. Include one or more formats that the person receiving the handoff can use.

Nearby samples return different values

The area may be a gradient, a shadow, a translucent overlay, or an edge blended with the background. The visible pixels can change across the element, even if its design uses one base color. Note that the color is variable, and sample or confirm the intended base value in the original design source.

The value does not match the design file

A screen sample describes the rendered appearance, not necessarily the stored design token. Browser color handling, display settings, transparency, and effects can all affect what you see. Use the design file or the interface's CSS as the source of truth when it is available, and label the screen sample as a visual reference rather than silently replacing the original value.

The same component looks different in another state

That may be expected. Hover, focus, pressed, selected, disabled, and error states can each use separate colors. Record each one separately instead of treating the difference as a mismatch. State how the person reviewing the handoff can reproduce it, for example, “hover with pointer” or “keyboard focus.”

Make the handoff easy to use

1. Name the component and property. Say “primary button background” or “input border,” not just “blue.” This helps someone find the right color when the interface has several similar shades.
2. Identify the state. Use plain labels such as default, hover, pressed, focus, disabled, selected, or error. If a state is triggered by a particular action, note that action too.
3. Include the location and context. Note the page or screen name, whether it is desktop or mobile, and any relevant theme such as light or dark. If the same component appears in several places, identify which instance you sampled.
4. Separate the color from its transparency. If the design uses opacity, write down the underlying color and opacity separately when you can confirm both. A blended screen pixel alone cannot reliably tell you the original color and transparency.
5. Label the source and confidence. Mark each value as confirmed from the design source, copied from code, or sampled from the rendered screen. If you are unsure whether an effect or overlay changes the result, say so rather than presenting the sample as exact source data.

A useful handoff entry can be a sentence or a list item. For example: Checkout page, primary button, hover background, #1769AA, sampled from desktop rendering, confirm against design token before implementation. Keep the same naming pattern for every entry so another person can compare them quickly.

Why a screen sample may not be the original color

Text and curved edges often contain pixels that mix the foreground color with the background. Sampling one of those pixels can produce a value that is not used anywhere in the design. Gradients and shadows also change from point to point, so a single HEX value cannot describe the whole effect.

Transparency creates another common mismatch. A semi-transparent color is composited over whatever is behind it. The resulting pixel depends on both colors, so sampling the finished screen does not reveal the original foreground color on its own. Similarly, a screenshot or display may look different from the value in a design file because the output has passed through browser and display color handling.

Use the Color Picker to document what is visibly rendered, then verify exact implementation values in the source design or code when precision matters. That distinction gives the recipient a helpful visual reference without confusing an observed pixel with a confirmed design token.