Sharing for Feedback: Links, Comments, and Stakeholder Handoffs

What “sharing for feedback” means in Adobe XD

Sharing for feedback is the practice of publishing a prototype so others can view it in a browser, interact with it, and respond with comments tied to specific screens and elements. In Adobe XD, this is typically done by creating a share link with a defined purpose (review, development handoff, presentation, etc.), selecting who can access it, and choosing whether stakeholders can comment. The goal is to reduce vague feedback by keeping responses anchored to the exact UI state being discussed.

Key outcomes of a good sharing setup

• Right people, right access: stakeholders can view without editing your source file.
• Feedback in context: comments are attached to a screen and location, not buried in email threads.
• Traceable changes: you can update the shared link while keeping a clear record of what changed and why.

Sharing modes and permissions (choose intentionally)

Before generating a link, decide the intent of the share. Different intents imply different expectations and settings.

Permission patterns you’ll use often

• Anyone with the link: fastest for internal teams; risky for sensitive work.
• Invite only / restricted: better for client work or pre-release features.
• Password protection: useful when you need broad access but still want a basic gate.

Practical rule: if you would hesitate to forward the link to a large mailing list, don’t use “anyone with the link” without a password.

Generate a share link (step-by-step)

Use a repeatable checklist so every share is consistent and review-ready.

Step-by-step: publish a prototype link for review

1. Open the correct flow: confirm you’re sharing the intended user journey (for example, “Checkout flow” rather than the entire file).
2. Open Share: go to the Share workspace/panel.
3. Select share type: choose a review-oriented option (commonly “Design Review”).
4. Name the share clearly: include product, flow, and version, e.g., Mobile Checkout v0.8 (Review).
5. Set access: choose link access level (anyone/invite/password) appropriate to the audience.
6. Enable commenting: turn comments on when you want annotated feedback.
7. Create link: generate the URL and copy it.
8. Send with a review brief: include what you want reviewed, where to start, and the deadline.

Tip: share one flow per link when possible. A single link that contains multiple unrelated paths increases the chance reviewers comment on the wrong screens or miss the intended scenario.

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

Enable commenting and capture feedback in context

Commenting turns the prototype into a shared discussion space. Reviewers can click on a screen, pin a comment to a location, and describe what they see. This is more actionable than general statements like “the form feels confusing.”

How to get higher-quality comments

• Ask for evidence-based feedback: “What did you expect to happen when you tapped Continue?”
• Request a severity label: “Blocker / Important / Nice-to-have.”
• Encourage one issue per comment: prevents mixed threads that are hard to resolve.
• Require reproduction steps for bugs: “From Home > Search > Filter, tap Apply…”

Commenting etiquette you can set in the invite

• Use @mentions (if available) to route questions to the right person (PM, engineer, legal).
• Reply in-thread with decisions: Accepted, Needs discussion, Deferred, Out of scope.
• When you fix something, respond with what changed and where to verify.

Versioning shared prototypes (keep links stable, changes traceable)

Versioning is the discipline of controlling what reviewers are looking at and ensuring you can map feedback to a specific state of the design. Adobe XD lets you update a published link; the URL can remain the same while the content changes. That’s convenient, but it can also create confusion if stakeholders don’t realize the design has moved on.

Two practical versioning strategies

• Stable link, tracked releases: keep one link per flow and update it, but maintain a visible version label in your share name and in your review message (e.g., “Now updated to v0.9”). Best for ongoing collaboration.
• New link per milestone: publish a new link for each major review round (v1, v2). Best when approvals or audits require a frozen reference.

Make changes traceable with a lightweight changelog

Include a short changelog in the message that accompanies the link (or in your team tracker). Keep it scannable:

Changelog (v0.9 → v1.0)  - Updated shipping address validation rules  - Added error state for invalid postal code  - Simplified payment method selection (removed accordion)  - Adjusted CTA copy: “Place order”

This helps reviewers focus on what changed and prevents re-litigating previously settled decisions.

A structured review process you can reuse

Unstructured reviews produce unstructured feedback. Use a consistent process that defines scope, collects comments in context, and turns them into actionable work.

1) Define what feedback you need (be specific)

Write 3–5 targeted questions. Each question should map to a decision you can make.

• Clarity: “Is the delivery date selection understandable without explanation?”
• Completeness: “Are any required fields missing for compliance?”
• Consistency: “Does this match our existing account settings patterns?”
• Risk: “Any legal/privacy concerns with the data shown on this screen?”

Avoid asking “Any thoughts?” because it invites broad opinions and style debates.

2) Share a specific flow (limit scope on purpose)

Tell reviewers exactly where to start and what path to follow. Example review brief you can paste into email or chat:

Review scope: Mobile Checkout (Guest) Start: Cart screen Goal: Place an order with a new shipping address Out of scope: Account creation, promo code edge cases Questions: 1) Is the address form clear and minimal? 2) Are error messages understandable? 3) Is the final confirmation step reassuring? Deadline: Thursday 3pm

This reduces off-topic comments and helps stakeholders test the same scenario.

3) Collect comments (and keep them actionable)

• Ask reviewers to pin comments to the relevant UI element or area.
• Encourage screenshots only when necessary; pinned comments are usually enough.
• If a comment is vague, reply with a clarifying question: “Which step felt unclear—address entry or delivery options?”

4) Triage feedback: must-fix vs future ideas

Not all feedback should be implemented immediately. Triage prevents scope creep and protects timelines.

A simple triage rubric

When you triage, respond in the comment thread with the category and next step. This closes the loop and reduces repeated requests.

5) Update the prototype while keeping changes traceable

After triage, implement changes in batches and publish updates in a controlled way.

Step-by-step: update without losing accountability

1. Create a change list: copy must-fix items into a checklist (issue tracker or document) with owners and due dates.
2. Group related fixes: for example, “Form validation” or “Confirmation screen messaging.”
3. Apply updates: make changes and verify the same flow still works end-to-end.
4. Publish update: update the existing link or publish a new one depending on your versioning strategy.
5. Announce what changed: send the changelog and call out which comments were addressed.
6. Request re-review only where needed: “Please re-check Steps 2–3; other screens unchanged.”

If stakeholders are still commenting on old behavior, explicitly state the version they should be viewing and the date/time of the latest publish.

Stakeholder handoffs: making review links “handoff-ready”

A stakeholder handoff is not just sending a URL—it’s packaging context so decisions can be made quickly. A good handoff message includes scope, decision points, and how to respond.

Handoff checklist (copy/paste)

• Link: (paste URL)
• Flow: what journey this covers
• Audience: who should review (PM, legal, engineering)
• Decisions needed: list 1–3 approvals or choices
• What’s changed since last review: short changelog
• How to comment: pin comments on-screen; one issue per comment
• Deadline: date/time and what happens if no response

For larger groups, consider assigning sections: one person reviews copy, another reviews compliance, another reviews edge cases. This prevents duplicated effort and conflicting direction.