ux-feedback
Add loading, empty, error, and success feedback states to StyleSeed components and pages with practical mobile-first rules.
What this skill does
# UX Feedback ## Overview Part of [StyleSeed](https://github.com/bitjaru/styleseed), this skill ensures data-dependent UI does not stop at the happy path. It adds the four core feedback states every serious product needs: loading, empty, error, and success. ## When to Use - Use when a component or page fetches, mutates, or depends on async data - Use when a flow currently renders only the success path - Use when a card, list, or page needs better state communication - Use when the product needs clear recovery and confirmation behavior ## The Four Required States ### Loading Use skeletons that match the final layout. Avoid spinners inside cards unless the pattern genuinely requires them. Delay skeletons slightly to avoid flashes on fast responses. ### Empty Provide a friendly explanation and a next action. Zero values should still render meaningfully instead of disappearing. ### Error Use plain-language failure messages and always offer recovery where possible. Localize failures to the affected card or section if the rest of the page can still work. ### Success Use toasts or equivalent lightweight confirmation for completed actions. Add undo for reversible destructive changes. ## Output Return: 1. The data-dependent areas identified 2. The loading, empty, error, and success states added for each one 3. Any reusable empty-state or toast patterns created 4. Follow-up work needed for analytics, retries, or accessibility ## Best Practices - Match loading placeholders to the real layout - Keep partial failure isolated whenever possible - Make recovery obvious, not hidden in logs or developer tools - Use success feedback sparingly but clearly ## Additional Resources - [StyleSeed repository](https://github.com/bitjaru/styleseed) - [Source skill](https://github.com/bitjaru/styleseed/blob/main/seeds/toss/.claude/skills/ux-feedback/SKILL.md) ## Limitations - Use this skill only when the task clearly matches the scope described above. - Do not treat the output as a substitute for environment-specific validation, testing, or expert review. - Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
Related in design
ios-hig-design-guide
IncludedBuild, update, and apply iOS design specifications using Apple Human Interface Guidelines (HIG) source data. Use when a task asks for iOS UI/UX rules, Apple design standards, component behavior, accessibility constraints, interaction patterns, or feature-level design-spec writing grounded in official HIG pages.
macos-design
IncludedDesign and build native-feeling macOS application UIs. Use this skill whenever the user asks to create a desktop app, macOS app, Mac-style interface, Apple-style UI, system utility, or anything that should look and feel like a native Mac application. Also trigger when users mention "native feel", "desktop app design", "Apple design patterns", "sidebar layout", "traffic lights", or want to build tools/utilities that feel like they belong on macOS. This skill covers layout, composition, interaction patterns, animations, light/dark mode, and all the subtle details that make an app feel like Apple built it.
ui-design-patterns
IncludedCommon interface patterns, navigation patterns, form patterns, data display patterns, feedback patterns, and accessibility considerations
figma-design
IncludedFigma workflows, components, auto layout, constraints, prototyping, design systems, and plugin development based on Figma Plugin API documentation
ux-principles
IncludedUser research, usability heuristics, user psychology, accessibility, inclusive design, user testing, and UX metrics
wireframing
IncludedLow/high fidelity wireframes, user flows, information architecture, prototyping techniques, and design iteration processes