Organize Figma Frames for Desktop, Tablet and Mobile Client Previews

A clear device-preview workflow starts in the design file. Separate desktop, tablet and mobile frames help clients understand how the same page changes across widths. Swelik can present those exported designs under one project, but it does not generate the missing layouts from a single desktop frame.

Use this guide to organize the source frames, map them to the correct preview targets and describe the review scope. The aim is consistency between what the designer prepared and what the client believes they are approving.

Choose one page or review unit

Begin with a focused review unit, such as the homepage or a service page. The device slots should represent the corresponding layouts of that unit. Putting a homepage desktop frame beside a contact-page mobile frame can confuse the comparison even if both exports are valid.

If several pages need independent decisions, organize them deliberately in your project structure and client instructions. Do not use the tablet slot merely as an extra storage location for an unrelated screen.

State the visitor task that connects the designs. For example, all three layouts might help someone understand a service and request a quote. That common task gives the client a reason to compare the layouts beyond their visual differences.

Use frame names that survive the import picker

Name frames with the page, device and revision. A pattern such as “Homepage / Mobile / Review 3” is easier to identify than several frames named “Final.” Keep the names short enough to scan and distinct enough to avoid selecting the wrong export.

Place review frames where the import picker can find them. The current picker reads supported frames at the requested document depth rather than every nested layer. A top-level review frame is a practical choice when it fits your design workflow.

Keep internal explorations separate from the frames intended for client review. You do not need to delete useful design work; you need a clear way to identify the approved review set. Avoid exporting an entire workspace simply because it contains the frame you want.

Align content and revision scope

Check that key facts, service names and calls to action agree across the layouts. A responsive design can reorder content, but it should not accidentally describe a different offer on mobile. Identify any intentional differences and explain why they exist.

Review the revision of each frame. If desktop has been updated but mobile is still pending, record that status. Do not present the pair as a completed synchronized revision merely because their filenames share the same date.

Use real or clearly marked provisional content. Long headings, translated labels or larger product names can affect the layout. A review based only on short sample text may miss the constraints the implementation will face later.

Map the frames to Swelik device targets

Create the initial preview using the desktop design. Save the private management link. From management, add a mobile or tablet layout through the device upload controls or use Update from Figma and select the corresponding device target.

Choose the source frame and target together. A mobile frame imported into the desktop target remains the desktop entry from the project's perspective. The importer cannot reliably infer your intent from the visual dimensions or frame name alone.

Open the public preview after each addition and inspect the relevant tab. Tabs appear for layouts that have been added. A missing tablet tab may simply mean no tablet design has been supplied, rather than a failed automatic conversion.

Explain what device previews prove

Separate static device frames demonstrate your intended layouts at those widths. They do not prove that the future website behaves correctly at every intermediate width or that navigation and forms work. Keep those checks in the implementation review.

A fit-width image is also not a responsive layout generator. Scaling preserves the arrangement within the image. It does not change columns, navigation or reading order. Use an actual narrow-layout frame when reviewing the mobile design.

The responsive presentation guide gives a sequence for showing these differences to clients. Start with the device that best reflects the project's main use case, then explain the other layouts in relation to the same task.

Update one device without losing context

When only mobile changes, update the mobile target and tell the client what changed. Keep the shared public destination stable, but identify the revision and device in the accompanying message.

Check the remaining layouts before asking for project-wide approval. A review status should not silently imply that an unseen or outdated layout was approved. List the included designs and any outstanding work in the request.

Use the same-link Figma update guide for the replacement steps. Maintain a simple revision record so earlier comments can be understood even after a section moves or a frame is replaced.

Keep a small pre-share checklist

Confirm the page identity, device target, source frame and revision. Check the exported content at the top and bottom of the page. Verify that the public tab shows the intended design and that provisional content is identified in the review message.

Then confirm that the link you are sending is public, not the management URL. Include the decision required and the layouts it covers. A well-organized frame set still needs a clear review request to produce useful feedback.

Frequently asked questions

Does Swelik create mobile layouts from my Figma desktop frame?

No. Prepare each layout in Figma and import it into the matching device target. The preview presents the supplied designs; it does not redesign them.

Must every project include tablet?

No. Add the layouts needed to explain the design and resolve the review questions. An intermediate layout is useful when it communicates a meaningful change that desktop and mobile alone do not show.

Can I mix Figma imports and uploaded PDFs?

Yes, the device workflow accepts supported designs through its available upload and import controls. Keep the source revision and device mapping consistent regardless of how the artifact was prepared.