The Linear design system, read as constraints

Start here, because most of the confusion downstream comes from skipping it. Linear does not publish a design system. There is no @linear/tokens on npm, no Storybook, no documentation site at a design.linear.app equivalent, no Figma library released by the company. Compare that with IBM's Carbon, Shopify's Polaris or Salesforce Lightning, all of which ship installable packages and public documentation as a deliberate product decision.

What exists instead is three kinds of secondary material, and it is worth knowing which one you are reading:

The distinction matters because an extraction can tell you a surface is #0f1011 but cannot tell you it is one deliberate step above the canvas rather than an accident. Everything below is stated at the level it can actually be supported: observable patterns, with the reasoning left visible so you can disagree with it.

If you take one thing from this: Linear's type sits in a narrow weight band, roughly 400 to 510, across essentially the entire product. A 72px display heading and a 15px label are separated by size and colour, not by weight. Bold, in the 700 sense that most interfaces reach for, is functionally absent.

That single constraint does more visual work than the palette. A wide weight band — 400 body, 600 labels, 700 headings, 800 hero — is the default that every UI framework ships with and every AI-generated interface reproduces. It reads as loud, and it reads as generic, because hierarchy is being shouted rather than composed. A narrow band forces hierarchy to be carried by size, spacing and colour instead, which is slower to get right and much harder to imitate accidentally.

The variable-font detail is what makes 510 possible at all. A weight of 510 is not a static cut; it exists because the interface uses a variable typeface where any value on the axis is available. Trying to reproduce this with static weights gives you 500, which is close, and the near-miss is part of why replications feel almost-right.

This is the detail most reproductions miss entirely, and it is measurable rather than a matter of taste. Letter-spacing in Linear moves negative as size increases: display type in the 48–72px range sits around -0.022em, mid-range headings around -0.012em, and body-scale type around -0.010em. The relationship is monotonic — bigger type, tighter tracking.

The reason is optical, not decorative. Letterforms drawn to be readable at 16px carry sidebearings sized for 16px. Scale them to 64px and those gaps scale too, so the word visually falls apart into letters. Professional type design compensates with optical sizes; interface work compensates with a tracking ramp. Most design systems set one letter-spacing value, or none at all, and their headings look loose in a way nobody can name.

/* The ramp, expressed as tokens. Values shown are the pattern,
   not Linear's — pick your own by eye at each step. */
:root {
  --tracking-display: -0.022em;  /* 48px and up */
  --tracking-heading: -0.012em;  /* 20-32px */
  --tracking-body:    -0.010em;  /* 13-17px */
  --tracking-label:    0.02em;   /* small caps, 11-12px: loosens */
}

Note the reversal at the bottom. Small uppercase labels want positive tracking for the same optical reason large display type wants negative. A ramp that only goes one direction is half the rule.

Linear separates surfaces with borders at sub-pixel widths — 0.5px on displays that can render it — and a stepped set of near-black greys, rather than with drop shadows. The canvas sits at roughly #08090a, card surfaces one step up around #0f1011, elevated panels above that. Borders come from a low-contrast grey around #23252a for structural edges, with a slightly brighter step for section separators.

This is a genuine trade-off, not a strictly better choice, and it is worth being honest about the cost. Shadows communicate depth pre-attentively; a reader knows a card is above the page without looking at it. Hairlines do not. What you gain is a flat, dense, precise surface where a lot of information can sit close together without visual noise — which is exactly what an issue tracker needs and exactly what a marketing site does not.

That last row is the one to act on. The reason a Linear-style treatment often fails on a landing page is not that it was executed badly; it is that the elevation strategy was chosen for information density and then applied to a surface with four cards on it.

The colour observation people repeat is "Linear is purple". At time of writing the observable interface reads closer to near-monochrome with a single high-chroma accent used for primary action and active state, plus a small set of chromatic fills reserved for tags and labels. The specific accent hue has changed across redesigns; the structural fact has not.

The structural fact is a ratio. The accent appears on a small percentage of pixels — a primary button, an active nav indicator — and everything else is grey. Copying the hue and applying it at typical SaaS density (accent headings, accent icons, accent links, accent borders, accent gradient hero) produces something that shares Linear's palette and none of its character.

The tag colours are worth separating out because they are a different system. A handful of chromatic fills — a violet, a teal, a coral, a green — exist to make labels distinguishable at a glance, the way categorical series work in a dashboard palette. They are not brand colours and they are not status colours, and a system that conflates the three ends up unable to show an error in red because red already means "marketing" on a label somewhere.

