MM Component Library

Chapter 1 — Why a Second Library

A design system earns trust by covering the decisions people actually face. ACF is strong at its core: tokens, foundational components, answer-card templates. Where it goes quiet is exactly where multimedia lives — image tiles, waterfall grids, category selector strips, carousels, and the full page experiences assembled from them.

The result was familiar to anyone who's worked in a system's blank zone: every multimedia project re-derived its own components, coherence reviews had no reference to point at, and "is this consistent?" became a matter of memory and taste rather than lookup. Meanwhile our AI-assembled layouts (the vNext component work) made the problem sharper — when an AI composes the page, the components are the design contract, so they'd better be defined somewhere.

The fix isn't forking a design system. It's defining the missing layer on top of the existing one, with an explicit rule for what belongs to whom.

Chapter 2 — The Architecture: Levels and Provenance

The library's spine is a four-level hierarchy with a strict ownership rule at each level:

• Atom — tokens: color, type, spacing, radius, elevation. Owned by ACF — we reference, never rebuild.
• Molecule — a single component: a badge, an image tile. Two provenance bins, below.
• Cell — a structure of molecules: waterfall, category selector, carousel grid. Mostly MM-built.
• Organism — a page-level experience: the image answer, the Vertical page. MM-built.

The interesting design decision is at the molecule level: every component is sorted into one of two provenance bins —

• ACF-direct-use: the component exists in ACF; we pull it as a pinned instance so it tracks the source library's live state. Never redrawn, never allowed to drift.
• MM-built: we build it, it consumes ACF tokens — but the component is the multimedia library's asset, with its own lifecycle.

One subtlety cost real debate: token usage carries zero provenance signal. An MM-built component uses ACF tokens by definition (that's the atom rule), so "it uses ACF tokens" tells you nothing about who owns it. Provenance is decided only by where the main component actually lives. Small rule, but it's the difference between a library and a pile — without it, every future maintainer re-argues ownership from vibes.

Cross-surface sharing follows from the structure: pages are organized by level, not by surface, so a molecule shared by SERP and the Vertical is stored exactly once and varies inside its own entry. One source of truth, two surfaces.

Chapter 3 — Maturity Is a Template, Not a Feeling

What separates a mature library from a pile of frames isn't the components — it's that every entry answers the same questions. I borrowed the documentation model from ACF's best pages and extended it with the governance fields the multimedia layer needs. Every component ships with:

purpose → variants (flat, as examples) → when to use / when not to (✅/❌) → anatomy → states → properties — plus, MM-specific: its provenance bin, and either the pinned source (if ACF-direct-use) or build status (if MM-built).

That last row is the governance layer in embryo: when a coherence review asks "is this component sanctioned?", the answer is written on the component itself. And each entry deliberately leaves room for a code-mapping line, so the library can later be harvested by tooling — the ambition is a library machines can consume, not just designers.

Chapter 4 — Building It AI-Natively

This is the first design-system project I've run where AI agents are part of the crew, and the division of labor is the case study inside the case study:

The reference archive. ACF's Figma documentation spans well over a hundred pages and changes weekly. My agents extracted the entire file — every component's variants, usage rules, anatomy, and its full multi-layer token system — into a linked, searchable archive, spot-verified against the live file. That archive is what makes "reference, never rebuild" practical: checking what ACF already defines is now a lookup, not an afternoon.

The teardown loop. For inventory, I assemble real production pages — one SERP, one Vertical — side by side in a working file, and agents tear them down component by component, proposing a level and provenance for each piece. I correct, they re-classify; my judgment, their legwork. The corrections aren't lost, either — they're written into the project's architecture notes so the same mistake can't be proposed twice.

The honest boundary. Judgment stays human. Agents can inventory what exists; deciding what a component is — its level, its bin, whether current usage reflects intended usage — is design judgment, and several early machine guesses were confidently wrong. The workflow is designed around that: agents propose, the designer disposes.

Chapter 5 — Status and the Point

The architecture is settled and documented; the reference archive is live; the inventory teardown is running; the library file is being populated level by level. Governance process — review tiers, coherence tagging — is deliberately sequenced after the library exists, because a review process is only as good as the reference it can point at.

Why this project matters to me: my earlier Bing work taught me that layout optimization has a ceiling and systems don't. This is the far end of that lesson. The component work made AI-assembled pages possible; the library work makes them governable. Defining what exists, who owns it, and how it's allowed to change — that's the design work that makes everyone else's design work coherent. It's invisible when done well, and unmistakable when missing.