Managing Design Values in Front‑End Code

Front‑end code is full of design values.

Colours, spacing, font sizes, border radii, z‑index layers, shadows, breakpoints, animation speeds, and component measurements all end up in the code somewhere. If they are scattered through stylesheets as one‑off values, the design becomes hard to change and harder to trust.

The problem is not that a project has many values. The problem is when nobody knows which values are deliberate.

Start by Naming the Decisions

A design value should usually represent a decision, not merely a number.

For example, #005fcc is a colour. brand‑primary is a decision. 24px is a measurement. space‑large or spacing‑6 is a spacing rule the project can reuse.

The naming does not need to be grand. It needs to be consistent enough that developers can tell whether they should reuse an existing value or introduce a new one.

Good candidates include:

• brand colours
• neutral colours
• typography sizes
• spacing steps
• breakpoints
• focus styles
• transition timings
• z‑index layers

Keep Values Close to the Layer That Owns Them

Not every value belongs in a global settings file.

Global values should be broadly reusable. Component‑specific values can live with the component. If a button has a particular internal padding because of its design, that may belong in the button partial. If the same spacing step is used throughout the site, it belongs in shared settings.

The article on organising Sass with partials and mixins is relevant here. Sass makes shared values easy to create, but a project still needs judgement about what should be shared.

Avoid Magic Numbers in Component CSS

Magic numbers are values that appear without context.

They are sometimes necessary, especially when aligning a specific piece of design, but they should not become the normal way the system works.

Ask:

• Is this value part of the spacing scale?
• Does it match an existing typography size?
• Is it compensating for another style?
• Will changing it affect other components?
• Should it be named?

If a component contains several unexplained values, it may be carrying a design rule that belongs somewhere more visible.

Be Careful with Abstraction

There is a limit to how abstract values should become.

A scale is useful. A complicated chain of aliases can be confusing:

• colour‑primary
• colour‑action
• colour‑link
• colour‑cta
• colour‑button‑primary‑background

That might be appropriate in a large system, but it can be too much for a smaller site. If developers cannot predict which value to use, the abstraction has stopped helping.

Start with the values the project actually repeats. Add more structure when the repetition becomes real.

Keep Design Values and Component Behaviour Aligned

Some design values affect behaviour, not only appearance.

Examples include:

• breakpoints that change navigation behaviour
• z‑index values that affect overlays
• spacing values that influence tap target size
• animation timings that affect perceived responsiveness
• focus styles that affect keyboard usability

These values need more care than decorative choices. A change to a breakpoint can change how JavaScript should behave. A change to z‑index can break a modal. A change to focus styling can make the site harder to use.

Document Unusual Decisions in the Code

Most values should be self‑explanatory through naming and structure. Some are not.

If a value exists because of a browser bug, third‑party embed, legacy template, or precise alignment requirement, leave a short comment. Future developers should know whether the value is safe to change.

Do not comment every value. Comment the ones that would otherwise look arbitrary.

Those shared values become easier to judge when components are visible outside a single page. Using Storybook to document front‑end components gives the values somewhere to be seen, reviewed, and corrected.

Wrapping Up

Managing design values is really about making design decisions visible in code.

Name the values that repeat. Keep global values global and component values local. Avoid unexplained numbers where a shared value exists. Use abstraction carefully, and document the odd cases. The result is not just cleaner CSS. It is front‑end code that can change without rediscovering the design system every time.

Key Takeaways

• Design values should represent reusable decisions, not random measurements.
• Global values should be genuinely shared across the project.
• Component‑specific values can stay with the component.
• Avoid magic numbers unless the reason is clear.
• Breakpoints, z‑index values, focus styles, and timings can affect behaviour as well as appearance.