Radii cluster tight — roughly 6px on controls and 12px on larger containers — against a default ecosystem habit of rounded-lg and up on everything. Padding is compact, in the 8–12px band for controls rather than the 16–24px that most component libraries ship.

Both follow from the same source as the hairlines: density. A dense tool cannot spend 24px of padding per control, and large radii on small elements start to eat the element. The rule underneath is not "use 6px" — it is that radius should scale with the element, and most systems apply one radius token to a 28px button and a 400px panel alike.

Copying this is the wrong outcome, and not only for the trademark reason. A design system is downstream of a product decision. Linear's density serves people who live in an issue tracker for six hours a day; that reader has different needs from someone landing on a pricing page for forty seconds. Lifting the surface treatment across that gap gives you an interface optimised for a job your product does not have.

The transferable thing is the method. Every observation above has the same shape: notice a pattern, work out the constraint that produces it, then write the constraint down as a rule. That is a repeatable exercise you can run on any product you admire, and it is what turns a mood board into something an agent can execute.

1. 1

   Screenshot three screens, not one

   A single screen tells you the palette. Three tell you which decisions are consistent — and consistency is what distinguishes a system from a page.

2. 2

   Measure, do not eyeball

   Open dev tools and read the computed values: font-weight, letter-spacing, border-width, border-radius, padding. Write down actual numbers. "Tight tracking" is not a rule; -0.022em above 48px is.

3. 3

   Look for the range, not the value

   The insight is rarely a single number. It is that all the weights fall between 400 and 510, or that every radius is 6 or 12 and nothing else. Ranges are rules; single values are samples.

4. 4

   Write down what is absent

   No shadows. No weights above 510. No second accent. No gradients. Absences are the highest-value part of a teardown and the part that never survives into a palette export.

5. 5

   Convert each observation into an instruction

   "Elevation uses a 1px border and a surface step, never a box-shadow" is executable. "Minimal and precise" is not. This is the step where a teardown becomes a design system.

We sampled 299 DESIGN.md files published across public repositories and directories to see what design guidance actually contains when it is written for an AI agent to read. The results explain why teardown-derived systems degrade.

Three quarters of these files contain no prohibitions. But as the teardown above shows, prohibitions are where the identity lives — no bold, no shadows, no second accent. A file that lists Linear's hex values and omits its restrictions has captured the least distinctive part of the system and discarded the rest.

The vague-adjective figure compounds it. "Clean" appears in 39% of these files and "modern" in 36%. Both are words a model will happily satisfy with the average of its training data, which is the reason AI-generated interfaces converge on the same look. Neither word constrains anything.

If the output of a teardown is going to a coding agent, it needs to survive being read once and applied across dozens of files. That means named tokens with stated purposes, and an explicit prohibition list. Here is the shape:

## Type

Weights: 400 and 510 only. Never use 600 or above; hierarchy is
carried by size and colour, not weight.

Tracking ramps with size:
- 48px and up: -0.022em
- 20-32px:     -0.012em
- 13-17px:     -0.010em
- 11-12px uppercase labels: +0.02em

## Elevation

Never use box-shadow. Elevation is a surface step plus a 1px border:
- canvas   -> surface   -> elevated
- Border: --border-subtle for structure, --border-strong for sections

## Accent

One accent. It appears on primary buttons and active nav state only.
Do NOT use the accent for headings, links, icons, borders or gradients.
Tag fills are a separate categorical set and are not brand colour.

## Never

- No gradients
- No drop shadows
- No second accent colour
- No font-weight above 510
- No border-radius above 12px

Notice how much of that file is the Never section and the prohibitions embedded in each rule. That ratio is the point. If you hand an agent a palette and a font name, you have given it permission to do everything else however it likes, and everything else is most of the interface.

There is a version of this exercise that produces something worse than what you started with. It happens when the teardown becomes the goal: you assemble a rigorous set of rules describing someone else's product, hand it to an agent, and get back a competent imitation with no reason to exist.

Design systems that are actually good are downstream of an argument about the reader. Linear's is an argument that a power user in a tool all day wants density and quiet. A learning product might argue for generous spacing and warmth. A financial dashboard might argue for reserved status colours and a neutral scale that survives a dense table. The rules follow from the argument; they do not substitute for it.

So use the teardown for calibration, not for content. It tells you what a rigorous system looks like — how specific the numbers get, how many things get forbidden, how narrow the ranges are. Then go make that argument about your own product.