Linear Design Principles

Apply how Linear thinks about UI, UX, and product. The throughline: design is product judgment, not decoration, and it only works when backed by structure, opinionated defaults, near-zero latency, trained quality, and small teams that own problems end to end.

[!info] Terminology trap "Linear design" in most search results means a generic SaaS aesthetic (dark mode, gradients, minimal landing pages) named after the company. That is the look, not the method. This skill is about how Linear actually works. Ignore the aesthetic literature.

When to apply this

Reach for these principles when the task is one of:

• Designing or reviewing an interface → use the hierarchy + clarity rules below, then references/ui-ux-craft.md.
• Framing a product problem → "problem before solution"; interpret requests, don't transcribe them.
• Planning a redesign or paying down design debt → references/ui-ux-craft.md (redesign strategy).
• Designing AI/agent features → "build the workbench, not the chatbox."
• Deciding process, org, or how decisions get made → references/operating-model.md.
• Building, not just deciding (accessibility, the checkable craft details) → references/accessibility-and-craft-specs.md.
• Tempted to apply a principle as universal law (or the product isn't Linear-shaped, a platform, an API, a consumer app) → references/boundaries-and-peers.md for where Linear's opinions have limits and which peer answer applies.
• Citing or sourcing a claim → references/sources.md.