Look at the screenshots on your own product page. Count how many contain one of these:
- A name that is "Test User", "John Doe", or "asdf"
- A row of lorem ipsum where real copy would be
- A date from eighteen months ago
- A notification badge showing an implausible number
- An empty state that is not meant to be empty
- Three rows in a table that is designed for thirty
- Your own email address
Most products have several. And every one of them tells a visitor the same thing: nobody uses this yet.
Why this is worse than a design flaw
A visitor evaluating unfamiliar software is doing one thing above all others: looking for evidence that other people use it. It is the single strongest signal in the decision, and it operates below the level of conscious reasoning.
Test data is direct evidence to the contrary. Not a suggestion — evidence. A dashboard with three rows in it is a dashboard with three rows in it, and the viewer's model of your product updates accordingly.
The unfair part is that this happens before they evaluate your design. You can have made something excellent and lost the argument on the contents of a name field.
What realistic data actually means
Not fake-impressive. Realistic. These are different and the difference matters.
Plausible volume. A table designed for thirty rows should show twenty-something, with a scrollbar implying more. Three rows says new. Two thousand says you are showing off, and it also makes the screenshot unreadable.
Plausible names. Real-sounding, varied in length, from more than one part of the world. A column of five names that are all eleven characters long looks generated because it is. Include one that is too long and gets truncated — truncation is a sign of real use.
Plausible numbers. Not all round. $12,480 reads as real; $10,000 reads as a placeholder. Not all growing either — one metric down is more convincing than five up, and it is the detail that makes people trust the rest.
Plausible dates. Recent, varied, clustered the way real activity clusters: several today, a few yesterday, thinning out backwards. A list where every item is "2 days ago" is a list somebody seeded in a loop.
Plausible mess. One item with an awkward name. One thing in an unusual state. Real accounts are slightly untidy, and a screenshot with zero untidiness reads as staged.
The empty state problem
A particular version of this deserves its own note, because it is so common in early-stage products.
You screenshot the app, and the section you are proudest of is empty, because your test account never used it. So the product page shows a nicely designed empty state — and an empty state is a picture of nothing happening.
Empty states are worth showing exactly once, on a page about onboarding. Everywhere else they are the wrong screenshot.
How to seed an account properly
A method that takes about an hour and is reusable forever.
- Make a dedicated demo account. Not your own. Yours has your email in the corner, your half-finished experiments, and a settings page full of flags.
- Give it a name and a story. "Northwind Studio, a 6-person design agency." Every piece of data you enter then has an obvious answer, instead of being invented field by field.
- Fill it to a realistic depth, not to the maximum. Enough that lists scroll, charts have shape, and the search has something to find.
- Check every corner of the chrome. The avatar, the initials, the account name in the sidebar, the notification count, the breadcrumb. This is where test data survives longest because you stop seeing it.
- Screenshot everything in one session. Same account, same data, same day. A set captured across three months has three different states in it and they will not line up.
- Keep the account. Do not let it drift. It is an asset; you will re-shoot from it every time the UI changes.
The chrome is where it hides
The last point is worth its own warning. When you are reviewing a screenshot, you look at the content area, because that is what you are showing.
The things that give you away are almost never in the content area. They are in the top-right avatar, the tab title, the sidebar footer, the version number, the browser URL showing localhost:3000.
Zoom to 200% and read every piece of text in the image that is not the subject. It takes thirty seconds and it is the highest-yield review you can do on a product screenshot.
A visitor cannot evaluate your software. They can only evaluate the evidence that other people already did. Your screenshots are most of that evidence.
The underlying idea
The content of your screenshots is doing as much persuading as the design of them. Seed one demo account properly, keep it, shoot the whole set from it in one sitting, and check the corners of the frame rather than the middle.