Design an Effective Skeleton Screen Loading Pattern for Better Perceived Performance
Create a complete skeleton screen design system with animation specs, component variants, and accessibility guidelines.
📝 The Prompt
Design a skeleton screen (shimmer/placeholder UI) system for [APPLICATION_NAME], a [APP_TYPE] with the following key screens: [SCREEN_1], [SCREEN_2], and [SCREEN_3]. The design system uses [DESIGN_SYSTEM_NAME or 'a custom system'] with a base background color of [BG_COLOR] and surface color of [SURFACE_COLOR].
Provide a complete skeleton screen design specification:
1. **Content Mapping Strategy**: For each of the three screens listed above, analyze the content structure and identify which elements should have skeleton placeholders vs. which should remain static (e.g., navigation bars, fixed headers). Create a mapping table with columns: Element | Skeleton Shape (rectangle, circle, pill) | Approximate Dimensions | Position.
2. **Visual Design Tokens**:
- Skeleton bone color (light theme): [recommend specific hex]
- Skeleton bone color (dark theme): [recommend specific hex]
- Border radius for rectangular bones
- Shimmer gradient colors and angle
- Spacing between skeleton elements
3. **Animation Specification**: Define the shimmer animation including direction (LTR, RTL, or based on [READING_DIRECTION]), duration (recommend between 1-2s), easing function, and whether bones animate individually or as a unified wave.
4. **Transition Behavior**: Specify how content replaces skeletons — options include fade-in, instant swap, or progressive reveal. Recommend the best approach for [APP_TYPE] and explain why. Define the minimum display time to avoid flash-of-skeleton.
5. **Component Variants**: Design skeleton variants for these common patterns:
- Text block (title + paragraph)
- Card with image, title, and metadata
- List item with avatar and two lines of text
- [CUSTOM_COMPONENT specific to the app]
6. **Accessibility**: Address how skeleton screens should be announced to screen readers using ARIA attributes. Recommend specific aria-busy, aria-label, and role usage.
7. **Performance Budget**: Set guidelines for when to use skeleton screens vs. spinners vs. no loading indicator based on expected load time thresholds.
💡 Tips for Better Results
Match skeleton shapes closely to actual content dimensions to minimize layout shift (CLS) when real content loads — mismatched skeletons feel more jarring than a simple spinner. Use a minimum display time of 300-500ms for skeletons to avoid a disorienting flash when data loads very quickly. Never use skeleton screens for actions that require user attention like form submissions — use progress indicators or spinners instead.
🎯 Use Cases
Front-end developers and UI designers use this when implementing loading states across an application to improve perceived performance and create a polished user experience.