How to Use Linear for Design Teams

Linear was built for engineering teams and it shows. But design teams that use it alongside engineering get something valuable: a shared task system where design work and implementation work are tracked in the same place.

Here's how to set it up so it works for design, not against it.

Setting up a design team project

In Linear, create a dedicated Team for design. Don't add design issues to the engineering team — they'll get lost in the noise and the issue states won't match your workflow.

Name it "Design" or "Product Design." Set the team identifier to something short: "DES" or "UX."

Within the design team, create Projects for each major initiative. A project in Linear corresponds to a discrete piece of work with a timeline — "Checkout Redesign," "Onboarding v2," "Mobile Navigation." Projects can contain cycles (sprints) and have their own milestones.

Keep your teams and projects structure simple. One design team, projects per initiative, cycles per sprint. That's the right starting structure.

Issue states for design workflow

The default Linear states (Backlog, Todo, In Progress, Done, Cancelled) don't map well to design work. Update them for your team.

A state sequence that works:

Backlog → Scoping → In Design → In Review → Ready for Dev → In Development → Done

• Backlog: Not yet prioritized
• Scoping: Understanding the problem before designing
• In Design: Active design work happening
• In Review: Design is ready for feedback from teammates or stakeholders
• Ready for Dev: Design is approved and specs are prepared
• In Development: Handed off, engineering is building it
• Done: Shipped

The "Ready for Dev" state is important. It's a clear signal to engineers that this design is ready to implement, and it prevents work from being picked up before it's actually spec'd.

Set the "In Development" and "Done" states to be managed by the engineering team if you're working closely with them. Design issues should automatically move through those states as the code ships.

Linking Figma to Linear issues

Paste a Figma file URL into a Linear issue and it embeds a preview automatically. Click through to open the file directly.

The better approach: use Figma's Linear integration plugin. From inside Figma, you can create a Linear issue from a selection, or link an existing issue to a frame. The linked frame URL appears in the Linear issue, and the Linear issue ID can be added to the Figma frame as an annotation.

This bidirectional link keeps design and implementation in sync. When a developer opens the Linear issue, they're one click from the exact Figma frame they need. When you're in Figma, you can see what Linear issues reference that file.

For design system work, create a separate Linear project called "Design System" and link each component issue to the corresponding Figma component.

Start using Linear for your design team

Using cycles for design work

Cycles in Linear are the equivalent of sprints. You define a duration (1 or 2 weeks is standard) and move issues into the cycle to commit to them.

For design teams, cycles work best for:

• Planning design deliverables per sprint
• Tracking how much work is in progress simultaneously
• Reporting progress to stakeholders at the end of each sprint

At the start of each cycle, move issues from Backlog to the active cycle and assign them to specific designers. At cycle end, review what was completed vs carried over.

Carryover is data. If the same issues keep rolling over, either they're too large (break them down) or they're consistently getting deprioritized (have a conversation about capacity).

Don't treat cycle planning as a rigid ceremony. For design teams, the value is visibility, not sprint velocity calculation.

GitHub integration — tracking when designs get implemented

Linear's GitHub integration is one of its most underused features for design teams.

When developers create a pull request that implements a design, they mention the Linear issue ID in the PR description or branch name (des-42-checkout-flow). Linear automatically links the PR to the issue and updates the issue status when the PR is merged.

For designers, this means you can see in Linear when your designs have actually shipped. Without this, you're often left wondering whether something you designed three weeks ago has been built yet.

To enable it: go to Settings → Integrations → GitHub. Connect your GitHub organization. Branches and PRs mentioning issue IDs will link automatically.

Keyboard shortcuts that matter

Linear's keyboard shortcuts are good enough that they're worth learning from day one.

• C — create new issue (from anywhere)
• Cmd + K — command palette (fastest way to navigate)
• Cmd + / — search
• G then I — go to My Issues
• G then C — go to active Cycle
• E — edit issue title inline
• A — assign issue (opens assignee picker)
• S — change status
• P — change priority

The most useful habit: use Cmd + K as your default navigation. It's faster than clicking through the sidebar.

Connecting Linear to Notion

Linear issues should link to relevant Notion documentation. When you write a design spec or decision doc in Notion, paste the URL into the corresponding Linear issue's description.

In Notion, use the Linear integration to show linked issues in your project database. This gives you the best of both tools: Linear for task tracking, Notion for documentation, with clear links between them.

Document design work in Notion

What not to track in Linear

Linear isn't the right place for:

• Research notes and synthesis (use Notion)
• Design system component documentation (use Notion)
• Stakeholder meeting notes (use Notion)
• Long-form design rationale (use Notion)

Linear is for discrete, actionable work with a clear status. Anything that's documentation rather than a task belongs in Notion. Keep the distinction clear and both tools stay useful.