Prepare one flow for review

Choose the decision the review should settle

Start with a brief that fits in a sentence: can a reviewer move from a list to the right detail, understand the next action, or finish an edit? Avoid making your first preview an entire product tour.

Prepare realistic text lengths and one less-than-perfect state. For a client review, use content you are authorized to share. Keep confidential production information out of a public example; do not loosen file access simply to remove a sign-in screen.

Set a flow and check its starting point

Figma describes flows as connected frames on a page and lets you share a link to a flow starting point. Its prototype presentation can be played by viewers with the appropriate access. Choose the flow you intend to review, then test the first screen and its first interaction in Figma.

Copy the prototype link, then check the audience

Figma’s documented workflow is to open presentation view, use Share prototype, review the settings, and copy the link. A link from the design editor can point to a selected frame instead. Prototype-only sharing and source-file access depend on the plan and sharing configuration, so a prototype URL is not a guarantee that the source file is hidden.

Embedded files retain Figma’s access rules. Organization access can require login and protected files can require a password. Do not treat the browser wrapper as an alternative permission system.

Check the plan as well as the link: Figma documents prototype-only sharing for paid plans. On Starter, a viewer of a shared prototype can still open the original file in the editor. Sending a prototype URL alone does not establish source-file confidentiality.

Check as the person who will attend the review

Open the original link using the same kind of account and browser context as your reviewer. Confirm the expected starting screen, the next action and the restart behavior. Your signed-in owner view alone is not a useful access test.

Record whether the reviewer needs an account, an invitation or a password. Deliver those access instructions through the agreed channel; do not place passwords, client links or file contents in a public tutorial or analytics event.

Test with the intended recipient’s actual access, including whether they can open the source file. Do not make confidential client work public just to load a preview. An embed continues to respect Figma’s file, password and organization restrictions.

Distinguish the prototype layout from the device view

Figma exposes separate prototype scaling and content-scaling options. It also distinguishes the node shown on initial load from the node used when the flow restarts. These are provider settings; changing a device camera does not establish that the embedded design is responsive.

The Embed API has its own client-id requirement, separate from a basic embed. This guide does not claim that all API controls are enabled in Plurigent.

The outer scaling=contain choice and content-scaling=responsive parameter solve different display problems. Neither turns a fixed artboard into a native adaptive app. Review the actual flow and viewer settings rather than treating the URL parameters as a compatibility guarantee.

Know which settings the current product actually keeps

The current Plurigent source parser keeps the starting-node and version identifiers when valid, but uses its own prototype presentation presets: no Figma device frame, scaling set to contain, and responsive content scaling. Changing scaling in the incoming link is not currently a separate product setting.

Use the original Figma presentation when you need to compare other provider settings. These values describe Plurigent’s configuration, not proof that a particular file responds correctly or that external content has loaded.

Use a small comparison in the Online Simulator

First open the built-in example and use Fit to see the whole device. Then submit your authorized prototype address in the single-line design input. Check that the expected design actually appears before discussing the device presentation.

Compare one layout question at a time using the same starting screen. If the prototype itself keeps a fixed composition, do not describe changing the device pose as an adaptive-layout test. Adjust the original design or provider presentation settings, then repeat the comparison.

After the review, return to the original Figma file for edits. Keep the review decision, proposed change and remaining implementation question together so a polished preview does not replace the rationale.

The desktop workspace starts at 100%; a narrow first view uses Fit. After choosing a zoom level, change posture without expecting the tool to reset it. Use the visible workspace exit/enter control when you need to return to the surrounding page; a local preview still does not verify Figma access for another recipient.

Locate the problem before changing the design

Use the table to decide what to check next. It is a troubleshooting sequence, not an automated diagnosis of the provider or your browser.

Leave a useful review note

Write down the task, the starting screen, the visible issue and the change you propose. Add the configuration you compared and who still needs to verify the behavior. This is a more useful handoff than an unexplained screenshot.

Keep the prototype address in your team’s approved workspace, not in this public resource browser. Scene JSON is not a backup of your Figma design, login session or recording. Confirm native system behavior in the relevant development environment.