Go-to-Market

A Screenshot Hygiene Checklist Before You Publish a Demo

A step-by-step checklist for cleaning every screenshot in a demo before it goes public, from personal data to stray UI and browser chrome.

A demo can be well written, well branded and still embarrassing. A real customer's email in a sidebar. A notification about an internal incident. A browser tab named after an unannounced project. Screenshot hygiene is the check that catches these before the demo is public.

Short Answer

Before publishing, go through every step and check for personal data, confidential figures, stray UI and anything outside the product frame.

  1. Prepare the account before recording.
  2. Check each step against a fixed list.
  3. Have someone who did not record the demo do a second pass.

Why Hygiene Is Harder than It Looks

The recorder is focused on the flow. They do not see the corners.

  • Data appears in sidebars, badges and footers.
  • Notifications pop up mid-recording.
  • Placeholder text like "test test asdf" looks fine to the recorder.
  • A second reviewer sees what the first one stopped noticing.

Before Recording

  • Use a test account with plausible data.
  • Close notifications and chat apps.
  • Clear recent searches and recent items.
  • Rename any test records with silly names.
  • Set the browser window to the size you want.

Checklist for Each Step

Check Look at
Personal data Names, emails, phone numbers, avatars
Customer names Tables, headers, recent lists
Figures Revenue, usage, pricing, IDs
Secrets API keys, tokens, webhook URLs in settings
Unreleased work Menu items or screens not yet announced
Stray UI Toasts, tooltips, open menus, loading spinners
Placeholder text "Test," "asdf," "lorem ipsum"
Consistency Same sample company name on every step

Fix What You Find

  • Blur personal data and secrets. Check that the blur is baked into the published image.
  • Replace placeholder text with plausible text.
  • Change numbers that reveal real figures.
  • Re-record a step if the stray UI covers something important.

Second Pass

Ask someone who did not record the demo to go through it in preview. They will see what you no longer notice.

An Illustrative Worked Example

This example is hypothetical. A recorder finishes a ten-step demo.

  1. On step 2, a toast reads "Sync failed." They re-record that step.
  2. On steps 4 to 7, a sidebar shows a real customer's name. They blur it on each.
  3. On step 8, a record is named "test 3." They replace it with a plausible name.
  4. A colleague finds an API key fragment on step 9. They blur it.

The Old Way Versus a Better Way

Old way Better way
Record in whatever account is open Record in a prepared test account
Recorder checks their own work A second person reviews every step
Look at the main area only Check sidebars, badges, footers and toasts
Crop out problems Blur or replace, so the screen stays whole
Fix after someone notices Check before every publish

Prepare a Reusable Demo Account

Many hygiene problems start in the account, not the recording. A dedicated demo account removes them before you start.

  • Seed it with a plausible sample company and a handful of sample people.
  • Use the same sample names everywhere, so every demo tells one consistent story.
  • Keep dates recent, or refresh them before a big recording session.
  • Turn off notifications that could appear mid-recording.
  • Keep it out of real workflows, so nobody fills it with real data later.

Write down the sample names and figures. When someone records a new demo, they use the same world.

Make the Review a Habit

A checklist works only if it runs every time.

  • Put the table above in the place your team keeps launch checklists.
  • Make "second pass done" a condition of publishing.
  • After a problem slips through, add the place it hid to the list.

A 1-Week Rollout Plan

Day 1 to 2. Set up the demo account with sample data.

Day 3. Review every live demo against the checklist.

Day 4 to 5. Fix what you find, republish, and add the checklist to your publishing routine.

Questions to Ask Before You Start

Answer these before recording. They take a few minutes and prevent most rework.

  • Is there a dedicated demo account, and who owns it?
  • Are the sample names and figures written down for everyone to reuse?
  • Who does the second pass, and is it required before publishing?
  • Does the published output contain only the blurred pixels?
  • What do we do if a problem is found after a demo is live?

Where Proovyt Fits (Full Disclosure)

Proovyt is an interactive demo tool, and this is our blog.

  • Blur and redact on every plan, baked into the pixels at publish or export.
  • Replace text and change a number on any screenshot.
  • Publishing copies only the screenshots the demo uses.
  • Proovyt Capture records only the tab you choose.

See the product page and the FAQ.

Common Mistakes

  • Checking only the centre of each screen.
  • Skipping the second pass.
  • Blur that is only a layer over the original.
  • Inconsistent sample names across steps.

The Bottom Line

A fixed checklist and a second pair of eyes catch what one recorder misses. Run both before every publish.

Frequently Asked Questions

Does Proovyt record my whole screen? No. It records only the tab you choose to record.

Is blur permanent? In the published demo, yes. It is baked into the pixels at publish or export.

What if I find a problem after publishing? Fix it and republish, which keeps the link. Or unpublish to take it down at once.

Should I blur avatars? If they are real people, yes.

Where can I read more on data in demos? See protecting customer data in demos.

Filed Under
  • Go-to-Market
  • Checklist
  • Data Privacy