Empty products photograph badly. A dashboard with zero activity does not explain what happens after a month of use. A marketplace with no listings looks unfinished. A wallet with no activity communicates almost nothing.
So before launch, teams need populated screens without having real users to populate them.
Start with a fixture, not a screenshot.
A fixture is simply the fictional state you want the product to contain: names, dates, orders, messages, balances, posts or whatever the interface needs. Write that state down before opening the design tool.
This sounds boring. It is also the step that keeps every screen from contradicting the next one.
One fictional user. One believable history. Several screens.
If the profile says the user joined three days ago, the analytics page should not show twelve months of history. If the store has seven orders, the revenue screen should not imply thousands of customers.
Route one: seed a staging environment.
If the product already works, the cleanest option is often a staging account populated with synthetic records. The screenshots come from the real interface, but none of the people, transactions or activity are real.
This gives you high fidelity to production and makes it easier to capture multiple states. The downside is setup: somebody has to create and maintain the fixtures inside the product.
Route two: build the state as a design mockup.
When engineering is not ready, Figma can create the screen long before the actual data model exists. This is fast, flexible and easy to art-direct.
But the mockup can drift away from the product. If the launch is weeks away, make sure somebody checks the final screenshots against the shipped interface before publication.
Route three: use a reusable synthetic interface.
For creator-facing scenes and repeated content, a simulated interface gives you another route. You can create the account state once, save it, and return to it for new screenshots or recordings.
That is especially useful when the visual appears across multiple pieces of content rather than one App Store listing. A multi-scene studio can keep the same fictional identity across finance, commerce, analytics and other digital contexts.
Populate the product with a story, not filler.
The fastest way to make screenshots feel generic is to fill every row with “John Smith,” round numbers and placeholder copy. Instead, give the sample account a small internal logic.
- Use dates that fit the timeline.
- Make totals agree with visible activity.
- Choose a handful of realistic names and labels.
- Keep the same identity across related screens.
- Only create the history the viewer can actually see.
Do not turn sample data into traction.
A populated interface can demonstrate what a product looks like in use. It should not quietly become evidence that you already have customers, revenue, assets or engagement that do not exist.
If a launch page separately makes a real claim—user count, revenue, transaction volume, performance—that claim should come from the real source. The screenshot can illustrate the product without carrying the proof.
The goal of pre-launch sample data is to show the future shape of the product, not to manufacture a past that never happened.
A practical pre-launch workflow.
- List the screenshots or scenes you need.
- Write one fixture that can support all of them.
- Choose staging, design mockup or simulated scene based on product maturity.
- Populate only the visible fields.
- Check continuity across every screen.
- Capture at the final aspect ratio and size.
- Do a last pass against the shipped product before publication.
If the screens will become video later, the same fixture can also feed a screen-recording workflow without rebuilding the fictional account from scratch.