One brand color is a useful starting point, but it is not a complete interface palette. A button, page background, body text, border, and focus ring have different jobs and may need different color relationships. This guide shows how to build a small design token palette from a single color while keeping the final values tied to real interface roles.
Start with the brand color's job
Before generating shades, confirm what the supplied color represents. It may be the primary action color, a logo color, a highlight used in marketing, or a legacy value that cannot be changed. Those uses affect how much flexibility you have.
Record the color in a standard format such as HEX or RGB and check that it is the approved source value. If there is a brand guide, use that rather than sampling a compressed logo screenshot. A screenshot can shift values through scaling, color profiles, and compression. If the exact brand color is unknown, ask for the source token or design file rather than quietly treating an estimate as authoritative.
Also note the intended interface: a light theme, dark theme, both, or a single component. A vivid brand color may work as a button background on a dark surface and fail as small text on a light surface. There is no reason to force one value into every role.
Generate a scale, then curate it
A color generator can help explore tints and shades around the starting value. The Toolsnix Color Palette Generator is one way to explore related colors. Treat generated values as candidates and select only the shades your components need.
A scale such as 50, 100, 200 through 900 can be useful when a product needs a set of progressively lighter and darker variations, but those labels do not carry universal meanings. A 500 value in one palette is not automatically equivalent to another project's 500. If you need only one action color, a dozen steps may create unnecessary decisions. Start small and add steps when a real component calls for them.
Review the generated scale for these issues:
- Too many near-identical shades: They are hard to distinguish and rarely have different purposes.
- A dramatic hue shift: Some lightness operations change the apparent hue or saturation. Check whether the result still feels on brand.
- A muddy middle: A mathematical scale can include values that look dull beside the source color.
- Insufficient contrast: A darkened version may still fail as small text on a light background, while a pale tint may disappear on white.
- No useful neutral colors: A single brand hue cannot supply every surface, border, and text value a real UI needs.
Keep the source brand value unchanged and store derived candidates separately. That makes it possible to compare your refinements against the original and prevents a generated shade from accidentally replacing the approved brand token.
Separate raw values from semantic tokens
A raw color token describes a value; a semantic token describes a purpose. For example, amber-600 can identify a swatch in a scale, while action-primary-background says where the value is intended to be used. Semantic names are easier to maintain when a light-theme action and a dark-theme action need different values.
A compact structure could look like this:
:root {
--brand-primary: #4f46e5;
--brand-primary-hover: #4338ca;
--surface-page: #ffffff;
--surface-raised: #f4f5f8;
--text-primary: #20212a;
--text-muted: #565866;
--border-subtle: #d7d9e2;
--focus-ring: #3730a3;
--status-error: #b42318;
}
These values are illustrative; they are not a ready-made accessible palette. The point is the naming distinction. A component can use --action-primary-background instead of a specific shade name. If the design changes, the role can remain while the underlying raw color changes.
Avoid names based on a component if the token is shared widely. button-blue may become confusing when the same color is also used for links and selected tabs. Conversely, do not create a universal primary token if it has several conflicting meanings. Choose names that communicate how the color should be used and what should happen when the theme changes.
Assign a role to each color
Start from the components in the interface rather than filling a spreadsheet with colors. A small product might need:
- Page and raised surfaces
- Primary and muted text
- Primary action background and its label
- Links and selected states
- Borders and dividers
- Focus indicators
- Error, warning, and success states
Some roles can share a value at first, but document the relationship. If link and action-primary use the same brand color, decide whether they should remain linked across themes. Avoid sharing a value just because the colors look similar in one screenshot.
A token should also state its expected context. A text-muted token must still be readable. A border-subtle token can have lower contrast than body text but must remain visible when it communicates a control boundary or state. A focus-ring should stand out against adjacent surfaces and should not disappear into the component's border.
Do not use one accent hue as the only indicator for every state. A red error, green success, and amber warning still need labels or icons. Color semantics vary among products and cultures, and some users cannot distinguish particular combinations. Preserve meaning through text, iconography, shape, or pattern.
Test the pairs that appear in real components
Contrast is a relationship between foreground and background. A color does not have an accessibility score in isolation. Test the exact pair used for body text, small labels, buttons, links, placeholders, and focus indicators. The Contrast Checker can help evaluate a pair, but check every important use in the actual component and follow the applicable standard.
Pay special attention to text on the brand color. If the primary action uses a blue or purple background, do not assume white text automatically works. Check the foreground against the chosen shade. If it fails, choose a different shade, change the text color, or use the brand color in a different role.
A contrast tool is not a complete accessibility audit. It cannot decide whether the interface communicates state clearly, whether focus is visible in every context, or whether a color-only distinction is understandable. Review keyboard focus and states as well as static samples.
Example: using a violet brand color
Suppose a team has one approved violet and is building a light dashboard. It can use the violet as a candidate for the primary action, but first it should test the label color on top of that button. The team may need a darker violet for text links, a pale violet for selected-row backgrounds, and neutral gray values for page and card surfaces.
The selected-row tint should not be used for normal text unless the contrast supports it. The focus ring may need a darker or more saturated value so that it remains distinct around both white and pale surfaces. Error and success colors should retain their familiar functional roles instead of being derived from violet. Each choice responds to a component need; none follows automatically from the original brand color.
Plan light and dark themes by role
A dark theme is not simply a light palette with colors inverted. The page surface, raised surfaces, text hierarchy, borders, and action colors need to be reassessed. Some brand shades that work on a light surface may glow too strongly on dark backgrounds; a lighter version may be needed for the action while the original remains appropriate for a logo.
Use semantic tokens as the stable interface and map values by theme:
:root {
--surface-page: #ffffff;
--surface-raised: #f4f5f8;
--text-primary: #20212a;
--action-primary-background: #4338ca;
--action-primary-label: #ffffff;
}
[data-theme="dark"] {
--surface-page: #15161b;
--surface-raised: #202129;
--text-primary: #f1f1f5;
--action-primary-background: #a5a0ff;
--action-primary-label: #171528;
}
Again, these are structural examples, not validated values. Test each foreground/background pair after mapping. Verify hover, active, disabled, and focus states in both themes. If a token is not used in a theme, do not add a placeholder solely for symmetry.
Document and maintain the palette
A token set is useful only if the team can understand it and apply it consistently. Keep a short record of the token name, purpose, source or derivation, and theme values. A design file can display swatches and sample components, while code can hold the actual variables. Make one source authoritative so the design and implementation do not drift.
When changing a token, search for every use and review affected components. A shared color may appear in a button, link, chart, and focus state. A change that improves one of them might make another less clear. If a token needs incompatible values for different roles, split it into two semantic tokens rather than adding local overrides indefinitely.
Common mistakes
- Using the brand color for every accent: Repetition can erase hierarchy. Reserve it for meaningful emphasis and build neutrals separately.
- Publishing a shade scale without use cases: Unused values add maintenance cost and encourage inconsistent improvisation.
- Naming tokens after temporary visuals: A semantic role survives a redesign better than
purple-button. - Checking colors only in isolation: Test foreground and background pairs in real text and controls.
- Treating a contrast pass as full accessibility: Labels, keyboard states, non-color signals, and layout still matter.
- Replacing approved brand values with sampled values: Use source files or brand documentation for exact values.
- Assuming the same tokens will work in both themes: Validate each mapping, including interactive states.
Frequently asked questions
How many colors should a small design token palette have?
Use as few as the interface needs. Start with brand, surfaces, text, border, action, focus, and necessary state roles. Add variations when a real component requires them, not simply to complete a numerical scale.
Can one brand color create an entire design system?
No. It can guide the accent direction, but a system also needs neutrals, readable text, state colors, spacing, typography, component behavior, and tested combinations.
Should tokens use HEX values or color names?
The implementation can store values in HEX, RGB, HSL, or another supported format. Token names should describe their purpose, such as text-primary or surface-page, rather than relying on a color adjective alone.
Should I create light and dark shades automatically?
Automatic generation can provide a starting scale, but review each value and role. Light and dark themes have different backgrounds and contrast needs, so test their actual mappings.
How do I know whether a token is too specific?
If it describes one component but is used by unrelated components, or if every redesign forces renaming it, consider whether a semantic role would be clearer. If two components need different behavior, separate the tokens.
Next step
Take the approved brand color and identify the real interface roles that need color. Generate only a few candidate shades, assign semantic names, then test the foreground and background pairs in representative components and themes. Keep the final palette small enough that every token has a reason to exist.