Figma
Figma is a web-based UI/UX design tool. It enables design, prototyping, and real-time collaboration, widely used by designers and product/development teams.
Get started
Beginner-friendly map of Figma’s core navigation and first collaboration loop.
Quick scan
- Location ≠ permission: Drafts/Projects vs access levels.
- Share at the right scope; test access once.
- Use comments to track feedback and decisions.
1) Purpose & outcomes
Get oriented fast: create a first file, structure it, and share it safely. You finish with a review link and a file others can navigate without help.
- Know Drafts vs Projects vs Files.
- Create and name a file with basic structure.
- Share with the right access (
can view/can edit). - Use comments to track feedback and decisions.
2) Who • When • Where in navigation
For anyone new to Figma or joining a team. It follows the Help Center’s Get started + file browser + sharing docs.
- Who: designers, PMs, engineers, students.
- When: first week, new project, client review link.
- Where: Help Center → Get started.
- Related tabs: Files and projects, Figma Design, FigJam, Figma Slides.
3) Mental model / flow
Two layers: where the file lives (discoverability) and who can do what (access). Sharing can inherit from team/project, so verify inheritance before adding people twice.
- Start in Drafts for solo exploration; move into a Project for shared work.
- Share file for one deliverable; share project for a set of deliverables.
- Keep decisions in comments; resolve threads when done.
- Be careful with Trash/restore—deletion affects collaborators.
4) Objects, terms & core jobs
Learn the nouns once; they apply across products. Then use the core jobs list as your day-to-day checklist.
- Drafts: personal space; still shareable.
- Projects: group related files inside a team.
- Files: Design (.fig), FigJam (.jam), Slides (.deck).
- Access:
can view,can edit(plus owner/admin where applicable). - Job: create + name + structure a file.
- Job: share link + collect/resolve comments.
5) Happy path workflow #1 — Create a first file
A tiny file that’s easy to reopen and review later.
- Create a new file in Drafts or in a team/project (choose location).
- Rename it (project + artifact).
- Add 2 pages/areas: Start here, Work.
- Add 1–2 starter frames/sections and label them.
- Move the file into the correct project (if you started in Drafts).
- Open Share settings and confirm default link access.
Expected outcome: A named, structured file in the right place, ready to share.
6) Happy path workflow #2 — Share + comments loop
Share once, then use comments as the feedback backlog.
- Click Share, set permission, copy link.
- Ask one reviewer to open the link and confirm access.
- Enter comment mode (
C) and pin 2 comments on specific spots. - Use
@mentionsto assign ownership. - Reply with decisions; resolve addressed threads.
- Re-check Share settings after any changes.
Expected outcome: A single review link with trackable, resolved feedback.
7) Decision points
Four common A/B choices that prevent early chaos.
| Situation | Choose A | Choose B |
|---|---|---|
| Start location | Drafts (solo experiments). | Project (shared + discoverable). |
| Share scope | File (one artifact). | Project/team (many files). |
| Need edit access | Request to edit. | Duplicate only for a real fork. |
| Control copying | Default sharing for collaboration. | Restrict copying/sharing when required. |
8) Guardrails, proof & practice
Most beginner issues are permission + organization mistakes. Use these checks before sending links.
Do / Don’t & pitfalls
- Do: Name pages/sections early.
- Do: Share smallest scope that fits.
- Do: Resolve comments when done.
- Don’t: Don’t Trash shared files casually.
- Don’t: Don’t invite outsiders to the whole team for one file.
- Don’t: Don’t duplicate as a permission workaround.
Common mistakes
Mistake: Wrong share level
Avoid: Decide file vs project vs team; check inheritance.
Mistake: Unclear structure
Avoid: Add Start here + labeled pages/sections.
Mistake: Feedback in chat
Avoid: Capture decisions in comments.
Mistake: Access surprises
Avoid: Test the link with one reviewer.
Mistake: Accidental deletion
Avoid: Learn restore before using Trash.
What good looks like
- File opens to a clear entry point.
- Reviewers can access immediately.
- Comments show decisions and are resolved.
Checklist: pre-check
- File named + located correctly.
- Pages/sections labeled.
- Share settings verified.
- At least one reviewer tested.
- Comment plan defined.
Checklist: post-check
- Reviewer confirms access.
- 2+ comments resolved.
- No accidental access broadening.
- File stays in correct project.
- Link shared with context.
Practice lab (5–15 min)
- Create + rename a file.
- Add Start here + Work pages.
- Share as
can viewwith one person. - Collect 2 comments and resolve them.
- Re-open Share and confirm access.
Expected result: A tidy starter file with correct access and resolved feedback.
Verify you did it right
- Reviewer opens link without prompts.
- Navigation is obvious.
- Threads are resolved cleanly.
Official docs links
- Guide to the file browser — Drafts, Deleted files, navigation.
- Guide to sharing and permissions — Share levels + inherited access.
- Add comments to files — Comment mode, mentions, threads.
Docs sources: Figma Learn Help Center: Get started, Guide to the file browser, Guide to sharing and permissions, Add comments to files.
Figma Design
Foundations for building clean, reusable UI in Design files.
Quick scan
- Frames + Auto layout = stability.
- Components/variants = reuse.
- Run the workflows: 1 screen + 1 component set.
1) Purpose & outcomes
Build UI in a Design file that stays editable as it grows. You’ll leave with one clean screen and one reusable component set.
- Use frames + layers to structure screens.
- Use layout rules (Auto layout) to reduce manual spacing.
- Use components/variants for reuse and consistency.
- Keep naming tidy for review and handoff.
2) Who • When • Where in navigation
For designing screens, components, and prototypes inside design files. Based on Help Center → Figma Design.
- Who: designers + reviewers.
- When: creating UI or a small design system.
- Where: Help Center → Figma Design.
- Related tabs: Dev Mode, Files and projects, Figma Slides.
3) Mental model / flow
A Design file is canvas + layer tree + properties. The fastest path is to encode structure (frames), rules (Auto layout), and reuse (components).
- Frames define boundaries (screens/containers).
- Layers define hierarchy and selection behavior.
- Auto layout encodes spacing/padding rules.
- Components propagate updates to instances.
4) Objects, terms & core jobs
These terms appear throughout the official docs. The jobs list is what you’ll actually do day-to-day.
- Frame: container for a screen/section.
- Component/instance: master + reusable copies.
- Variants: one component set with properties (size/state).
- Auto layout: responsive spacing rules.
- Job: build one screen with clean hierarchy + names.
- Job: convert repeated UI into components/variants.
5) Happy path workflow #1 — Build a clean screen
Make a screen that won’t fall apart when text changes.
- Create a screen frame (device preset or custom).
- Add a top container and apply Auto layout (vertical).
- Add header + content blocks; set padding/spacing.
- Create a button and reuse it twice.
- Rename key layers (Header, CTA, Content).
- Ask for 2 review comments on structure.
Expected outcome: A screen where spacing is rule-driven, and layers are readable.
6) Happy path workflow #2 — Button component with variants
Model size/state without duplicate components.
- Design one button.
- Convert to a component.
- Create variants for size and state.
- Name properties clearly (size=, state=).
- Place instances and swap properties.
- Edit the main component and confirm instances update.
Expected outcome: A button component set with variants that reduces duplicate work.
7) Decision points
These choices impact editability and handoff.
| Situation | Choose A | Choose B |
|---|---|---|
| Repeated UI | Component + instances. | Copy/paste for true one-offs. |
| Dynamic content | Auto layout + constraints. | Manual layout for static visuals. |
| Multiple states | Variants + properties. | Separate components only if needed. |
| Consistency | Use styles/variables for shared tokens. | Direct values for experiments. |
8) Guardrails, proof & practice
Design files get slow when structure is unclear. Keep the file inspectable for others (and future you).
Do / Don’t & pitfalls
- Do: Name frames and key layers.
- Do: Use components/variants for repeats.
- Do: Use Auto layout where content can grow.
- Don’t: Don’t leave default names everywhere.
- Don’t: Don’t detach instances unless forking.
- Don’t: Don’t mix random spacing systems.
Common mistakes
Mistake: Over-grouping
Avoid: Prefer frames/components over deep groups.
Mistake: Inconsistent spacing
Avoid: Let Auto layout handle spacing/padding.
Mistake: No component strategy
Avoid: Start with button/input/card.
Mistake: Messy variants
Avoid: Use consistent property/value names.
Mistake: Hard to hand off
Avoid: Keep a ‘Handoff’ page/section of final screens.
What good looks like
- Layer tree reads like an outline.
- Components cover repeated UI.
- Text changes don’t break alignment.
Checklist: pre-check
- Frames named and ordered.
- Auto layout used where needed.
- At least 1 key component built.
- Variants cover states.
- Canvas has a clear entry point.
Checklist: post-check
- Instances update correctly.
- Variants switch correctly.
- Exports work (PNG/SVG).
- Reviewers can find targets fast.
- No broken alignment after edits.
Practice lab (5–15 min)
- Create 1 screen frame.
- Build a header/content stack with Auto layout.
- Make a button component with 2 sizes + 2 states.
- Place 3 instances and swap variants.
- Export one asset (SVG/PNG).
Expected result: A small UI screen plus a reusable button component set.
Verify you did it right
- Auto layout properties visible.
- Variants have clear names.
- Export matches expectation.
Official docs links
- Figma Design (category) — Design basics and guides.
- Auto layout (guide) — Adaptive layouts.
- Create and use variants — States/options via properties.
Docs sources: Figma Learn Help Center → Figma Design (category), plus guides on Auto layout, frames, and variants.
Dev Mode
Inspect, navigate, and hand off designs for implementation.
Quick scan
- Find Ready for dev targets, then Inspect exact nodes.
- Use statuses + annotations to reduce ambiguity.
- Capture questions in-file (comments).
1) Purpose & outcomes
Dev Mode is a developer-first view for navigating and inspecting designs. You’ll leave with a clear ‘ready’ scope and the ability to pull reliable specs from Inspect.
- Toggle Dev Mode (
Shift+D) when available. - Use ready-for-dev views to find the intended build targets.
- Inspect selections for properties, measurements, variables, and code snippets.
- Use statuses + annotations to reduce ambiguity.
2) Who • When • Where in navigation
For engineers implementing UI and designers preparing handoff. Based on Help Center → Dev Mode.
- Who: engineers, designers doing handoff.
- When: build time, spec review, change tracking.
- Where: Help Center → Dev Mode.
- Related tabs: Figma Design, Billing.
3) Mental model / flow
Dev Mode prioritizes navigation + inspection. The loop: find ready designs → select exact node → inspect → copy details → ask questions in-file.
- Sidebar helps you jump to sections/frames quickly.
- Ready-for-dev status makes intent explicit.
- Inspect panel surfaces specs and snippets.
- Annotations provide implementation notes (filter by category).
4) Objects, terms & core jobs
These terms are used across Dev Mode docs; the jobs list is what teams repeat daily.
- Ready for dev: status applied to frames/sections/components.
- Inspect: measurements/properties/variables; code snippets when available.
- Annotations: notes/measurements; categories for filtering.
- Statuses & notifications: keep everyone aligned on readiness/updates.
- Job: implement from the correct, current target.
- Job: reduce back-and-forth via notes + statuses.
5) Happy path workflow #1 — Designer prepares ‘ready for dev’
Make it obvious what should be built.
- Clean naming for target frames/sections.
- Apply Ready for dev status to the intended scope.
- Add 2–3 annotations for tricky behavior/spacing.
- Use categories so devs can filter notes.
- Share the file and point to the ready-for-dev area.
- Update status/notes when the design changes.
Expected outcome: Developers can open Dev Mode and immediately find what to build with key notes.
6) Happy path workflow #2 — Developer implements using Inspect
Use Dev Mode as the spec source of truth.
- Open file and toggle Dev Mode.
- Use ready-for-dev view to find target screens.
- Select the exact node to implement.
- Review sizing/spacing/typography and variables in Inspect.
- Copy code snippets if available; otherwise note key properties.
- Leave a comment if anything is ambiguous.
Expected outcome: Implementation uses consistent specs from the right node, with questions captured in-file.
7) Decision points
Pick the path that matches access and process.
| Situation | Choose A | Choose B |
|---|---|---|
| No Dev Mode access | Inspect in Design Mode. | Ask admin about Dev Mode seats/settings. |
| Design not marked ready | Request Ready for dev + notes. | Avoid implementing from exploratory work. |
| Many notes | Filter by annotation category. | Ask for cleanup if noise blocks progress. |
| Need code mapping | Use snippets + variable code syntax. | Manual translation if snippets aren’t available. |
8) Guardrails, proof & practice
Dev Mode works when ‘ready’ is explicit and kept current.
Do / Don’t & pitfalls
- Do: Mark ready scope clearly.
- Do: Annotate behaviors/edge cases.
- Do: Select the exact node before inspecting.
- Don’t: Don’t build from unmarked exploratory screens.
- Don’t: Don’t split specs across screenshots.
- Don’t: Don’t leave stale Ready for dev statuses.
Common mistakes
Mistake: Ready too broad
Avoid: Mark only what’s shipping now.
Mistake: Inspecting wrong layer
Avoid: Select the real element, not a wrapper group.
Mistake: No variable clarity
Avoid: Ensure variable values/modes are visible.
Mistake: Spec drift
Avoid: Re-check recency/updates before coding.
Mistake: Questions lost
Avoid: Ask in-file via comments/annotations.
What good looks like
- Ready targets are obvious.
- Notes cover tricky parts.
- Inspect provides consistent specs.
Checklist: pre-check
- Targets named clearly.
- Ready status applied.
- Notes added for edge cases.
- Dev has access.
- One ‘handoff entry’ is identified.
Checklist: post-check
- Dev finds target quickly.
- At least one element spec verified.
- Questions captured in-file.
- Ready status updated if changed.
- Implementation matches notes.
Practice lab (5–15 min)
- Toggle Dev Mode.
- Mark one frame Ready for dev.
- Add 2 annotations (spacing + behavior).
- Inspect a button/text layer.
- Copy a snippet or record key properties.
Expected result: A mini handoff that a dev can navigate and inspect reliably.
Verify you did it right
- Ready scope visible.
- Notes are meaningful.
- Inspect shows correct values.
Official docs links
- Guide to Dev Mode — Basics + access.
- Use code snippets in Dev Mode — Inspect code generation.
- Dev Mode statuses and notifications — Mark ready + track updates.
- Add measurements and annotate designs — Notes + categories.
Docs sources: Figma Learn Help Center → Dev Mode section (guide, navigation, inspecting, code snippets, statuses/annotations).
FigJam
Collaborative whiteboards for meetings, workshops, and ideation.
Quick scan
- Prep sections first; test access.
- Use spotlight + timer + voting to facilitate.
- End with Actions + owners.
1) Purpose & outcomes
FigJam is for collaborative boards (meetings, workshops, ideation). You’ll leave with a board people can join, follow, and exit with clear next steps.
- Create a board (blank or template).
- Organize with labeled sections (agenda).
- Facilitate with spotlight, timer, and voting.
- Share with correct permissions (open sessions if needed).
2) Who • When • Where in navigation
For facilitators and teams running collaborative sessions. Based on Help Center → FigJam + meeting guides.
- Who: teams, facilitators, students.
- When: syncs, retros, brainstorms, planning.
- Where: Help Center → FigJam.
- Related tabs: Get started (sharing), Files and projects.
3) Mental model / flow
A board should work before/during/after the meeting: prep → invite → facilitate → summarize. The most important thing is structure + permissions before people arrive.
- Prep sections first (don’t start empty).
- Confirm access (invite vs open session).
- Use spotlight to guide attention; use timer/voting to converge.
- Close with a Summary/Actions section.
4) Objects, terms & core jobs
These terms appear across meeting docs; the jobs list is the repeatable routine.
- Section: grouped area you can hide/reveal/move.
- Open session: temporary invite link (up to 24h on paid plans).
- Spotlight: ask others to follow your view.
- Timer & voting: timebox and decide.
- Job: run a structured session with participation.
- Job: converge to actions + owners.
5) Happy path workflow #1 — Run a team sync
A simple board-led meeting flow.
- Create a new FigJam file (file browser or
figjam.new). - Add sections: Updates, Blockers, Actions.
- Share and confirm everyone can access (
can editfor participation). - Start an open session if you need external participants.
- Use spotlight while walking through sections.
- Use timer to timebox each section.
Expected outcome: Everyone follows the same board flow and leaves with action items.
6) Happy path workflow #2 — Brainstorm → vote → actions
Collect ideas and converge transparently.
- Create an Ideas section; ask everyone to add stickies for 3 minutes.
- Cluster similar stickies and label themes.
- Start voting and set votes per person.
- End voting and review results.
- Move top themes into Actions with owners (mentions).
- Add a short summary at the top of the board.
Expected outcome: Ranked priorities and clear next steps captured on the board.
7) Decision points
Choose the right collaboration mode for your audience.
| Situation | Choose A | Choose B |
|---|---|---|
| External participants | Open session (temporary). | Invite by email for ongoing access. |
| Permission | can edit for workshops. | can view for read-only review. |
| Starting point | Template for speed. | Blank for custom flows. |
| Decision-making | Voting for convergence. | Discussion only for small groups. |
8) Guardrails, proof & practice
FigJam fails when structure or permissions aren’t ready. Guardrails keep sessions smooth and outcomes reusable.
Do / Don’t & pitfalls
- Do: Prep sections before the meeting.
- Do: Test access with one participant.
- Do: Use timer/voting to keep momentum.
- Don’t: Don’t start on an empty board.
- Don’t: Don’t leave decisions only in voice/chat.
- Don’t: Don’t over-invite to broad scopes.
Common mistakes
Mistake: No agenda
Avoid: Use 3–6 sections matching the flow.
Mistake: Access issues
Avoid: Set Share settings before sending link.
Mistake: Group gets lost
Avoid: Use spotlight to guide.
Mistake: Too much debate
Avoid: Timebox + vote.
Mistake: No wrap-up
Avoid: Create Actions with owners.
What good looks like
- Sections guide the session.
- Decisions/actions are visible.
- Board is clean enough to revisit.
Checklist: pre-check
- Sections created.
- Share settings set.
- Open session decision made.
- Timer/voting plan set.
- Summary area reserved.
Checklist: post-check
- Actions captured with owners.
- Top outcomes summarized.
- Noise cleaned up.
- Link shared with pointer.
- Board reusable as template (optional).
Practice lab (5–15 min)
- Create a new board.
- Add Ideas/Cluster/Actions sections.
- Run a 2-minute timer for ideas.
- Start voting (3 votes/person).
- Move winners into Actions.
Expected result: A tiny workshop board with timed ideation and voting.
Verify you did it right
- Participants can join.
- Timer/voting runs.
- Actions are clear.
Official docs links
- Run meetings in FigJam — Open sessions, spotlight, timer, voting.
- Create your first meeting board in FigJam — Board setup + sections.
- FigJam (category) — More FigJam guides.
Docs sources: Figma Learn Help Center → FigJam category and meeting guides (open sessions, spotlight, timer, voting, sections).
Figma Slides
Create, present, and export slide decks inside Figma.
Quick scan
- Presenter view vs audience view: share the right thing.
- Interactive audience needs access; screen-share is simplest.
- Offline preload and exports are available.
1) Purpose & outcomes
Build and present slide decks collaboratively. You’ll end with a deck that’s ready to present (notes optional) and exportable when needed.
- Create a deck in Drafts or a team project.
- Build slides in slide/grid view (template optional).
- Present in presenter view (with or without notes).
- Export to PDF/PPTX or save a .deck copy if required.
2) Who • When • Where in navigation
For anyone creating and presenting decks in Figma Slides. Based on Help Center → Figma Slides docs.
- Who: presenters, co-presenters, teams.
- When: building a deck, adding notes, exporting deliverables.
- Where: Help Center → Figma Slides.
- Related tabs: Get started (sharing), Files and projects.
3) Mental model / flow
A deck is edited like a file, then presented in presenter/audience view. Screen-share is simplest; audience interaction requires viewers to have access.
- Create deck → add content → add notes (optional).
- Present: Present or Present + Notes (notes stay private).
- Offline: preload presenter view to present without internet.
- Export when you need a non-Figma file (PDF/PPTX).
4) Objects, terms & core jobs
These terms are used in the official docs; the jobs list is your repeatable routine.
- Presenter view: full screen, spotlight for co-presenters, offline option.
- Audience view: what viewers see; used by presentation link.
- Presenter notes: markdown notes; requires
can editto add. - Exports: PDF/PPTX (limitations apply).
- Job: present smoothly (right window/link).
- Job: export/share deliverables safely.
5) Happy path workflow #1 — Create a deck + notes
Make a small, reviewable deck.
- File browser → Create new → Slide deck (Drafts or project).
- Pick a template (or start blank).
- Add 5 slides (Title, Agenda, Key point, Visual, Next steps).
- Open presenter notes and add 2 bullets on 2 slides (markdown).
- Share deck with co-presenters (at least
can view). - Quick run-through in Present mode.
Expected outcome: A deck with structure and notes, ready to present.
6) Happy path workflow #2 — Present (notes + offline + link)
Avoid day-of surprises.
- Click Present; choose Present or Present + Notes.
- If screen-sharing, share the audience window (not notes).
- If internet risk: options menu → Make available offline → wait for ready indicator.
- Copy presentation link if the audience needs to open audience view.
- Co-presenters open presenter view if they need to take spotlight.
- Export to PDF/PPTX after if required.
Expected outcome: A stable presentation flow with the right sharing mode and a backup plan.
7) Decision points
Pick based on audience needs.
| Situation | Choose A | Choose B |
|---|---|---|
| Audience access | Screen-share only. | Share presentation link for audience view. |
| Interactive elements | Give viewers can view access. | Avoid interactivity if sharing is restricted. |
| Notes | Present + Notes. | Present (no notes). |
| Export | PDF for sharing/printing. | PPTX for PowerPoint workflows (limitations). |
8) Guardrails, proof & practice
Slides issues are mostly mode + permission errors. Guardrails keep notes private and links working.
Do / Don’t & pitfalls
- Do: Test Present modes early.
- Do: Share the audience window when using notes.
- Do: Preload offline if needed.
- Don’t: Don’t assume audience can interact without access.
- Don’t: Don’t test the link at the last minute.
- Don’t: Don’t expect perfect PPTX fidelity.
Common mistakes
Mistake: Notes shown to audience
Avoid: Share audience view window, not notes window.
Mistake: Co-presenter can’t take over
Avoid: They must open presenter view.
Mistake: Offline not ready
Avoid: Wait for offline-ready indicator.
Mistake: Viewer export blocked
Avoid: Owner may restrict export/copy; adjust settings if needed.
Mistake: PPTX mismatch
Avoid: Expect limitations; use PDF when possible.
What good looks like
- Presenters have access.
- Notes stay private.
- Export matches distribution needs.
Checklist: pre-check
- Deck location decided.
- Presenters added.
- Notes added where needed.
- Link tested (if used).
- Offline preload done (if needed).
Checklist: post-check
- Presentation ran smoothly.
- Audience view behaved correctly.
- Exports saved if required.
- Deck stored in correct project.
- Feedback captured.
Practice lab (5–15 min)
- Create a new deck.
- Add 5 slides.
- Add notes to 2 slides.
- Open Present + Notes and copy presentation link.
- Export to PDF.
Expected result: A small deck you can present and export without surprises.
Verify you did it right
- Modes switch correctly.
- Link opens audience view.
- PDF export succeeds.
Official docs links
- Create a new slide deck — Create + template picker.
- Present a slide deck — Presenter view, offline, links.
- Add and view presenter notes — Notes + Present + Notes.
- Export from Figma Slides — PDF/PPTX and limitations.
Docs sources: Figma Learn Help Center → Figma Slides docs for creating, presenting (including offline and links), presenter notes, and exporting.
Files and projects
How Figma organizes work: teams, projects, files, and client collaboration patterns.
Quick scan
- Location = discoverability; permission = actions; seat = product access.
- Use projects for shared work; avoid Drafts as source of truth.
- Decide client model early (invite/join/connected project).
1) Purpose & outcomes
Keep work discoverable and collaboration predictable. You’ll end with a clean team → project → file structure and a clear client-collaboration approach.
- Use projects to group related files (Design/FigJam/Slides).
- Move/rename files to keep structure current.
- Share at the right scope (file vs project).
- Pick a client model (invite, join client space, or connected project).
2) Who • When • Where in navigation
For anyone organizing work or collaborating with clients. Based on Help Center → Administration → Files and projects.
- Who: leads, admins, agencies, anyone organizing files.
- When: new project, re-org, client onboarding, project wrap-up.
- Where: Help Center → Files and projects.
- Related tabs: Get started (file browser), Billing (seats).
3) Mental model / flow
Three levers: location (discoverability), permission (what you can do), seat (product access). For clients, decide location + seat implications early to avoid surprise costs or lost access.
- Drafts are private by default; projects in teams are for shared work.
- Share file for one deliverable; share project for many deliverables.
- Clients often need view/comment only—don’t over-seat them.
- Connected projects can let each party use seats from their own plan (admin setup; paid).
4) Objects, terms & core jobs
These terms show up in official guides; the jobs list is your weekly routine.
- Project: container for related files.
- Connected project: host + external shared project (paid + admins).
- Transfer/save a copy: wrap-up options for engagements.
- Job: keep production work out of personal Drafts.
- Job: share the smallest scope that fits.
- Job: define end-of-engagement access/transfer plan.
5) Happy path workflow #1 — Set up a clean project space
Make a project a new teammate can navigate in minutes.
- Create a project in the correct team/org.
- Name it clearly (Client • Product • Quarter).
- Create/move the key files into the project.
- Add a ‘Start here’ page/section inside each file.
- Share project with team; share files with stakeholders as needed.
- Pin/star project and share the source-of-truth link.
Expected outcome: A discoverable project with correct access and navigable files.
6) Happy path workflow #2 — Client collaboration setup
Choose the lowest-friction, least-risk option.
- Decide: client needs review only or active editing?
- Option A: invite client to your project/file (common when you manage work).
- Assign the minimal seat type needed (View for review-only; paid seat for editing).
- Option B: join client space if they manage the work (confirm access/seat).
- If both on paid plans and need a shared space, consider connected projects (admins approve).
- Document end-of-engagement transfer/backups.
Expected outcome: Clear access, predictable costs, and a plan for project end.
7) Decision points
Make these decisions early to avoid rework.
| Situation | Choose A | Choose B |
|---|---|---|
| Work location | Your team (you manage). | Client team (client manages). |
| Client participation | Review only → View seat + access. | Edit → ensure paid seat where files live. |
| Both parties on paid plans | Connected project. | Invites only. |
| Project end | Transfer ownership if needed. | Save/import a copy if access will be removed. |
8) Guardrails, proof & practice
Most issues are over-sharing and seat confusion. Guardrails keep structure and client work clean.
Do / Don’t & pitfalls
- Do: Use projects for shared work.
- Do: Invite at smallest scope.
- Do: Agree on wrap-up plan early.
- Don’t: Don’t invite clients to your entire team.
- Don’t: Don’t assume access lasts forever.
- Don’t: Don’t keep production work only in Drafts.
Common mistakes
Mistake: Over-sharing
Avoid: Use project/file invites instead of team invites.
Mistake: Seat vs permission confusion
Avoid: Seats = product access; permissions = file actions.
Mistake: No conventions
Avoid: Use consistent naming + Start here.
Mistake: Connected project assumptions
Avoid: Admins on both sides approve; confirm requirements.
Mistake: No backup plan
Avoid: Decide transfer/copy/import before access changes.
What good looks like
- Projects match workstreams.
- Stakeholders have view access only.
- Client process is documented.
Checklist: pre-check
- Project created.
- Key files in project.
- Sharing scope chosen.
- Seat assumptions validated.
- Wrap-up plan written.
Checklist: post-check
- New teammate can find files.
- Clients can review without access issues.
- Editors can edit; viewers stay viewers.
- Backups/transfer handled.
- Project stays tidy.
Practice lab (5–15 min)
- Create a project.
- Move 2 files into it.
- Share project with one viewer and one editor.
- Add Start here pages with pointers.
- Write a 3-bullet client access plan.
Expected result: A discoverable project space with clear access and a documented client plan.
Verify you did it right
- Files appear in the project.
- Viewer vs editor access behaves correctly.
- Start here explains navigation.
Official docs links
- Files and projects (category) — Organization basics.
- Guide to collaborating with clients in Figma — Invite vs join client space; seats.
- Guide to connected projects — Host/external setup.
- Guide to the file browser — Drafts/Deleted files/navigation.
Docs sources: Figma Learn Help Center → Administration → Files and projects, plus client collaboration and connected projects guides.
Billing
Plans, seats, approvals, and invoices (without mixing up “seat” vs “permission”).
Quick scan
- Cost drivers: plan + paid seats (Full/Dev/Collab).
- Seat ≠ permission: don’t mix them.
- Approvals + invoices are the core admin routine.
1) Purpose & outcomes
Billing is mostly plan + seats. You’ll leave able to explain seat types, request/approve upgrades, and find invoices without mixing up seats vs permissions.
- Plan type sets features; seat types drive cost.
- Seat type ≠ permission (
can editis not a seat). - Seat approvals control upgrades (manual vs automatic).
- Invoices + billing details support finance workflows.
2) Who • When • Where in navigation
For admins managing subscriptions and members requesting seats. Based on Help Center → Billing.
- Who: org/team admins, billing admins, members.
- When: onboarding, seat changes, invoice review.
- Where: Help Center → Billing.
- Related tabs: Dev Mode (seat impact), Files and projects.
3) Mental model / flow
Keep a clear separation: plan (features), seat (product access), permission (resource actions). Seat requests + approvals are the upgrade pipeline; invoices are the audit trail.
- Starter/Professional/Organization/Enterprise differ in features and billing cadence.
- Seat types include Full, Dev, Collab (paid) and View (free).
- Permissions control what you can do in a given file/project.
- Approvals determine whether upgrades happen automatically or require admin review.
4) Objects, terms & core jobs
These terms are used in billing docs; the jobs list is your recurring routine.
- Seat types: Full / Dev / Collab / View.
- Seat request: member asks for an upgrade.
- Approval settings: automatic vs manual approvals.
- Billing groups: Enterprise-only cost-center grouping (optional).
- Job: allocate minimal seats to match needs.
- Job: review invoices and projected costs.
5) Happy path workflow #1 — Member requests the right seat
Get the access you need without workarounds.
- Identify the action you need (edit designs, use Dev Mode, etc.).
- Attempt the action; if gated, follow the seat request prompt.
- Submit request with project + timeline context.
- Wait for approval (avoid duplicating files to bypass access).
- After approval, confirm the feature works.
- If review-only, request to stay on View seat with proper file permissions.
Expected outcome: You receive the minimum seat type required for your role.
6) Happy path workflow #2 — Admin manages seats + invoices
Control costs without blocking work.
- Open seat management and review current seat counts.
- Review approval settings (automatic vs manual).
- Process pending seat requests (approve/decline).
- Assign the correct seat type (Full vs Dev vs Collab vs View).
- Open invoices to review history and projected costs.
- Update payment/invoice details if needed.
Expected outcome: Seat allocations match real usage, approvals follow policy, invoices are auditable.
7) Decision points
Use these to avoid overspending.
| Situation | Choose A | Choose B |
|---|---|---|
| User need | Review/comment only → View seat + access. | Editing required → paid seat. |
| Approval policy | Manual for control. | Automatic for speed (monitor spending). |
| Enterprise accounting | Use billing groups. | Skip billing groups if not needed. |
| Dev access | Dev seat if required for Dev Mode. | View seat if only reviewing designs. |
8) Guardrails, proof & practice
Billing problems are mostly ‘wrong seat for the job’ and ‘seat vs permission confusion’. Guardrails keep upgrades intentional.
Do / Don’t & pitfalls
- Do: Document seat criteria internally.
- Do: Review seats quarterly.
- Do: Teach seat vs permission in onboarding.
- Don’t: Don’t upgrade everyone to Full by default.
- Don’t: Don’t ignore seat requests (workarounds happen).
- Don’t: Don’t use workspaces as billing groups.
Common mistakes
Mistake: Seat vs permission mix-up
Avoid: Repeat: seat = product access; permission = file actions.
Mistake: Over-provisioning
Avoid: Use Dev/Collab/View appropriately.
Mistake: No approval settings
Avoid: Configure and communicate the upgrade process.
Mistake: Invoice blind spots
Avoid: Review invoice history and projected costs regularly.
Mistake: Billing groups misuse
Avoid: Use only for cost centers on Enterprise.
What good looks like
- Seat types match roles.
- Upgrades are approved with context.
- Invoices are reconciled.
Checklist: pre-check
- Plan type confirmed.
- Seat definitions shared.
- Approvals configured.
- Billing admins assigned.
- Invoice details verified.
Checklist: post-check
- Seat requests processed quickly.
- Seat count matches budget.
- Invoices stored for finance.
- Users have needed access.
- Org structure used correctly.
Practice lab (5–15 min)
- Find your seat type.
- Submit or review a seat request.
- As admin: change one test seat type (if allowed).
- Open invoice history and note projected cost.
- Explain seat vs permission to a teammate.
Expected result: You can operate the basics: seats, approvals, invoices.
Verify you did it right
- You can define seat vs permission.
- You can find seat counts.
- You can find invoices.
Official docs links
- Guide to billing at Figma — Plans, seats, invoicing.
- Manage seats in Figma — Seat types + admin flows.
- Make a seat request — Member upgrade flow.
- Manage payment and invoice details — Invoices and billing info.
- Workspaces vs billing groups — Collaboration vs accounting.
Docs sources: Figma Learn Help Center → Billing and seat management docs (seat types, approvals, invoices, billing groups/workspaces).
Figma Sites Beta
Build and publish websites from Figma with preview, settings, and domains.
Quick scan
- Beta caveat: everything on canvas publishes.
- Preview first, then publish/update intentionally.
- Subdomain is fixed; unpublish/republish is supported.
1) Purpose & outcomes
Publish responsive websites directly from a Sites file. You’ll leave with one page that previews well across breakpoints and a controlled publish/update/unpublish routine.
- Create a Sites file (template/blank/from Design).
- Preview and test across breakpoints.
- Publish to figma.site (custom domain optional).
- Manage settings (SEO/social/password/cookie consent) before publishing.
2) Who • When • Where in navigation
For teams shipping simple sites fast with built-in hosting. Based on Help Center → Figma Sites Beta.
- Who: designers building web pages.
- When: landing pages, small marketing sites, internal sites.
- Where: Help Center → Figma Sites Beta.
- Related tabs: Figma Design, Files and projects, Billing.
3) Mental model / flow
Sites files contain webpages on canvas; preview shows visitor behavior; publishing makes it live. Beta caveat: every webpage on the canvas is included when you publish—keep unfinished pages in another file.
- Build pages → preview → fix issues → publish.
- Changes go live only after you publish an update.
- Unpublish removes the site from the web (you can republish later).
- Assigned figma.site subdomain can’t be changed after publish.
4) Objects, terms & core jobs
These appear in Sites docs; the jobs list is the release routine.
- Webpage: becomes part of the published site.
- Preview: open inline preview (e.g.,
Shift+Space). - Breakpoints: responsive sizes you toggle in preview.
- Publish modal: title/URL, issues, access scope.
- Job: preview across breakpoints before every publish.
- Job: keep publish file free of unfinished pages.
5) Happy path workflow #1 — Build + preview a responsive page
Validate behavior before anything goes live.
- Create a new Sites file (
figma.com/site/newor file browser). - Add/rename one webpage and build a simple header/hero/CTA.
- Preview (
Shift+Space) and toggle breakpoints. - Fix layout issues you observe at each breakpoint.
- Test links/interactions in preview.
- Repeat until the page behaves correctly.
Expected outcome: A page that previews correctly across breakpoints with working links.
6) Happy path workflow #2 — Publish + update (and unpublish if needed)
Ship intentionally, then keep updates controlled.
- Review site settings (SEO/social previews/password/cookie consent).
- Open Publish modal (File icon → Publish).
- Confirm title/URL and access scope (public vs internal on Org/Enterprise).
- Review Issues and fix critical ones.
- Publish and share the live URL.
- After edits, publish an update to push changes live.
- If needed, unpublish from site settings; republish later to reuse the domain.
Expected outcome: A live site that updates only when you publish, with a clear way to unpublish.
7) Decision points
These choices prevent accidental publication and access surprises.
| Situation | Choose A | Choose B |
|---|---|---|
| Unfinished pages exist | Move to another file before publishing. | Risk: all webpages publish. |
| Audience scope (Org/Enterprise) | Internal-only for employees. | Public web for external visitors. |
| Domain | Use figma.site for speed. | Custom domain for brand (extra setup). |
| Release discipline | Preview + fix issues before publish. | Publish fast only for true drafts. |
8) Guardrails, proof & practice
Sites is real publishing. Guardrails focus on accidental pages, stale updates, and beta constraints.
Do / Don’t & pitfalls
- Do: Preview across breakpoints before every publish.
- Do: Complete settings before publishing.
- Do: Split unfinished pages into another file.
- Don’t: Don’t expect code export for external hosting.
- Don’t: Don’t expect the figma.site subdomain to be changeable.
- Don’t: Don’t assume edits go live without publishing an update.
Common mistakes
Mistake: Accidental pages shipped
Avoid: Everything on canvas publishes—separate files.
Mistake: Stale live site
Avoid: Publish an update after edits.
Mistake: Ignoring issues
Avoid: Fix critical issues and retest preview.
Mistake: Wrong access scope
Avoid: Choose public vs internal intentionally.
Mistake: Domain confusion
Avoid: Custom domain optional; subdomain is fixed once assigned.
What good looks like
- Only intended pages publish.
- Preview matches live behavior.
- Updates follow a release routine.
Checklist: pre-check
- All pages ready (or moved out).
- Title/URL decided.
- Settings reviewed.
- Preview tested at breakpoints.
- Issues checked.
Checklist: post-check
- Live URL loads correctly.
- Changes appear only after update publish.
- Access scope correct.
- No unfinished pages live.
- Rollback plan noted (republish previous version if needed).
Practice lab (5–15 min)
- Create a Sites file from a template.
- Add/rename one webpage.
- Preview and toggle 3 breakpoints.
- Open Publish modal and review Issues.
- Publish once, then make a small change and publish an update.
Expected result: A tiny site you can preview and publish/update intentionally.
Verify you did it right
- Preview works at breakpoints.
- Publish modal shows correct status.
- Live URL updates only after publish/update.
Official docs links
- Publish, update, or unpublish a site — Publish modal, issues, access, unpublish, republish previous version.
- Explore Figma Sites — Preview shortcuts and basics.
- Review and update your site settings — SEO, password, cookie consent, previews.
- Manage a custom domain for your site — Domain setup.
Docs sources: Figma Learn Help Center → Figma Sites Beta category and publish/preview articles (open beta notes, publish states, breakpoints, settings, domains).
