Skip to main content

SaaS Error & Empty State Design System

Build a design system for error pages, empty states, loading and offline states — the overlooked screens that shape UX and support load.

Füllen Sie die Platzhalter aus

Edit the values, then copy your finished prompt.

Ihr Prompt
prompt.txt

                                

What this prompt does

This prompt designs a complete error and empty-state system for your product — the overlooked screens that quietly shape user trust and support load. You provide [product_name], [product_type], [framework], [brand_personality], [primary_action], [illustration_style], and [illustration_count], and it covers HTTP error pages, empty states, loading states, connection/offline states, partial-failure states, and design specifications including SVG illustrations and copy guidelines.

The structure works because these screens are usually an afterthought until support tickets pile up. The prompt is a checklist that forces coverage of every state — from a 404 with a search bar to a skeleton screen matching real content layout to an offline banner that queues actions. It ties tone to your [brand_personality] and the copy rule that an error should never blame the user, and it generates [illustration_count] SVGs in your [illustration_style]. Every state answers three questions: what happened, is it the user's fault, and what to do next.

When to use it

  • You're shipping a web app and want error and empty states designed up front, not after support complaints.
  • You need consistent HTTP error pages (401, 403, 404, 429, 500, 503) with helpful recovery paths.
  • You want skeleton screens that match real content layout instead of generic spinners.
  • You're handling offline and partial-failure states and need graceful degradation patterns.
  • You need copy guidelines that set a consistent tone and never blame the user.
  • You want [illustration_count] SVG illustrations in a defined [illustration_style] for key states.

Example output

You get a categorized state system: HTTP error pages each with plain-language explanations and recovery actions (re-login that preserves the URL, retry countdowns, incident links); empty states for dashboards, lists, search, and filtered views with clear first-action CTAs; loading states using content-matched skeletons and optimistic UI; connection and offline states with queued actions and reconnect banners; partial-failure handling for individual widgets; and design specs — SVG code for [illustration_count] states, per-state copy tone, entrance animations, responsive behavior, and screen-reader announcements.

Pro tips

  • Set [brand_personality] carefully; it drives the copy tone across every state, from playful to strictly professional.
  • Use [primary_action] so empty-state CTAs point users toward what the product is actually for.
  • Match [illustration_style] to your real design language (minimal line art, full-color) so the SVGs fit.
  • Cap [illustration_count] at the states that matter most; you rarely need a unique illustration for every screen.
  • Keep the rule that errors never blame the user — it's the single biggest trust lever in this whole system.
  • Match [framework] to your stack so the generated state components are reusable rather than throwaway.

Frequently Asked Questions

Does it cover loading and offline states, or only error pages?
It covers all of them. Beyond HTTP error pages, it designs empty states, loading states with content-matched skeletons, connection and offline states with queued actions, and partial-failure states where one widget fails but the rest of the page stays functional.
Will it generate the illustrations?
It generates SVG illustration code for the number of key states you set in `[illustration_count]`, in the `[illustration_style]` you specify. These are starting-point line-art or simple SVGs you can refine, not polished production artwork from a designer.
How does it handle copy tone?
It produces copy guidelines per state type, anchored to your `[brand_personality]`, with a firm rule that error states never blame the user. Every state is written to answer what happened, whether it's the user's fault, and what to do next.
Are the states accessible to screen readers?
Yes. The design specifications include screen-reader announcements for dynamic state changes, plus reduced-motion-aware entrance animations and responsive behavior, so users on assistive technology aren't left without feedback when a state changes.
Engr Mejba Ahmed

Need this built for real?

Engr Mejba Ahmed

AI Developer · Software Engineer

I'm Mejba — I design and ship production AI systems, automations, and full-stack apps. If you want this turned into a working solution for your team, let's talk.

Mehr in Tech & SaaS UI Prompts

Engr Mejba Ahmed

Engr Mejba Ahmed

Claude Code Expert · Online

👋

Hey there!

Quick Actions

WhatsApp Instant reply

Chat on WhatsApp

+880 1723 741224 · Instant reply

Popular Questions

Engr Mejba Ahmed is connected
Engr Mejba Ahmed is typing...
Engr Mejba Ahmed avatar

✉ Want me to follow up? Drop your email

Engr Mejba Ahmed avatar

📞 Connect Directly

Choose how you'd like to reach me

WhatsApp

+880 1723 741224

Email

[email protected]

✓ Details sent! I'll get back to you shortly.

Powered by OpenAI

335+

Blog Posts

25

AI Courses

63

Projects

Services & Expertise

Pricing & Process

Learning & Resources

Connect & Support