
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.
- Prepare the account before recording.
- Check each step against a fixed list.
- 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.
- On step 2, a toast reads "Sync failed." They re-record that step.
- On steps 4 to 7, a sidebar shows a real customer's name. They blur it on each.
- On step 8, a record is named "test 3." They replace it with a plausible name.
- 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.
