How to Create Mock Screenshots for SaaS Applications

A static design file is usually the fastest way to make a polished mock screenshot of a SaaS application. Choose an interactive prototype when the image needs to show a flow or changing state. In either case, use the product’s real visual language, put in plausible sample content, and preview the result at the size where it will be published.

This guide covers the design workflow, when a prototype or backend is useful, how to check the exported image, and how to capture a live reference. For official Figma capabilities referenced below, see its documentation on design files, prototyping, Figma Make, backend services, and previewing and sharing prototypes.

1. Decide what the screenshot needs to communicate

Start with the message, not the tool. Identify the feature or workflow the image should explain, the audience, and where the image will appear. A hero image, a feature callout, and a mobile product announcement may need different compositions and dimensions.

One screen or feature: use a static design when the goal is a carefully controlled image, such as a dashboard hero or a feature announcement.
A flow or changing state: use a prototype when a reviewer needs to click through screens, see a state change, or understand navigation.
A working demonstration: consider backend behavior only when the experience needs real persistence, authentication, form submissions, saved content, or server requests.

Figma documents design files for responsive and interactive designs and assets, and its prototyping tools support no-code interactive experiences across screen sizes. These are capability descriptions, not a claim that any particular route will produce a more realistic result.

2. Choose a starting point

Start from a design file for a controlled still image

Create a blank file or use an existing product design system. This gives you direct control over layout, typography, colors, and reusable components. It is a good fit when the deliverable is an exported image and nobody needs to interact with it.

Use a prototype to show a flow

Build connected screens and define the interactions that matter. Keep the flow narrow: include only the steps needed to communicate the feature. Preview the path from its starting screen so a viewer can understand the state changes in context.

Use a prompt-based start to explore ideas

Figma Make describes generating mockups or prototypes from a prompt and using an existing design system as a starting point. Treat the generated result as a draft. Review and refine component choices, hierarchy, terminology, spacing, and content against the intended product rather than presenting the first output as authoritative.

3. Make the interface feel specific to the product

A convincing mockup communicates a particular product rather than a generic dashboard. Align the most visible choices with the application it represents:

Use real product terminology. Name navigation items, actions, and features the way the product does.
Follow the visual system. Reuse the product’s colors, typography, spacing, buttons, and component shapes when available.
Show a clear hierarchy. Make the primary task or feature obvious; reduce unrelated panels and decorative detail.
Use plausible sample content. Choose believable names, dates, values, and status labels. Keep the content internally consistent across the screen.
Represent a useful state. Consider whether the screen should show first use, populated data, success, empty state, or an error. Pick the state that supports the message.
Review small details. Check alignment, text wrapping, contrast, clipped controls, and whether the visible data fits the labels.

These are practical design recommendations: design-system reuse and iterative refinement are supported workflows, but they do not guarantee that generated content will match a real application.

4. Decide whether the mock needs data or a backend

For a static image, place sample content directly in the design. A backend adds setup and is relevant when the demonstration needs persistent state, authentication, user input, saved content, or server requests. Do not add live data connections just to make a still screenshot look populated.

If a prototype does use a backend, keep API keys and tokens in the tool’s secret interface. Do not put secrets in prompts, visible sample text, or shareable screenshots. Use non-sensitive demo data where possible and check what the preview exposes before sharing.

5. Preview and export at the intended dimensions

Set the frame or preview to the dimensions of its destination. Check the desktop layout for a desktop page and a mobile-sized preview for a mobile placement.
Inspect the full screen, then inspect the crop that will actually be shown. Confirm that the important feature remains visible at that crop.
For a prototype, preview the interaction path and confirm the starting point and sharing permissions.
Export the frame in an image format supported by the destination. Keep a source design file so you can revise the mock later.
Open the exported asset separately and verify its dimensions, sharpness, and crop before publishing.

Figma documents fullscreen and mobile previews and sharing controls for functional prototypes. Confirm preview access permissions before distributing a prototype link.

6. Be clear that a concept is a concept

If the screen contains fabricated sample data or depicts a proposed feature, label it as a mockup or concept in the surrounding page, caption, or presentation. This helps viewers distinguish an illustrative design from a current live interface.

7. Capture a live page as a visual reference

If you need a screenshot of an existing SaaS page to compare with your mockup, a browser capture can provide a reference. With a local Playwright setup, install the package and Chromium, then save this as capture.mjs:

