How to Create a Product Demo with Screenshots on Mac (No Video Required)

Why screenshots beat video for most product demos

Video demos seem like the obvious choice for showing off a product. But they come with costs that most teams underestimate. A 3-minute screen recording takes 30 minutes to produce if you include scripting, recording clean takes, and basic editing. When the UI changes — a button moves, a label changes, a new step gets added — you re-record the whole thing. And videos are opaque to search engines, screen readers, and anyone on a slow connection.

Screenshot-based demos sidestep all of these problems. Each step is an annotated screenshot with a short text description. The whole demo loads instantly, works on any device, is accessible by default, and updating a single step means replacing one image. No re-recording, no re-editing, no re-exporting.

This format has quietly become the standard for help centers, onboarding flows, and internal documentation. Tools like Scribe, Supademo, and Storylane have built businesses around it. But you don't need specialized tools — you can build effective screenshot demos with Mac's built-in capture tools and any document or web editor.

Planning your screenshot demo

A good demo tells a story: the user starts somewhere, takes a series of actions, and ends up with a result. Before you capture anything, map out that story.

Define the scope

Decide exactly what the demo will show. A common mistake is trying to cover the entire product in one demo. Instead, focus on one workflow. "How to create your first project" is a demo. "How to use our project management tool" is a product tour — break it into multiple demos.

List every step

Walk through the workflow yourself and write down every click, every page transition, every form field. Be specific:

• Click "New Project" in the top-right corner
• Enter a project name in the Name field
• Select a template from the dropdown
• Click "Create"
• The project dashboard appears with the template applied

Each step becomes one screenshot. If you find yourself needing two annotations on a single screenshot to explain two different actions, split it into two steps.

Decide what to show vs. what to describe

Not every step needs a screenshot. "Log in to your account" doesn't need a screenshot of the login page unless the login flow is unusual. "Click Settings in the sidebar" might not need a screenshot if the sidebar is visible in the previous step. Use text-only steps for actions that are self-explanatory, and save screenshots for steps where the user needs to see the interface to know what to do.

Capturing screenshots for demos

Consistency is everything in a screenshot demo. If each screenshot has a different browser width, different test data, or a different zoom level, the demo looks sloppy and the user has to mentally re-orient with each step.

Set up your capture environment

Browser width. Pick a width and lock it in. 1280px is a good standard — it's wide enough to show most web UIs without horizontal scrolling, and narrow enough that the screenshots look good on mobile screens. In Chrome, open DevTools (Cmd+Option+I), click the device toolbar (Cmd+Shift+M), and set a custom width.

Test data. Use realistic-looking data. "Test Project 1" and "john@example.com" make your demo look like a placeholder. Use names, dates, and values that look like real data: "Q2 Marketing Campaign", "sarah.chen@company.com", "$12,450".

Clean state. Clear notifications, close unrelated tabs, hide browser bookmarks bar (Cmd+Shift+B in Chrome). The audience should see your product, not your browser setup.

Capture technique

Use region capture (Cmd+Shift+4) for most steps. Capture just the browser viewport — no browser chrome, no URL bar, no bookmark bar — unless the URL or browser UI is part of the step.

For full-page captures that scroll, use Chrome DevTools: open the command menu (Cmd+Shift+P), type "Capture full size screenshot", and press Enter. DevTools renders the entire page and saves it as a PNG.

Save screenshots with descriptive filenames that reflect the step order:

demo-onboarding/
  01-dashboard-click-new-project.png
  02-project-name-field.png
  03-template-dropdown.png
  04-click-create.png
  05-project-dashboard-result.png

Sequential numbering makes it easy to see the flow at a glance and insert new steps later (01, 01a, 02, ...).

Annotating screenshots for clarity

A screenshot without annotation is just a picture of your app. The annotation is what turns it into an instruction. The user needs to know where to look and what to do.

Highlight the action area

Every demo screenshot should draw attention to one spot: the button to click, the field to fill in, the menu to open. Use one of these annotation patterns:

• Numbered circle. A small circle with a step number (e.g., "1", "2") placed next to the action target. Best for steps with multiple actions.
• Arrow. A colored arrow pointing to the target element. Simple and clear. Best for single-action steps.
• Highlight box. A semi-transparent colored rectangle overlaid on the target area. Good for drawing attention to a region rather than a single element.
• Dim everything else. Darken or blur the entire screenshot except the action area. High contrast, but time-consuming to produce for every step.

Write concise step text

Each step gets one sentence. Start with a verb. Tell the user what to do, not what the interface looks like.

• Good: "Click New Project in the top-right corner."
• Bad: "You'll see a blue button labeled New Project in the top right area of the dashboard next to your avatar."

If the step has a result the user should verify, add it: "Click Create. The project dashboard appears with your template applied."

