Component inventory
One component shipped. Eight in flight. Twenty more catalogued and waiting their turn. The system grows component by component – never in a single push – and every one ships against the same contract before it’s marked done.
This page is the honest count. What you can use today, what’s coming next, and what we’ve decided we won’t build. If the answer to “is there a component for X?” isn’t here, the answer is no – and the proposal route at the bottom of this page is how we’d hear about it.
The component contract
A component is “shipped” when it satisfies all eight points below. Anything less is “beta” or “in progress” – useful labels because they tell you what’s safe to put in production and what isn’t. The contract is non-negotiable. Skipping a check to hit a deadline is how design systems quietly become inconsistent UI libraries.
var(—es-color-teal-600) Status taxonomy
Five labels. They mean exactly what they say.
Meets the full contract. Safe to use everywhere. Breaking changes require a major version.
Meets the contract minus full state coverage. Usable in production. The API can still shift.
Actively being built. There’s an owner, a brief, and a target. Don’t depend on it yet.
On the roadmap. The brief exists. No work has started. Sequencing is on this page.
Intentionally excluded. The reason is on the page. Don’t propose it without reading first.
Inventory
Every component the system tracks, grouped by what it does. Names that link out have a docs page; the rest are catalogued but not yet authored. The “depends on” column is honest about prerequisites – nothing ships until its dependencies have.
Action
Input
Display
Navigation
Feedback
Overlay
Data
Editorial
Editorial elements live in the typography and patterns pages, not as standalone components. They’re CSS classes on the long-form template – pull-quote, drop-cap, end-mark, caption – and they ride the same type tokens as everything else.
What “good” looks like
Two ways to wire up the same primary action. One satisfies the contract, the other quietly breaks it.
<Button variant=“primary”>Save</Button>The variant carries the meaning. The colour, padding, and motion follow from tokens. Light mode, dark mode, and reduced motion all just work.
<Button style={{ background: ‘#06A0A9’ }}>Save</Button>Inline values bypass the token layer. Dark mode breaks. Brand updates skip you. The component’s contrast guarantees no longer apply.
API contract
Every component speaks the same prop language. If you’ve used one, the next one looks familiar. The shape:
interface ComponentProps {
variant?: 'primary' | 'secondary' | 'ghost' | 'danger';
size?: 'sm' | 'md' | 'lg';
as?: 'button' | 'a' | 'span';
loading?: boolean;
disabled?: boolean;
iconLeft?: IconName;
iconRight?: IconName;
'aria-label'?: string;
children?: ReactNode;
}What each prop does, and why it’s the same shape every time.
variant=“primary” size=“md” as=“a” loading={isSaving} disabled iconLeft=“arrow-right” aria-label=“Close” What the API deliberately does not expose: colour and spacing. Those live in tokens, not props. If you want a different colour, change the variant. If you want different spacing, change the size. If neither fits, the component is wrong for the job – or the system needs a new variant. Either is a conversation, not a one-off override.
Out of scope
The system will not provide the items below. They’re useful, sometimes essential – but they belong to libraries that already do them better than we could.
Roadmap
The next twelve months. Phases ship together – we’d rather release “forms” than “text field” – and the dates are targets, not promises.
- Q3 2026 Forms v1.0 Text, textarea, select, checkbox, radio, switch. The full set lands together.
- Q3 2026 Card · Tag · Badge The display primitives forms depends on for layout.
- Q4 2026 Top nav · Footer · Tabs Site-level chrome. Replaces the current ad-hoc nav across product surfaces.
- Q4 2026 Modal · Toast · Banner Overlay and feedback patterns. Modal first because every form needs it.
- Q1 2027 Table · Pagination · Empty state Tabular data and the empty case it falls back to.
- Q1 2027 Tooltip · Popover · Menu The smaller overlays. Tooltip and popover share the same anchor primitive.
How to propose a component
Three things we want to see before work starts. Bring them to design review – it runs every other Wednesday at 14:00.
The use case
Where does it appear? What problem does it solve that an existing component doesn’t? One paragraph. Specifics beat abstractions every time.
Two reference designs
From inside the product if possible, from elsewhere if not. They tell us what “good” looks like before anyone opens Figma.
The dependency list
What tokens, what other components, what libraries. If something’s missing from the system, we’ll need to build that first.
Governance details – review cadence, who signs off, how breaking changes are versioned – live on the governance page.
Owners
Each category has a current owner. They review proposals, sign off on shipped releases, and take the on-call pager when something breaks. For anything cross-cutting, mail design@executivesupport.com.