Collaboration and Handoff Basics in Figma: Comments, Versioning, and Share Settings

Why collaboration and handoff matter in day-to-day UX work

In most teams, a Figma file is not just a design artifact—it is a shared workspace where stakeholders review, teammates edit, and developers extract specs. Collaboration and handoff basics help you: (1) control who can see or change the file, (2) collect feedback in a trackable way, (3) preserve milestones with version history, and (4) prepare a file so others can understand it quickly without a meeting.

Sharing permissions and link settings (what to choose and when)

Permission levels: view vs edit

When you share a file, you’re deciding whether someone can only review or can change the source of truth.

• Can view: Best for stakeholders, clients, and most developers. They can inspect and comment (if allowed) but cannot alter the design.
• Can edit: Best for design collaborators who will actively modify layouts, components, or styles. Use sparingly to avoid accidental changes.

Link access: who can open the URL

Link settings control how widely a file can be accessed. Typical options include restricting to invited people, to your organization/team, or allowing anyone with the link. Choose the narrowest setting that still supports the workflow.

Practical steps: share a file safely

1. Click Share (top-right in the file).
2. Under Invite, add emails for key collaborators.
3. Set each person to Can view or Can edit.
4. Open Link access and choose the narrowest option that still works.
5. Confirm whether commenting is allowed for viewers (recommended for review).
6. Copy the link and paste it into your team channel with context: what to review, by when, and what kind of feedback you need.

Commenting etiquette: getting useful feedback (and avoiding noise)

What a good comment looks like

High-quality comments are specific, actionable, and anchored to the right element. Encourage reviewers to include:

• Context: what they were trying to do or understand.
• Observation: what they saw (e.g., “This label is unclear”).
• Request: what change they want (or a question if unsure).
• Priority: must-have vs nice-to-have.

Example comment templates you can paste into a review request:

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

[Context] On the checkout screen…
[Issue] The shipping method options feel easy to miss.
[Request] Can we increase visual hierarchy (heading + spacing)?
[Priority] Must-have for stakeholder review.

Where and how to place comments

• Attach comments to the smallest relevant target (a button, label, or component), not the entire frame, unless the feedback is about the whole screen.
• Use one comment thread per topic. Don’t bundle unrelated issues into one thread.
• If feedback repeats across screens, comment once and reference the pattern: “Applies to all settings screens.”

Resolving feedback without losing decisions

When you act on a comment, reply with what changed and why, then resolve it. This keeps the file readable and creates an audit trail.

• Reply before resolving: “Updated spacing to 16px and increased heading weight for hierarchy.”
• Ask clarifying questions when needed: “Do you mean the primary CTA should be ‘Continue’ instead of ‘Pay now’?”
• Don’t resolve prematurely: If you’re waiting on a decision, leave it open and tag the decision-maker.

Version history: saving milestones you can return to

Concept: versions as safety nets and review anchors

Version history lets you view and restore earlier states of the file. In real workflows, you use named versions to mark milestones so you can:

• Compare “before vs after” during reviews.
• Undo risky refactors without panic.
• Freeze a stakeholder review baseline while continuing exploration.

Recommended milestones to name

• Before refactor: right before reorganizing components, renaming styles, or restructuring pages.
• Before stakeholder review: the exact prototype you want reviewed.
• Post-review updates: after incorporating feedback, so the team can track what changed.

Practical steps: create a named version

1. Open the file menu (Figma main menu) and go to Version history.
2. Choose Create named version (wording may vary slightly).
3. Use a label that includes purpose + date, for example: Stakeholder Review v1 — 2026-01-20.
4. Add a short description: what’s included, what’s excluded, and any known open questions.

Preparing a file for handoff: make it understandable without you

Page structure: separate work-in-progress from handoff-ready

A clean page structure prevents developers and stakeholders from landing in unfinished explorations.

• Create (or maintain) a handoff page that contains only the latest approved screens and components.
• Keep exploration on separate pages (e.g., “WIP”, “Explorations”, “Archive”).
• Order pages top-to-bottom in the sequence others will use: Cover/Index → Handoff → Prototype → Archive.

