From grimoire
Selects loading indicators by response time (spinner, skeleton screen, progress bar) and prevents duplicate submissions during UI waits over 0.1s.
How this skill is triggered — by the user, by Claude, or both
Slash command
/grimoire:design-loading-statesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Apply the correct loading indicator for each response time range, prevent duplicate submissions, and use skeleton screens to reduce perceived wait time.
Apply the correct loading indicator for each response time range, prevent duplicate submissions, and use skeleton screens to reduce perceived wait time.
Adopted by: Facebook introduced skeleton screens (content placeholders that match the layout of loading content) in 2013 and published A/B test results showing improved perceived performance; LinkedIn, Slack, YouTube, and Google Search all use skeleton screens for primary content loading; Google's RAIL model (Response, Animation, Idle, Load) codifies the 0.1s/1s/10s response time thresholds as the industry standard for web performance UX Impact: Facebook and LinkedIn A/B tests comparing skeleton screens to spinners found skeleton screens reduce perceived wait time by 20–30% at identical actual load times; Nielsen (1993) research on response time thresholds established that users lose the feeling of direct manipulation at > 0.1s, lose the sense that the task is proceeding normally at > 1s, and cannot maintain attention without a progress indicator at > 10s — thresholds confirmed by subsequent Google RAIL research Why best: No loading indicator on a slow action causes duplicate submissions (users click again because they believe the first click failed); a generic spinner gives users no information about progress and no ability to cancel; skeleton screens reduce layout shift when content loads and give users a preview of the forthcoming structure
Sources: Nielsen "Usability Engineering" Ch. 5 (Morgan Kaufmann, 1993); Luke Wroblewski "Designing for Loading States" (lukew.com, 2014); Google Developers "RAIL Performance Model" (web.dev); Bojko "Eye Tracking the User Experience" (Rosenfeld Media, 2013)
| Response time | Indicator | Rationale |
|---|---|---|
| < 0.1s | None | Instant; user perceives as direct |
| 0.1–1s | Inline spinner or subtle state change | Brief; spinner communicates "working" |
| 1–4s | Skeleton screen (preferred) or centered spinner | Long enough to notice; skeleton reduces shift |
| 4–10s | Progress bar + percentage or step count | Users need to know how far along the process is |
| > 10s | Progress bar + estimated time + Cancel option | Users need to assess whether to wait or abort |
Default for unknown duration: skeleton screen (preferable to spinner for layout-heavy content); spinner for single values or compact components.
The moment an action is triggered:
<!-- on submit: -->
button.disabled = true
button.innerHTML = '<spinner /> Saving…'
Failure to disable causes duplicate form submissions, double payments, and conflicting API calls — the most expensive class of loading state bug.
A skeleton screen is a layout placeholder that mirrors the shape of the incoming content — same number of lines, same rough dimensions, same card/row structure.
What to show:
What NOT to show:
Use skeleton screens when:
Use spinner when:
For operations > 4s or with known steps (file upload, multi-step processing):
Uploading: ████████░░░░ 67% — 12s remaining [Cancel]
Include:
Loading is a transition, not a destination. Plan the states on either side:
Success:
Error:
Timeout:
For low-risk, reversible actions (liking a post, adding a tag, reordering items):
Optimistic UI eliminates perceived latency for the most common interactions. Do not use for high-risk, irreversible actions (payments, deletions, sending messages).
npx claudepluginhub jeffreytse/grimoire --plugin grimoireDesigns loading patterns including skeleton screens, spinners, progressive reveals, optimistic UI, and placeholders with duration guidelines and smooth transitions.
Guides writing loading copy that names specific operations, scales detail with wait time, and uses time estimates to manage user anxiety during loading states.
Guides building and reviewing optimistic UI updates, skeleton screens, loading states, code splitting, lazy loading, performance budgets, INP targets, and bundle optimization for perceived speed.