MCM-53 — Shared UI Component Library

← Back to MCM Design System overview

As a Frontend Engineer,
I want a shared library of common UI components that every surface installs as a dependency,
so that I don't have to re-implement or copy a component from one surface into another, and a fix or improvement to a component benefits every surface at once.

Assumption: the product console and customer portal already build on a similar underlying component approach, so they're treated here as the first adopters, converging their existing components onto the shared library. The marketing site is structured differently and may only be able to take the shared tokens plus a smaller subset of primitives without a deeper rebuild — how much of the library it ultimately adopts is not yet confirmed.

Acceptance Criteria

• A shared component library exists as an installable package, covering at minimum the primitives already duplicated across surfaces today: buttons, cards, tabs, form fields, and tables.
• The product console and customer portal, which already share a similar component approach, are the first surfaces expected to adopt the shared library in full, since converging them requires the least behavioural change.
• The marketing site can consume the shared tokens and whichever primitives fit its existing structure, without being required to adopt the full component set in this iteration.
• Components in the shared library support both light and dark appearance and expose the same customization points (size, variant, disabled/loading state) consistently across component types.
• Every component in the shared library is versioned; a surface adopts a new version deliberately rather than receiving changes automatically on every build.
• Where a surface's existing local component and the shared library's equivalent behave differently, adopting the shared library is called out and reviewed as a behaviour change before merge, not swapped silently.

---

Technical Design

This builds the shared component package on top of the token source from MCM-52, reusing the same underlying primitives the product console and customer portal have already independently converged on — this story formalises and shares that convergence rather than inventing a new approach. The marketing site, whose components are structured differently today, adopts the shared token layer and only the subset of primitives it can use without a deeper rebuild; see the assumption above on how far that goes.

---

UI / Frontend Changes

• Buttons, cards, tabs, tables, and form fields in the product console and customer portal are swapped for the shared library's versions over time (the full swap across already-built screens is follow-on adoption work, tracked outside this module — establishing the library itself is what's in scope here).
• The marketing site adopts the shared tokens and whichever primitives fit its existing structure.
• No new end-user-facing screen; visual appearance is unchanged, or converges where surfaces had already disagreed.

Out of Scope

• Rewriting the marketing site's existing component structure to match the product console's — it adopts what fits without a structural rebuild.