Component organization: predictable locations and naming

Even if your team already has components, handoff improves when others can find them quickly.

• Keep reusable components in a dedicated area or page (e.g., “Components”).
• Use consistent naming patterns (e.g., Button / Primary, Input / Default).
• Avoid duplicates: if two components look the same but behave differently, clarify with names (e.g., Button / Primary / Loading).

Style usage: reduce one-off values

Developers can implement faster when the file uses consistent styles instead of scattered custom values.

• Use text and color styles wherever possible.
• Minimize “almost the same” values (e.g., multiple grays that differ by 1–2%).
• If a one-off is truly needed, add a note explaining why it’s an exception.

Developer notes: what to annotate

Figma is visual, but developers often need intent and edge cases. Add lightweight notes near relevant screens (or in a dedicated “Notes” section) covering:

• States: empty, loading, error, success.
• Behavior: validation rules, disabled conditions, character limits.
• Content rules: truncation, wrapping, localization considerations.
• Data assumptions: what’s real vs placeholder.

Example note block you can copy:

Dev Notes (Checkout)
- Promo code: show error state if invalid; keep user input.
- Address line 2 optional; hide if empty in summary.
- Button disabled until required fields valid.
- Long product names wrap to 2 lines then truncate.

Structured scenario: simulated collaboration from invite to review version

Scenario setup

You are preparing a prototype for stakeholder review. You want a teammate to check UI consistency and a PM to confirm copy. You will: invite a collaborator, request changes via comments, respond with updates, and save a named version for review.

Step 1 — Invite a collaborator (simulated)

1. Click Share.
2. Invite teammate.designer@company.com with Can edit.
3. Invite pm@company.com with Can view and ensure commenting is enabled.
4. Set link access to Only invited people (or org-only if your process requires it).
5. Send a message with scope: “Please review the onboarding flow screens for hierarchy + copy clarity. Comment directly on elements. Deadline: Thursday 3pm.”

Step 2 — Add comments requesting changes

Switch to comment mode and place comments on specific elements. Example threads:

• On primary CTA button: “Request: confirm button label. Should this be ‘Continue’ or ‘Next’? Priority: must-have.”
• On form field group: “Request: spacing feels tight between fields. Can we align to our spacing system and increase group separation?”
• On error message component: “Request: add error state example for invalid email. Priority: nice-to-have for review, must-have for dev handoff.”

Step 3 — Respond with updates (model the workflow)

1. Make the requested design changes.
2. Reply in each comment thread with a short changelog: “Updated CTA label to ‘Continue’ per PM; increased field group spacing; added email error state example.”
3. If you disagree or need a decision, reply with options: “Two label options: ‘Continue’ (generic) vs ‘Create account’ (specific). Which do we want for stakeholders?”
4. Resolve threads that are complete; leave decision threads open.

Step 4 — Create a saved version labeled for review

1. Open Version history.
2. Create a named version: Stakeholder Review — Onboarding Prototype v1.
3. Description example: “Includes onboarding flow screens + error state for email. Excludes password reset flow. Open question: final CTA label on step 3.”

Readiness checklist for stakeholder review prototypes

• Screens are clean: no overlapping drafts, no stray elements off-canvas, no duplicated frames that confuse reviewers.
• Clear flow: starting point is obvious; the main path is easy to follow; dead ends are removed or explained.
• Minimal distractions: hide experimental variants not meant for review; keep only what stakeholders should evaluate.
• Consistent UI kit usage: components and styles are applied consistently; no random one-off colors/typography.
• Key states represented: at least one example of empty/loading/error if it affects stakeholder understanding.
• Comments are under control: resolved threads are cleared; open threads represent real decisions needed.
• Permissions are correct: stakeholders have view/comment access; only collaborators have edit access.
• Named version saved: a review baseline exists so you can keep iterating without losing what was reviewed.