What this prompt does
This prompt specifies a reusable empty-state system for a SaaS app and returns working component code. It centers on a single EmptyState component with a typed variant prop covering the variants you list, plus props for illustration or icon, title, description, primary CTA, and an optional secondary link. Sensible per-variant defaults mean a screen can render a good empty state with minimal props, and the microcopy is written so no variant ends in a dead-end.
The variables tune the system to your app. [stack] (for example, React with Tailwind and shadcn/ui) sets the component conventions. [product] gives context so the defaults and copy fit. [tone] drives the microcopy voice. [variants] is the key input — it defines the typed variant prop and the cases the component must cover, such as no-data, no-results, error, and permission-denied, each getting its own sensible defaults.
When to use it
- You want one reusable empty-state component instead of ad-hoc blank screens
- Your app has several empty cases: no-data, no-results, error, permission-denied
- You want sensible per-variant defaults so screens render good states with minimal props
- You need empty states that point users at a next action, not dead ends
- You care about accessible heading levels, focus order, and keyboard-reachable CTAs
- You want example usages across a list, table, dashboard, and detail screen
Example output
The model returns the component code, a props table, and four example usages as separate code blocks — across a list, a table, a dashboard, and a detail screen. The EmptyState component takes a typed variant prop for your listed variants, with props for illustration, title, description, primary CTA, and an optional secondary link. Each variant has sensible defaults and helpful microcopy in your brand tone, plus proper heading level, focus order, and keyboard-reachable CTAs.
Pro tips
- List every case you need in
[variants]; it defines the typed variant prop, so anything omitted has no first-class state - Spend real effort describing
[tone]— the copy is what turns a blank screen into onboarding rather than an error page - Set
[stack]to your frontend so the component and props table match your conventions - Use the per-variant defaults so most screens need minimal props, keeping usage consistent across the app
- Keep the accessibility requirements: proper heading level, focus order, and keyboard-reachable CTAs
- Adapt the four example usages to your real screens so the component is proven across list, table, dashboard, and detail layouts
- Give every variant a primary CTA that points somewhere; the brief is explicit about no dead-end screens, so even an error state should offer a retry or a way out
- Lean on the per-variant defaults so a developer dropping in an empty state gets good copy for free rather than inventing it on each screen
