How to Set Up a Design Team From Scratch

Starting a design team from scratch is an opportunity to do things right before the shortcuts accumulate. The decisions you make early — tooling, naming conventions, review processes — are hard to change once the team has grown into them.

Here's how to build the foundation well.

Tool stack decisions

The core stack that works for most product design teams:

Figma for design. It's the industry standard, and for good reason — real-time collaboration, a powerful component system, Dev Mode for handoff, and the largest ecosystem of plugins and community resources. Start with Professional ($15/editor/month) and evaluate whether you need Organization ($45/editor/month) for branching and advanced admin controls.

Notion for documentation. Design specs, decisions, onboarding docs, project briefs, research findings — Notion handles all of it. The linked database system is useful for connecting related docs (a project brief linked to its research notes linked to its design spec). Set this up early before documentation starts living in random Google Docs.

Linear for project tracking. Design work belongs in the same tracking system as engineering work, not in a separate design-only tool. When designers create Linear issues alongside engineering issues, stakeholders get one place to see project status, and the handoff moment (design done → engineering picks up) becomes a tracked event, not an informal handshake.

Miro for workshops and whiteboarding. Journey maps, design sprints, retrospectives, and affinity mapping all need a shared visual space. Miro's template library and real-time collaboration make it the best tool for this.

Try Figma

Naming conventions and file organization

Set these up before anyone starts working. Changing naming conventions retroactively is painful.

Figma file naming: [Product] / [Feature or Section] / [Type]

Examples:

• Checkout / Cart / Design
• Checkout / Cart / Explorations
• Design System / Components / v2

Project structure in Figma (pages within a file):

1. Cover (title, version, status, owner)
2. Working (active designs, not for stakeholders)
3. Review (designs ready for feedback)
4. Archive (past versions, don't delete)
5. Components (local component overrides specific to this project)

In Notion, a basic page hierarchy:

• Design Team (root page)
  • Handbook (team processes, tools, onboarding)
  • Projects (one page per project, with brief, research, spec, decisions)
  • Design System (component docs, usage guidelines)
  • Research (interview notes, usability test reports)

Design system foundations

Don't try to build a full design system on day one. Build the foundations that prevent the most common mistakes:

• Color styles in Figma with semantic naming
• Text styles with a clear type scale
• A spacing scale (8pt grid, defined values: 4, 8, 12, 16, 24, 32, 48, 64)
• A shared icon library

This is the minimum. It gives everyone consistent raw materials without the overhead of a full component library.

Document even these basics in Notion. A one-page spec for "how we do color" prevents each designer from making independent color decisions.

Code of conduct for design reviews

Write down how design reviews work before you run the first one. Without explicit norms, reviews default to whoever talks loudest winning.

A simple code of conduct:

• The designer presenting explains the goal first, before showing screens
• Feedback focuses on user needs, not personal preference
• Questions are welcome; directives are not (say "I wonder if..." not "you should...")
• One voice at a time; no side conversations
• Decisions get captured in the Figma file or a Notion doc before the session ends

Publish this in your team Notion. Reference it when a review goes sideways.

Onboarding a new designer

A new designer should be productive within their first week. That requires a documented onboarding path:

Day 1: Tool access, Figma team walkthrough, Notion handbook read-through. Day 2–3: Shadow a design review, read two or three recent project specs, learn the naming conventions. Day 4–5: First small task with a designated buddy for questions. Week 2: First solo task, feedback session with their manager at end of week.

Write this as a Notion checklist. The new designer should be able to follow it independently.

The rituals that keep teams aligned

Weekly design sync (30–60 min). Every designer shares what they're working on and where they're stuck. No presentations, no polish — just current status and blockers. This prevents the "I didn't know you were redesigning that" problem.

Design reviews (as needed, not on a fixed cadence). When a designer has something ready for feedback, they schedule a review. Don't put this on a fixed weekly slot — it creates artificial pressure to have something to show.

Retrospectives (monthly or per-project). What's working, what isn't, what to try next. The design team needs its own retros separate from engineering retros, because the design process issues are different.

Try Notion Free

The goal with all of these: predictability. Designers should know how work gets reviewed, how decisions get made, and how to escalate blockers. When the process is predictable, designers can focus on the work instead of navigating politics.