How to read a component page

Every component page opens with the same three answers, in the same order. If you only read one thing, read those.

How

What it is made of and what it does. The markup, the classes, the states it can be in.

When

The situation that calls for it, and the situations that do not. This is the part people skip and then get wrong.

Where

The places it is allowed to appear, and the places it must not. Some components only make sense inside one pattern.

After those, a page carries whatever else is true of that component:

Anatomy names the parts, so a conversation about a change can be specific.

States lists rest, hover, focus, active and disabled where they differ, and says which are deliberate omissions.

Accessibility states what the component is responsible for. Some components carry an obligation you cannot see, such as a name for screen readers or a minimum target size, and skipping it breaks a rule the whole site is held to.

Content gives the writing rules for any text inside it: length, tone, what is barred.

Do and Don’t is the short version for someone in a hurry.

Checks before you ship is what to verify, phrased so a tester who has never opened the code can run it.

In code names the Astro component that renders it and lists its props. Where a page has no “In code” section, that component exists as CSS and markup only: the classes are real and documented, but there is nothing to import yet, so the markup gets written by hand each time. Those are the ones still to build.

What is real in code, and what is not

As of October 2026 these render from a component under src/components/ui/: Button, ButtonGroup, Pager, PagerPair, CaseHero, MetaRow, CaseFigure, CaseSection, CaseBlock, Eyebrow, Note, Quote, StatList, AwardList. Every case study page is assembled from those and carries no CSS of its own.

These are still CSS and markup only, written by hand: the case study card, the dialog, the navigation, the progress dots and the row list. They live on the home page, which has not been converted yet. Their pages describe real, shipped classes, but there is no component to import.

Saying which is which is the point. A documented class that looks like a component is how two slightly different versions of the same thing end up in a codebase.

The Figma library

The library lives in SDC Fall of 2026. It carries the token collections, nine components, the home and case study screens assembled from them, and a flow of the routes.

Every value in it is read from the stylesheet this site ships. The font families are variables too, font/display and font/body, bound to the text styles.

One thing in it is not faithful, and the cover page says so: the web type scale is fluid, clamp(min, viewport, max), and Figma has no fluid value, so the Type scale collection carries the two ends as Mobile and Desktop modes.

Worth knowing about the display face. nickel-gothic-variable has a width axis and a slant axis and no weight axis, so Regular is its only weight. That is why the Figma display styles are Regular rather than Black, and it means the font-variation-settings: "wght" 900 in the stylesheet does nothing on that face. It is inert, not wrong, but it reads like a setting that matters.

There are two SDC libraries in Figma and they are versioned rather than one replacing the other:

1.0 is SDC Design Tokens, last touched 17 April 2026. Colour only, every variable ALL_SCOPES, and it predates both the live v2 site and the decision to ship light as the default. It stays published; anything already pointing at it keeps working.

2.0 is this one. It is what the site ships today, and it is what new work should use.

If the two disagree, 2.0 is right. The version in the name is what tells you which, so do not drop it.

What a component page is not

It is not a live render. The Storybook does that, from the site’s own stylesheet. It is not a token list either, for the same reason: one source, not two.

If a page here and the running site disagree, the site is right and this page is a bug. Say so and it gets fixed.