Designing every state
🎯You'll be able to
List and design every state for each screen and component: default, hover, focus, selected, disabled, loading, empty, error and success.
🏠The everyday picture
A traffic signal isn't designed only for green. Red, amber, flashing amber and "out of order" all need a clear meaning.
📘What it really is
- Component states:
- Default and hover (for mouse users);
- Focus (for keyboard users; UX7);
- Selected / pressed (a chosen slot);
- Disabled (not available, with a reason where helpful: "booked");
- Loading (a button that says "Booking…" while waiting);
-
Error (a field with a message).
-
Screen states: empty (no results, nothing yet), loading, error (couldn't load), partial and success.
-
A state inventory is a table of components and screens against states, ticked when designed. It shows gaps before developers find them.
-
Disabled buttons: use them carefully. A disabled Continue can confuse people if they don't know why; the kit's slot screen keeps Continue active-looking only after a time is chosen, and says "Choose a time first" if pressed early.
-
Loading: show that something is happening and prevent double submissions (disable the button with
aria-busy="true").
📝A worked example
Input: the reference component page (design-system/components.html).
| Component | States shown |
|---|---|
| Button | default, secondary, focus, disabled, loading |
| Text field | default, focus, error, disabled |
| Time slot | default, selected, focus, disabled (booked) |
| Alert | error, success, empty |
Expected output: test 6 of npm run test:system checks that each of these states appears with data-component and data-state
attributes. The starter's page shows only default states.
🌍Where it's used
- Design systems, which document every state of every component.
- QA checklists, where testers try each state.
- Payments, where a loading state prevents double charges.
📝Case scenario
A payment button had no loading state. On slow connections people pressed it twice and were charged twice. A loading state that disabled the button and said "Paying…", plus a check on the server, ended the double payments.
🖱️Try it
Make a state inventory for the details screen: list each component and mark which of the states above it needs. Success: at least six states marked, including loading for the "Book appointment" button.
⚠️Common mistakes
- Happy-path only. Sign: no loading or error designs. Fix: a state inventory.
- Hover without focus. Sign: mouse users see a change, keyboard users don't. Fix: design focus as its own state.
- Silent disabled buttons. Sign: people press and nothing happens. Fix: explain why, or let the press show a message.
🛠️For your project
Project 3's test 6 checks every state of four components on the component page.
✅Quick check
Name four component states besides default.
Show the answer
For example focus, selected, disabled and loading (also hover and error).
What does a loading state on a submit button prevent?
Show the answer
Double submissions, and uncertainty about whether anything is happening.