Sample data is usually too polite.
Every name is short. Every avatar loads. Every title fits. Every table row has the same shape. The empty state is clean because nobody has created the mess yet.
That makes the product easier to present.
It also makes the design easier to lie to.
A mockup filled with tidy data can make weak decisions look finished. The hierarchy holds because nothing is long. The table feels calm because nothing is missing. The component looks reusable because every example behaves.
Then real users arrive with duplicate names, half-filled profiles, long company names, broken images, weird time zones, and imported spreadsheets that do not respect the layout.
The design did not suddenly become worse.
The proof was too convenient.
Pretty data is not proof
Sample data often gets chosen to make the screen look balanced.
That instinct is understandable. A product needs to be shown. A design review needs to move. A component preview should not look broken by default.
But a clean example is only one condition.
It proves the happy path can be arranged nicely.
It does not prove the product can survive use.
The risk is that everyone starts reviewing the composition instead of the behavior. The card looks good. The list feels calm. The dashboard has rhythm. Nobody asks what happens when the second line appears, when a value is missing, when two records have the same name, or when the status is half-known.
The sample data made the hard questions disappear.
Real data repeats itself
Real data is not random.
It has patterns that quietly attack the interface.
Five customers start with the same company name. Three tasks use almost the same title. A table has one column full of values and another column empty because that integration was never connected.
Names repeat.
Dates go stale.
Images fail.
Statuses disagree.
Permissions remove actions from only some rows.
This is not edge-case theater. It is the normal shape of a product after people have used it for a while.
A design that only saw clean examples has not been stress-tested.
It has been flattered.
Inconvenient data changes the conversation
Bad sample data is not useful because it makes the screen ugly.
It is useful because it makes tradeoffs visible early.
A long project name reveals whether truncation preserves meaning. Missing avatars reveal whether identity depends on decoration. Duplicate records reveal whether secondary metadata is doing enough work. Empty values reveal whether the table still scans. Failed statuses reveal whether recovery has a place to live.
These are product questions.
They are cheaper to answer before implementation hardens around the polite version of the screen.
A good review should include data that interrupts the mood a little.
Not chaos.
Just enough reality to make the product show its joints.
Components need awkward examples
This matters even more in component work.
A button story with one perfect label does not prove much.
A card with one short title does not prove the card.
A table with five complete rows does not prove the table.
The component has to meet the data it will actually carry: long words, translated labels, missing descriptions, disabled actions, loading rows, empty sections, permission differences, and values that arrive late.
That does not mean every component preview should become a disaster scene.
It means the component should have at least one honest example.
The one that asks: what happens when the product stops being convenient?
The demo should earn trust
Sample data is part of the design process.
It teaches the team what the product can handle. It decides which weaknesses stay hidden and which ones become visible while they are still easy to fix.
This is why demos should be a little inconvenient.
Use the long name. Leave one field empty. Add the duplicate. Show the failed import. Include the awkward customer who breaks the grid. Let the component meet the work before the user does.
A beautiful mockup is useful.
But a truthful mockup is safer.
The product does not need sample data that makes it look good.
It needs sample data that makes it tell the truth.