Design every empty state a dashboard can hit so 'no data yet' never reads like a bug

You are designing the empty-state system for one specific screen in a product, covering every distinct reason that screen can render with nothing in it, not just a single generic "no data" message.

SCREEN
The Reports tab in a project-management SaaS dashboard.

DISTINCT EMPTY REASONS
New account with no reports created yet; existing account with reports but the current filter/date-range matches none; the reports API call failed to load.

FIRST-USE USER CONTEXT
They've just signed up and have never created a report before; they don't yet know a report is built from saved views, not raw data.

PRIMARY NEXT ACTION AVAILABLE
Create report from template; for the filtered-zero case, clear filters; for the error case, retry the load.

VISUAL SYSTEM CONSTRAINTS
No custom illustrations available yet — use icon + text only, single column, matches the existing card component width.

RULES
Treat each entry in DISTINCT EMPTY REASONS as its own empty state with its own copy — a screen with zero rows because a brand-new account hasn't created anything yet is a different problem from the same screen showing zero rows because a filter matched nothing, and collapsing both into one "Nothing here" message is the single most common empty-state mistake, because the correct next action is different in each case (create the first thing vs. loosen the filter). For every state, write a headline that names what's actually true (not "No results" as a flat fact with no path forward) and a single sentence of supporting copy, then specify exactly one primary action button tied to that state's real next step — never stack two competing CTAs in an empty state, since a user who hit an empty screen is already uncertain and a choice between two vague buttons increases that uncertainty rather than resolving it. For the first-use state specifically, write copy that assumes zero prior context about the product's terminology, since this is often the very first thing a new account sees on that screen. For an error or failed-load state, the copy must never blame the user's input or connection speculatively — state only what's known (the load failed) and offer retry, never invent a diagnosis the system hasn't confirmed. Specify layout notes only where they change per state (e.g., whether an illustration is warranted or whether a filtered-to-zero state should stay minimal and inline rather than taking over the whole screen with a big illustration, which reads as overkill for a one-click filter fix).

WHAT NOT TO DO
Do not produce a single reusable empty-state template with a variable swapped in — that is exactly the failure mode of collapsing distinct problems into one message. Do not add humor or personality copy unless the product's existing voice already uses it elsewhere on this screen; empty states are a bad place to introduce a new tone the user hasn't seen before.

OUTPUT FORMAT
A table with one row per empty reason: State name | Headline | Supporting copy | Primary action label + destination | Layout note (illustration / inline / none). Close with one paragraph flagging any empty reason from the input that actually needs to be split further into two distinct states.