Your design system is missing the states that matter

Open almost any design system and the button page will show you six variants, three sizes and a hover state. Open the product it governs and you will find a button that has been disabled with no explanation, a table with a blank area where an empty state should be, and a form that reports failure by doing nothing.

The system is not wrong. It is incomplete in a specific and predictable way: it documents the states designers see in Figma, and omits the ones users see in production.

The nine states

• Default — documented everywhere.
• Hover — documented everywhere, and irrelevant on touch.
• Focus-visible — often missing, and the one keyboard users depend on entirely.
• Active/pressed — usually a nice-to-have.
• Disabled — documented, but rarely with the reason it is disabled.
• Loading — improvised per feature.
• Error — improvised per feature, usually as a red border with no message.
• Empty — the most common state on day one of any product.
• Selected — inconsistently modelled, especially in filters.

Empty is a first-run experience

Every list is empty before it is full, and every user meets that version first. Treating the empty state as an edge case means the product’s first impression is the one nobody designed.

An empty state has a job: say what would be here, and offer the action that puts something here. "No results" does neither.

Errors are content, not decoration

<!-- The border says something is wrong. Nothing says what. -->
<input class="error" />

<!-- The state is announced, associated, and actionable. -->
<input id="email" aria-invalid="true" aria-describedby="email-error" />
<p id="email-error">Enter an email address we can reply to — this one is missing an @.</p>

The second version is not more work at the system level. It is less work at the feature level, because the association and the announcement are already decided.

The test

Take any component in your system and ask what it looks like when the request behind it has failed, when there is nothing to show, and when the user is holding a keyboard. If the answer is "that depends on the feature", you have a style guide.