import { chromium } from 'playwright';

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage({
  viewport: { width: 1440, height: 1000 },
  deviceScaleFactor: 1,
});

try {
  await page.goto('https://example.com', {
    waitUntil: 'networkidle',
    timeout: 60000,
  });
  await page.screenshot({ path: 'reference.png', fullPage: true });
} finally {
  await browser.close();
}

Install with npm install playwright and npx playwright install chromium, then run node capture.mjs. Replace the example URL with a page you are authorized to access. This captures a rendered page; it does not create a fabricated mockup. For a static concept image, a design file is still the direct route.

Capture options to consider

viewport sets the browser viewport and therefore the responsive layout you see.
deviceScaleFactor controls pixel density; use a higher value when you need a sharper raster output.
fullPage: true captures the full document height instead of just the viewport.
For a specific element, use a locator and call locator.screenshot({ path: 'element.png' }).
If the page loads content late, wait for a meaningful selector with page.locator('main').waitFor() or use a short explicit delay. Network-idle waits can be unsuitable for pages with continuous network activity.

Use a test account for authenticated pages and keep credentials out of source control. Pages may render differently because of access checks, dynamic content, consent banners, or viewport-specific behavior. Respect the site’s access rules and avoid capturing private user data.

8. Troubleshooting

Symptom	Likely cause	What to do
The mock looks generic	It uses default labels, generic components, or inconsistent styling.	Apply the product’s terminology and design system; replace filler with plausible, consistent content.
Important content is cut off	The frame or crop does not match the publication placement.	Preview at the target dimensions and adjust the composition or crop.
The generated screen has incorrect details	A prompt-based first pass is being treated as final.	Iterate and manually review hierarchy, text, component states, and visual styles.
A prototype link cannot be opened	Its sharing permissions or starting point may not be set for the viewer.	Review prototype access and test the share link with the intended audience.
Browser capture times out	The page is slow, requires access, or never reaches network idle.	Check the URL and access, increase the timeout if appropriate, and wait for a specific page element instead of network idle.
Screenshot is blank or incomplete	Capture began before the main content rendered, or the page blocks automated access.	Wait for a meaningful selector, check the page manually, and use an authorized session if required.
Text or controls look blurry	The export is displayed larger than its source dimensions or uses a low pixel density.	Export at an appropriate size and inspect the actual output dimensions before placing it.
Live content changes between captures	The page includes dynamic data, animation, or time-dependent content.	Use a stable state or a design-file mock when exact repeatability matters.

9. Performance, reliability, and cost

A static design file has no runtime dependency on a backend for its screenshot; an interactive prototype needs more setup because it represents behavior. A live browser capture also depends on the destination page loading successfully, and dynamic pages can vary between captures. Preview and export a stable state when repeatability matters.

Keep the implementation proportional to the deliverable. For a single still image, manually placed sample content avoids unnecessary data connections. For repeated live-page captures, reuse browser setup carefully and set explicit timeouts and viewport dimensions. Consider what data and access credentials the capture process can reach.

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It is useful when the deliverable is a screenshot of a live page rather than a designed concept. A single GET request returns PNG, JPEG, WebP, or PDF; its options include full-page capture, element selection, viewport and device presets, custom CSS and JavaScript, waits, and caching. See the ScreenshotNeo site for the service overview.

Or skip the browser setup

For a live reference screenshot, call the API with your access key and target URL. See the ScreenshotNeo API documentation for the available parameters.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Replace the example target URL as needed. Keep the API key private. ScreenshotNeo accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 shots monthly with no card; paid plans start at $5 for 3,000 shots. Sign up for 1,000 free screenshots a month with no card.

FAQ

What is the difference between a mockup, wireframe, and prototype?

A wireframe sketches structure, a mockup presents a more finished visual design, and a prototype connects screens or interactions to demonstrate behavior. A screenshot is a static image, even when it comes from a prototype preview.

Can I create a mock screenshot without a backend?

Yes. A static design can use sample content placed directly in the file. Add backend behavior only when the demonstration needs state, authentication, saved content, input, or server requests.

Should I use AI to generate the mockup?

A prompt-based workflow can give you a starting point and may use an existing design system. Review and refine the result to match the product and the intended screen state.

How do I make the screenshot suitable for mobile?

Preview at mobile dimensions and compose for the narrow viewport. Do not assume a desktop crop will show the same hierarchy or keep the important feature visible.