# When should a product extend an existing component or create a new one?

By Sean Everett · October 7, 2026

Compare the purpose and behavior of the proposed interaction with the existing system. Make variants, exceptions and new components earn their maintenance cost through evidence.

Topics: Design systems · Product design · Component governance

## Inspect meaning and behavior before appearance

Start with the task the proposed component serves. Compare it with existing components by purpose, information required, available actions and expected states. Two controls can look similar while asking people to make different decisions; different styling can also conceal the same underlying interaction.

GOV.UK’s contribution criteria ask whether a proposal addresses a demonstrated need and duplicates an existing component or pattern. Apply that question to the product inventory. Find existing uses across teams before assuming a missing design-file symbol means the capability must be created from scratch.

Record the mismatch precisely. Does the current component lack a necessary state, a supported input or an interaction the task requires? Bring design and engineering owners together around that example. A specific failure gives the review something more useful to assess than visual preference.

## Compare reuse, a bounded variant and a new interaction

A different emphasis for the same action can be a reasonable variant. GOV.UK documents secondary button styling for secondary actions while warning against crowding pages with competing calls to action. A variant should preserve a recognizable interaction rather than become a container for unrelated behaviors.

For a hypothetical record editor, a quieter Save button retains the same basic action. A control that opens a searchable list of many records needs selection behavior and additional states. Calling both a button variant would hide the second interaction’s design and testing requirements.

Try composition before adding special cases to a shared component. An existing field, help message and action may work together without changing their contracts. Create a new component when the task requires a coherent behavior that the existing pieces cannot support clearly, and document that boundary.

## Make release and maintenance part of the decision

GOV.UK evaluates proposed contributions through user research, consistency and use across different contexts, browsers and assistive technologies. Use those as review dimensions, with evidence from the proposed product contexts. Adoption of an established component alone does not validate the complete screen.

Exercise the states that change behavior: empty input, loading, error, long content, unavailable actions and keyboard focus. Check the component at every entry point that will use it. Record any unsupported combination so teams do not discover a hidden limitation after rollout.

Assign ownership for guidance, implementation and future changes. Explain when to use the component, when to use something else and how existing consumers will migrate if behavior changes. Revisit local exceptions that recur across teams; repeated need can justify a shared extension after its behavior is understood.

## Related reading

- [GOV.UK Design System: Contribution criteria](https://design-system.service.gov.uk/community/contribution-criteria/)
- [GOV.UK Design System: Button uses and variants](https://design-system.service.gov.uk/components/button/)
- [Keeping features coherent across a product](https://evergences.com/insights/product-coherence-feature-overlap/)

Source: https://evergences.com/insights/design-system-extension-governance/