Annotation style guide

Pick one annotation style and stick with it across the entire demo. If you use red arrows in step 1 and blue circles in step 5, the demo looks inconsistent. Establish these rules before you start annotating:

Assembling the demo

Once your annotated screenshots are ready, you need a format to present them. The right choice depends on where the demo will live.

Option 1: Document-based demo (Google Docs, Notion, Confluence)

The simplest format. Paste each annotated screenshot into a document with the step text below it. This works well for internal demos, onboarding docs, and help center articles.

Structure each step consistently:

## Step 3: Select a template

Click the **Template** dropdown and choose the template
that matches your project type.

[Screenshot with template dropdown highlighted]

In Notion, use the toggle block to let users expand steps they need help with and collapse ones they don't. In Google Docs, use numbered headings for automatic table-of-contents generation.

Option 2: Slide-based demo (Keynote, PowerPoint, Google Slides)

One step per slide, with the screenshot taking up most of the slide and the step text as a caption or title. This format works well for sales demos, onboarding presentations, and training sessions. You control the pacing by clicking through slides.

Keep the layout simple: screenshot centered or left-aligned at 60–70% of the slide width, step text to the right or below. Use the same slide layout for every step so the audience knows where to look.

Option 3: Web-based interactive demo

For public-facing demos on your website or product page, build a simple click-through experience. Each step is a screenshot with a hotspot on the action area. When the user clicks the hotspot, the next step appears.

You can build this with basic HTML and CSS:

<div class="demo-step" id="step-1">
  <img src="step-01.png" alt="Dashboard with New Project button highlighted">
  <p class="demo-caption">Click <strong>New Project</strong> to get started.</p>
  <button onclick="showStep(2)">Next &rarr;</button>
</div>

Or use a static site generator to build a more polished version with transitions between steps, a progress bar, and keyboard navigation.

Option 4: PDF export

For demos that need to be emailed or viewed offline, export your document or slides to PDF. PDF preserves the layout and image quality regardless of the viewer's device or software. It's also the best format for demos that need to be printed — for example, quick reference cards posted near workstations.

Screenshot demos vs. video demos: when to use each

Screenshot demos aren't always the right choice. Here's when each format wins:

Use video when the demo involves drag-and-drop interactions, complex mouse gestures, or animated transitions that screenshots can't capture. Also use video for marketing content where the goal is emotional engagement rather than step-by-step instruction.

Use screenshots for everything else. Help center articles, user onboarding, internal training, SOPs, knowledge base entries, and product documentation are all better served by screenshot demos. They're faster to create, faster to consume, and faster to maintain.

Keeping demos up to date

The hardest part of screenshot demos isn't creating them — it's maintaining them. A demo with outdated screenshots is worse than no demo at all, because it teaches users to distrust your documentation.

Create a capture checklist

For each demo, maintain a capture checklist that documents the exact conditions for every screenshot:

• Browser and viewport width
• URL for each step
• Test account credentials
• Test data that should be visible
• Any feature flags or settings that need to be enabled

When a UI change ships, re-run the checklist to recapture only the affected steps. The checklist ensures consistency even when different people update the demo over time.

Version your screenshots

Store demo screenshots in version control alongside your documentation. When you update a screenshot, the diff shows exactly what changed. Use the naming convention demo-name/step-NN-description.png so files sort naturally and are easy to find.

Automate recapture when possible

For web applications, you can automate screenshot capture using headless browser tools. Write a script that navigates through the demo flow and captures each step:

# Capture a specific step with Chrome headless
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --headless \
  --screenshot="step-03-template.png" \
  --window-size=1280,800 \
  "https://app.example.com/projects/new"

This won't add annotations, but it gives you the base screenshots. Add annotations manually or with a tool that supports overlays. Run the script after each release to flag screenshots that need updating.

Common mistakes in screenshot demos

Too many steps. If your demo has 40 screenshots to show a 5-minute workflow, you're over-capturing. Combine steps that happen on the same screen and skip steps that are obvious (like clicking a clearly labeled button).

Inconsistent capture sizes. Screenshots at different zoom levels or viewport widths make the demo feel jarring. Set your browser width once and don't change it during the capture session.

Fake-looking data. "Test User", "Lorem Ipsum", and "example@email.com" signal that the demo isn't real. Use realistic data that looks like it belongs in a production environment.

Missing result steps. Don't end the demo on the action. Show the result. If the user clicks "Create", show what happens after they click — the success state, the new page, the confirmation message. This confirms they did it right.

No context for the first screenshot. The first step should orient the user: where are they in the app, and what should they see before they start? A screenshot of a dashboard with a callout saying "From the main dashboard, click New Project" is much clearer than jumping straight to a screenshot of the project creation form.