Sample data shows the filled shape of the product
Aliases: dummy data · demo records · populated preview
What it is
Sample data is fake records stuffed into an empty container: a few orders, a sample board, a thread of demo messages, so people can see what the UI looks like when filled. It is a display, not the work they will keep editing. An editable starting point (a starter project, a seeded document) is a different object. Empty states hint structure with a skeleton; sample data sits that structure down with concrete rows—density, fields, and relations that empty copy cannot say.
Why it happens
An empty UI cannot support mental rehearsal: people do not know how wide a row is, what a filter leaves, which blocks a detail view opens. Sample rows turn those into scannable facts; learning happens on the real layout without a first create. For rehearsal to work, the sample must look like “a ledger already in use,” not three slogan lines. Because it looks real, the display job and the record job compete for the same list controls. This entry only requires the display job: after looking, people can answer which columns exist when filled and what a row contains. Once those rows enter a searchable, countable, collaborative record set, display has crossed into pollution. The sample should be just heavy enough to hold the layout; more makes people think the product already finished their work, and motive to create a first real item drops.
Where it stops holding
In regulated or reconciling contexts, fake rows can be taken as real balances; do not demo with plausible money. A container that already holds real data does not need samples to show shape; inserting fakes is pollution. Experts who cleared data to see a production-empty state are blocked if samples pour back in. A pure graphic canvas has no “row” to show; shape belongs to the empty-state structural preview, and a planted drawing becomes starter artwork.
Applying it
- Place samples only while the container has no real records, to show columns, density, and what a row can do—not to generate a deliverable file for them.
- Sample fields should light up the same cells a real layout uses; “Sample 1” that cannot fill a cell is not a demo.
- After the first real record is written, samples should leave the working view’s display job and not keep “demonstrating” beside real rows.
- Verify with someone new looking only at the sampled UI: what objects exist when filled, what can a row do. If they can name the structure, display worked; if they start editing those rows as their work, the sample has crossed over.