Atlassian Design System

The Atlassian Design System exists to keep a large family of Atlassian apps consistent, and it shows in what it prioritises. Where many systems lead with components, ADS leads with tokens and primitives, and treats components as the layer you reach last. That ordering is the main thing worth studying here, whether or not you ever ship an Atlassian-style product.

Tokens carry the system Atlassian calls its tokens the single source of truth for design decisions, and the structure backs that up. Color, typography, spacing, radius, and elevation are all tokens, and every color token is defined twice, once for light and once for dark, so a theme change is a change of token values, not a fork of the stylesheet. Spacing is built on an 8-pixel base unit, and typography is applied through a Text primitive or Heading component rather than raw font-size values. A team adopting only this layer, tokens plus discipline about using them, gets most of the consistency benefit even if it never imports an ADS component.

Primitives first, components second Between tokens and components sit the primitives: Box for containers, Stack and Inline for vertical and horizontal layout, Flex and Grid for the CSS layout models, Bleed for negative margins, Pressable and Anchor as the bases for custom buttons and links, and Text for typography. The point of the layer is that custom UI gets composed from token-backed building blocks instead of freehand CSS, so one-off screens stop drifting away from the system. Atlassian currently recommends the compiled entry point for primitives; the older plain package is listed as legacy, which is worth knowing before you copy an import from an old tutorial. On top sit the familiar components, grouped the way product teams actually need them: forms, navigation, feedback, overlays, and data display.

Tooling is part of the product Most design systems publish rules and hope. ADS also ships the enforcement: an ESLint plugin for design-system use and another for its UI styling standard, so token and styling rules are checked in the editor and in CI rather than in design review. Migrations between versions are supported with codemods. Designers get official Figma libraries and a plugin with token integration, and there is an official MCP server exposing the system's tokens, icons, components, and accessibility tooling, which is a practical sign of where system documentation is heading: written for coding agents as well as people. The accessibility guidance is similarly concrete, targeting WCAG 2.1 AA with per-component notes on ARIA, keyboard behaviour, and screen readers.

The catch: it is Atlassian's system first ADS is a house system that happens to be public. The implementation is React and TypeScript only, the setup expects its css-reset, tokens, Babel plugin, and Compiled-based styling to be configured the documented way, and the visual result is unmistakably the Atlassian app look: dense, blue-led, and built for screens full of issues, pages, and tables. Inside an Atlassian-shaped product that is a feature. Outside one, you are adopting a strong opinion about how software should look, and a migration path tied to one vendor's roadmap.

Bottom line Building a React product with dense, collaborative, data-heavy screens? ADS is one of the most complete public references, and its packages are Apache 2.0, so adopting pieces of it is legally simple. Studying design systems from the outside? Start with the token and primitive layers and the lint tooling; that is where this system is ahead of most of the field.