Skip to main content

Demo what you can't capture

Use cases for building demos from screenshots and screen recordings when the product isn't a web app you can capture in Chrome.

Updated Oct 15, 2026

Demo what you can't capture

Overview​

The Chrome extension captures web apps beautifully, but plenty of products don't live in a browser tab you can reach. Desktop software, mobile apps, products behind a VPN or single sign-on, and on-prem installs are all hard or impossible to capture as HTML.

This playbook covers the situations where building a demo from screenshots or a screen recording is the right move, what a good build looks like for each, and when another source fits better.

Snapshot​

"Our product is a desktop app"​

The situation: your product installs on a laptop or workstation, so there's no web page for the extension to capture.

What to build: choose Record my screen and walk through the flow you'd show on a call. Walnut analyzes the video, finds the key moments, suggests a name for each screen and lays a click hotspot where it detected the click. Review the moments, skip the ones you don't need, and keep a span as a clip screen where motion tells the story better than a still.

Tips:

  • Rehearse once before you record so the video has fewer dead ends to skip.
  • When you start a new demo from a recording, Walnut can suggest a demo title and description. Edit them before you import.

"We need to show the mobile app"​

The situation: buyers care about the mobile experience, but you can't capture a phone with a browser extension.

What to build: mirror the phone to your computer and choose Record my phone, or upload portrait screenshots. Walnut suggests a matching iOS or Android device frame for screenshots that look like a phone capture, so the demo reads as mobile at a glance. You can override the frame per screenshot or choose No frame.

Example: A field-service team records a technician's check-in flow on a mirrored phone, keeps six key moments, and adds a guide step on each explaining what the technician does next.

"The product is behind a VPN, SSO or on-prem"​

The situation: the environment you'd demo from isn't reachable from where you build, or the install runs on the customer's own infrastructure.

What to build: have someone with access record the flow or take screenshots, then import the files. You get a clickable demo without anyone needing to reach the environment again. Drag rows to set the order before you import, since that's the order the screens land in.

Tips:

  • Use demo or sandbox data where you can. Before you share, blur anything sensitive. The screenshots and recordings article covers how.
  • Add sticky notes for internal reviewers to flag screens that need checking.

"The prospect sent us screenshots"​

The situation: for a proof of concept, a prospect shares screenshots of their own setup or of how they'd like a workflow to look, and you want to show your product in that context.

What to build: upload the screenshots, put them in story order, and add guides that explain each step. If a screen needs real interaction, use Make editable to convert it into editable HTML with AI. Text, buttons and inputs then become individually editable, and you can attach interactions and variables. Turn on Use only visible data so the conversion only uses values actually visible in the image.

Tips:

  • Check the Match score after converting. Use Fix gaps or Match layout closely to bring it closer to the original.
  • Guides you placed before converting stay attached.

"We already have a recorded walkthrough"​

The situation: you have an onboarding video, a recorded webinar segment or a training walkthrough, and people skim past it.

What to build: upload the video, up to 60 minutes. Walnut splits it into key moments with suggested names and hotspots, turning a passive video into a demo viewers click through at their own pace. Keep a few spans as clip screens where the motion matters. If you'd rather keep the recording intact, choose Add as one video.

Example: An enablement team turns a 20-minute onboarding recording into a demo, keeps around a dozen moments, and adds a guide step on each so new users can jump straight to the part they need.

When Figma import is the better choice​

If the screens you want to show exist as designs in Figma rather than in a running product, use Figma import instead. Each frame lands as a fully editable Walnut screen, and you can update screens from Figma when the design changes without losing your guides. Note that Figma import runs through AI Mode.

You can mix sources in one demo. For example, one section from a desktop recording, one from Figma, and one from a live web capture.

Tips for a better result​

  • Keep each import to one flow. A video imports on its own, so bring screenshots in as a separate batch.
  • Treat the suggested hotspots and names as a starting point and edit them freely.
  • Import into a named section rather than the default Imported screens so the storyline stays readable.
  • After import, the screens behave like any other Walnut screen. Add guides, annotations and variables the same way.

Key takeaways​

  • Use screenshots and recordings for desktop apps, mobile apps, environments you can't reach, prospect-supplied screenshots and existing videos.
  • Walnut splits videos into key moments with suggested names and click hotspots, and frames phone screenshots automatically.
  • Use Make editable when a flat screenshot needs real interactions.
  • Choose Figma import when the screens are designs, not a running product.
Was this helpful?