The tangible win
After this lesson, you should be able to review a component and ask for the missing states before it becomes production debt.
Why states matter
Material Design documents interaction states such as enabled, disabled, hovered, focused, and pressed (Material states). This matters because users do not experience components as still images. They experience them while deciding, typing, waiting, making mistakes, and recovering.
A button that only has a “normal” design is like an API that only specifies the success response.
Backend analogy: success-only APIs are incomplete
If you shipped an endpoint with only 200 OK documented, another engineer would ask:
- What happens when validation fails?
- What happens when the user lacks permission?
- What happens while work is pending?
- What happens when retry is possible?
Components need the same discipline. The visible part is just the response body. The state model is the contract.
The state matrix
| State family | Product question | Example |
|---|---|---|
| Availability | Can the user use it now? | Enabled, disabled, loading. |
| Interaction | What feedback confirms the user’s action? | Hover, focus, pressed. |
| Validation | What mistake or success needs explanation? | Error, warning, success. |
| Permission | Is the action blocked, hidden, or explainable? | Read-only, upgrade required. |
| Async | What happens while the system works? | Submitting, retrying, optimistic. |
Accessibility is part of state
Some states must be exposed semantically, not just visually. The W3C button pattern notes that toggle buttons use aria-pressed to communicate pressed state to assistive technologies (WAI-ARIA Button Pattern).
<button aria-pressed="false">Mute</button>
<button aria-pressed="true">Mute</button>If the state only changes color, some users and tools may not receive the contract.
Practice: review the component
Scenario: A product designer gives you a button spec with default, hover, and disabled. The button submits a payment. What is the best next question?
Your review checklist
Before accepting a component, ask:
- What are the valid states?
- What triggers each state?
- What can the user do next?
- How is the state communicated visually and semantically?
- Which states are forbidden or should never occur?
Read next
Primary source: read Material’s States page. Focus on enabled, disabled, hovered, focused, and pressed. Then skim GOV.UK’s Button page to see how practical usage guidance complements visual states.
Ask me if you want a real component teardown. We can inspect a button, input, modal, or table and build its state matrix.