Design files are full of screens with twelve realistic rows of data. Every real user starts with zero, and that screen decides whether they get to the twelve.

What an empty state should do

• Explain what goes here, in one sentence, without jargon.
• Offer the action that fills it, as a button rather than an instruction.
• Show what it will look like once populated — a faded example row communicates more than a paragraph.
• Distinguish "nothing yet" from "nothing matched your filter". These are different situations and users read the wrong one as a bug.

That last distinction is the one most commonly missed. A search returning no results and an account with no data look identical in most products, and the user concludes the search is broken.

The same applies to error and loading states. Together they are most of what a user sees in their first session, and they are almost always the least-designed part of the product.