Unify Button Styles Across Modules with Limited Options & CSS Variables

Requirements Goal

The goal is to let the primary buttons in the Requirements, Code, Pipeline, Environment, and Release modules reuse the same color, font size, border radius, and padding, avoiding multiple style sets for the same role.

Initial Implementation

Initially each module set its own button colors, font sizes, border radii, and padding. All five modules provided a "View Details" entry.

Figure 1: Five modules each setting button styles independently.

Problem Analysis

Key Issues

These buttons share the same role but vary in color, size, and shape without corresponding functional differences. Users may waste effort deciding whether the visual differences imply different meanings.

Engineering-wise, independent parameter settings mean every change requires manual synchronization across all occurrences. Merely making the five buttons look similar does not solve the duplicate maintenance problem.

Design Principles

Reducing meaningless candidate values lowers the cost of repeated fine-tuning. Deciding on a small set of suitable options first, then selecting from them, is easier than facing arbitrary color and size values each time.

Options should be built around actual use cases. Primary, secondary, and destructive actions may need different rules; the same role should reuse existing definitions. There is no need to create a full design system upfront — start with the most frequent decisions in the project.

Optimized Implementation

Parameter Consolidation

Inventory the five buttons' colors, font sizes, padding, and border radii to confirm they belong to the same role. Merge parameters for identical purposes; document any retained differences with their specific use cases.

In this example the primary buttons are converged into one group of shared variables. Variable names express the role, making it easy for similar components to reference them.

Style Implementation with CSS Custom Properties

.actions {
  --action-primary: #2d61bd;
  --action-font: 26px;
  --action-padding: 14px 24px;
  --action-radius: 6px;
}
.action-primary {
  background: var(--action-primary);
  font-size: var(--action-font);
  padding: var(--action-padding);
  border-radius: var(--action-radius);
}

The font size shown is for the illustration canvas. Real products should determine parameters based on actual display sizes; avoid prescribing canvas values as cross-platform standards.

Exception Handling

When adding new buttons, reuse existing roles first. Only when dense toolbars or long labels genuinely require variation should you record the applicable conditions and decide whether to add a separate tier.

Limited options are meant to aid decision-making. If existing options cannot meet readability or operational needs, adjust the rules rather than forcing a fit.

Effect Verification

Figure 2: Same-role buttons now reference unified color, size, and shape rules.

Visual inspection checks appearance consistency; verifying that shared variables actually take effect requires inspecting the style source and computed styles.

☐ All five buttons have consistent color, font size, padding, and border radius.

☐ Same role references shared parameters so modifications propagate automatically.

☐ Retained exceptions have clear purposes; long labels do not break layout.

Application & Practice

Pick three pages, collect the actual styles of their primary buttons. Merge similar values by purpose, then record the retained roles, parameters, and exception conditions in a checklist.

The practice outcome should guide future button additions, not just produce a set of visually similar color swatches.