UI states · by UXKIN

Real UI, not AI slop.

Most generated screens only show the happy path: perfect data, a fast connection, nothing failing. Real people meet everything else first: an empty list on day one, a spinner that never ends, an error with no way out, a name too long for its box. This skill finds those states for each screen and builds them properly.

It works on its own, with no account, token or server.

When to Use

• Use when building or reviewing a screen that loads, lists, searches, submits or saves data.
• Use when asked to make UI production-ready, handle edge cases or "finish" a screen.
• Use when a screen only shows the happy path.

Connect UXKIN (optional)

UXKIN (https://uxkin.com) is a library of 500,000+ real app screens, user journeys and 15k+ website design systems, each with a DESIGN.md. Connected, it lets you look at how real products solve what you are building. To connect it, the person:

1. adds the MCP server https://uxkin.com/mcp (name: uxkin) in this app's MCP settings,
2. signs in with their UXKIN account when the app asks (searches need a UXKIN plan),
3. or follows the guide for their app: https://uxkin.com/ui-design-mcp

Only set this up when the person asks for it; never add servers or accounts on your own.

1. List the states for each screen

For every screen or component that shows, loads or changes data, go through this list and keep the ones that can happen:

Write the list down before building, and confirm the important ones with the person if the right behavior isn't obvious.

2. Build each state properly

• First use and empty: say what this place is for and give the next step as a button ("Add your first invoice"), not just "No data". Empty because of a filter or search is different: say so and offer to clear it.
• Loading: keep the layout steady. Use placeholders shaped like the content for lists and cards, an inline spinner for small areas, and progress for long tasks. Don't block the whole screen for a part of it. If it takes more than a few seconds, say what's happening.
• Error: say what went wrong in plain words, what the person can do, and offer the action (Try again, Edit, Contact support). Keep what they typed. Never show raw error codes or stack traces.
• Offline: show that the connection is missing, keep what's already loaded visible, and retry automatically when it's back if that's safe.
• Validation: check at the right moment (on leaving a field or on submit, not on every keystroke), put the message next to the field, and say how to fix it.
• Permission or plan missing: explain what's missing and how to get it, and keep the rest of the screen usable.
• Success: confirm briefly and in place (a short message, the item appearing in the list); offer Undo for actions that remove things.
• Edge content: truncate long text with the full value available, give images a fallback, format big numbers, and paginate or virtualise long lists.
• Busy actions: disable the button and show progress while it runs so it can't be sent twice.

Use the project's existing components and copy style for every state; don't invent a new look for them.

3. Check each state

Make each state appear for real: empty data, a slow or failed request (through the browser's network tools, a mock or a test flag), offline mode, very long text. Look at each at a phone and a desktop width. Fix what's broken and check again.

Report which states you built, which you checked and how, and any that need a decision from the person (for example, what the error should say for their backend).

Optional: real examples

If the UXKIN MCP tools are connected, find_ui_references finds how

…