Share with users and colleagues

Two channels, two audiences. Send a Play URL to anyone outside your team — stakeholders, user-testing participants, leadership — and they click through with no sign-in. Invite teammates into the workspace itself and you get live cursors, inline comments on real components, and a shared editing surface.

Send a Play URL (the public path)

Play is the public, read-only viewer for a Statecraft prototype. Click the Play button in the toolbar and Statecraft opens the prototype in a fresh browser window — no editor chrome, no sign-in wall. The URL in the address bar is shareable as-is.

The right fit when you want to:

• Run user testing. Send the participant a URL, watch them click through, learn where the flow breaks down. Works in any browser; no account needed.
• Preview to stakeholders. Leadership, customers, partners — anyone you want to look at the design without picking up an editor account.
• Get async sign-off. Drop the link in Slack or email with a question; the reviewer clicks through and replies in the thread.

Comments aren't available in Play (it's read-only on purpose). For "leave a comment on this specific button" feedback, invite the reviewer to the workspace instead. For the deep detail on Play URLs — what's public, what's private, the URL shape — see Play mode.

Invite to the workspace (the collaborator path)

Workspaces are how collaborators work together in Statecraft. Open Workspace → Members and add the reviewer's email. They sign in (or sign up) and can open every project in the workspace from then on.

Three roles, with different permissions:

• Owners can do everything — edit projects, invite members, manage billing.
• Editors can edit projects and post comments. The right role for a design partner, a PM, an engineer who wants to fix a layout in your prototype.
• Viewers can read every project and every comment thread, but can't post comments or edit anything. For a one-off read-only review, a Play URL is usually simpler.

There is no per-project share link — the workspace is the unit of access. If you want someone to see one project but not others, put that project in its own workspace and invite them there.

The feedback round

Once the reviewer is in the workspace, the typical loop:

1. You save a snapshot of the version you want them to see.
2. The reviewer opens the project and switches to that snapshot.
3. They click any element to leave a comment on it.
4. You get a notification, reply, mark resolved.

The round happens on a frozen version the reviewer is looking at — they can't accidentally see your in-progress edits, and their comments don't drift onto a different design as you keep working.

Save a snapshot

Open the version-history dropdown in the toolbar (the clock icon) and click Save snapshot. The snapshot is created instantly with a timestamp label. Double-click the row in the dropdown if you want to give it a more descriptive name like "v1 for design review".

Snapshots are immutable. Once saved, the snapshot keeps showing the same prototype even as you keep editing the live project. Save a snapshot before each review round and the reviewer always sees the version you intended.

Save as many as you want. The dropdown lists them most-recent first; reviewers can switch between them to compare versions.

Comments on real components

Any element on the canvas can carry a comment. The reviewer clicks the element they want to feedback on, types their comment, and posts it — the comment attaches to the actual component (the <Button> with that data-pid), not to a coordinate on a frozen image.

Threads stay on the snapshot they were left on. If you save a new snapshot, comments on the old one don't follow — they belong to the version that was being reviewed. That's deliberate: a comment like "this button colour is wrong" needs to point at the button as it was when the comment was made, not the redesigned one you've shipped since.

Notifications

When a reviewer leaves a comment, every editor and owner of the workspace gets:

• An in-app notification. The bell in the top nav shows unread count and opens a list of recent activity.
• An email. Sent from statecraft@statecraftapp.com with the comment text and a deep-link back to the snapshot.

Reply from inside the editor. The reviewer who started the thread gets a notification on every reply. Mark a thread resolved to close it without deleting the discussion, or use the Mark all comments as resolved action at the bottom of the version-history dropdown to clear them all in one go.

What's next

Want every state of the feature in the review, not just the happy path? Show every state before the next snapshot. For the under-the-hood detail of how snapshots, comments, and Play mode work, see Snapshots & version history, Comments & feedback, and Play mode.