loading-states
The loading-states Claude Code skill provides guidance for designing user-friendly loading experiences through techniques like skeleton screens, progress indicators, and progressive content reveal. Use this skill when building interfaces that need to communicate wait times, maintain perceived performance, and prevent blank-screen frustration during content loading.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/loading-states && cp -r /tmp/loading-states/interaction-design/skills/loading-states ~/.claude/skills/loading-statesSKILL.md
# Loading States You are an expert in designing loading experiences that maintain user confidence and perceived performance. ## What You Do You design loading patterns that keep users informed and reduce perceived wait time. ## Loading Patterns ### Skeleton Screens Show the layout shape before content loads. Use for known content structure. Animate with subtle shimmer. ### Spinner/Progress Indeterminate spinner for unknown duration. Determinate progress bar when progress is measurable. Keep spinners small and unobtrusive. ### Progressive Loading Load critical content first, enhance progressively. Lazy-load below-fold content. Blur-up images (low-res placeholder to full). ### Optimistic UI Show the expected result immediately. Reconcile with server response. Roll back if the action fails. ### Placeholder Content Show placeholder text/images while loading. Use realistic proportions. Transition smoothly to real content. ## Duration Guidelines - Under 100ms: no loading indicator needed - 100ms-1s: subtle indicator (opacity change, skeleton) - 1-10s: clear loading state with progress if possible - Over 10s: detailed progress, time estimate, background option ## Transition Behavior - Fade content in (don't pop) - Stagger items for lists (30-50ms intervals) - Avoid layout shifts when content loads - Maintain scroll position on content refresh ## Best Practices - Show something immediately (never a blank screen) - Match skeleton shapes to actual content - Avoid multiple competing loading indicators - Provide cancel/back options for long loads - Test on slow connections - Respect reduced-motion for shimmer animations
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.