Onboarding Screenshot Placeholders for Product Tours

The screenshot problem

Product tour screenshots are almost always out of date

Screenshots in product tours decay faster than almost any other content asset. Every UI change—a button move, a layout update, a new sidebar item—makes the screenshot subtly wrong. Users notice when the highlighted area in the tour does not match the actual interface. That discrepancy breaks the trust the tour is trying to build.

The practical consequence is that screenshot-heavy tours become an engineering bottleneck: before a redesign ships, someone has to re-capture, crop, annotate, and upload every screenshot in every tour flow. Teams that skip this step ship tours with outdated images and accept the resulting user confusion.

Placeholder images do not solve the stale screenshot problem permanently, but they remove the blocker on launching a tour with correct structure, copy, and sequencing while screenshot production catches up.

Standard dimensions

Screenshot placeholder sizes for common tour frameworks

Intercom Product Tours typically use screenshots at 800x500 or 600x400. Appcues modal images render at 480x320 or 600x400. Shepherd.js tooltip attachments use smaller images around 400x250. Full-page overlays in frameworks like Intro.js or UserPilot can go up to 1200x700.

For screenshot placeholders, use a background color that represents the UI context: light blue or gray for product dashboards, purple for analytics views, green for success states.

<!-- Intercom-style tour screenshot placeholder -->
<img
  src="https://fallback.pics/api/v1/800x500/EFF6FF/3B82F6?text=Feature+Screenshot"
  width="800"
  height="500"
  alt="Feature screenshot placeholder"
/>

<!-- Appcues modal image -->
<img
  src="https://fallback.pics/api/v1/600x400/F5F3FF/7C3AED?text=Step+2+Screenshot"
  width="600"
  height="400"
  alt="Onboarding step screenshot placeholder"
/>

<!-- Shepherd.js tooltip image -->
<img
  src="https://fallback.pics/api/v1/400x250/F0FDF4/10B981?text=New+Feature"
  width="400"
  height="250"
  alt="New feature screenshot placeholder"
/>

Step labeling

Label placeholders with step number and feature name

During internal review of a product tour, reviewers need to know which placeholder corresponds to which step. Embed the step number and feature name in the placeholder text so the tour structure is legible even without real screenshots.

Keep labels short: 'Step 1: Dashboard', 'Step 2: Reports', 'Step 3: Export'. This also helps QA testers verify that the correct screenshot appears in each slot once real assets are uploaded.

const tourSteps = [
  {
    target: '#dashboard-btn',
    title: 'Your Dashboard',
    image: 'https://fallback.pics/api/v1/800x500/EFF6FF/3B82F6?text=Step+1+Dashboard',
    content: 'Get an overview of all your key metrics at a glance.',
  },
  {
    target: '#reports-btn',
    title: 'Reports',
    image: 'https://fallback.pics/api/v1/800x500/F5F3FF/7C3AED?text=Step+2+Reports',
    content: 'Drill into the data that matters to your team.',
  },
  {
    target: '#export-btn',
    title: 'Export',
    image: 'https://fallback.pics/api/v1/800x500/F0FDF4/10B981?text=Step+3+Export',
    content: 'Download reports in CSV, PDF, or directly to Google Sheets.',
  },
];

CMS-driven tours

CMS-managed tour assets with fallback URLs

If your product tour content is managed in a CMS (Contentful, Sanity, Notion API), the image field may be null for steps that have not yet been designed. Resolve null image fields to fallback.pics URLs at query time rather than letting nulls reach the tour renderer.

This means your tour framework always receives a valid image URL and never needs to handle the null case at the component level.

// Contentful tour step resolver
function resolveTourStepImage(step: ContentfulTourStep): string {
  if (step.screenshot?.url) return step.screenshot.url;
  const label = encodeURIComponent(`Step ${step.order}: ${step.featureName.slice(0, 12)}`);
  return `https://fallback.pics/api/v1/800x500/EFF6FF/3B82F6?text=${label}`;
}

Design review

Use placeholders in Figma handoff for tour frame annotation

During design handoff, Figma frames for product tours often contain placeholder images rather than real screenshots. Using fallback.pics URLs in the Figma frame's image embed means the designer, engineer, and PM are all looking at the same dimensioned placeholder in all contexts: Figma, staging, and production.

When real screenshots are ready, replacing the URL in Figma and in the code is a single coordinated update rather than a hunt across multiple asset systems.

A/B testing tours

Placeholder-first tour development accelerates A/B test setup

If you A/B test onboarding flows, the variant tour needs images just as much as the control. With placeholder-first development, you can launch both variants with the same placeholder images and measure conversion differences before investing in variant-specific screenshot production.

Only produce custom screenshots for variants that show statistically significant conversion lift. This avoids wasted design effort on underperforming variants.

Internal links

Related SaaS image and onboarding patterns

For file upload preview fallbacks and integration logo grids that appear in onboarding flows, see the related posts.

https://fallback.pics/docs/
https://fallback.pics/placeholder-image-api/
https://fallback.pics/blog/empty-state-images-vs-placeholders/
https://fallback.pics/blog/file-upload-preview-fallbacks/