Overview
How might we design skeleton screens so people can trust and act on AI output?
When this pattern fits
- Ideal for AI apps with longer generation times, where a structure-matched loading state reduces perceived latency and sets expectations.
When to skip or lighten it
- Sub-200ms responses where skeletons flicker uselessly.
- Unknown output shapes that would make a fake skeleton misleading.
- Voice-only modes where visual skeletons do not apply.
States
State model coming soon
Key UX elements
Key UX elements coming soon
Anti-patterns to avoid
Spinners with blank layout instead of content-shaped placeholders.
Skeletons that do not match the final layout, causing jumpiness.
Leaving skeletons on screen after content failed.
Animating so aggressively that accessibility suffers.
How products use it
| Product | Implementation |
|---|---|
| Linear | Content-shaped loading placeholders in app views. |
| Notion | Block skeletons while AI or pages load. |
| Vercel / Next.js apps | Route and streaming skeletons for AI UIs. |
| ChatGPT | Streaming placeholders as answers begin. |
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Skeleton Screens" AI interface design pattern.
Pattern Definition:Frequently asked questions
When should AI UIs use skeletons vs streaming text?
Stream text when the answer is prose. Use skeletons for cards, tables, or multi-panel layouts that are not token-shaped.
Do skeletons replace progress steps?
No. Skeletons show layout; progress steps explain tool work. Use both for agent runs.
How do you avoid layout shift?
Match skeleton dimensions to the likely final component, then morph into real content.
What if generation fails?
Replace skeletons with an error state and retry—never freeze on gray bars.