By the end of this lesson you can
- Design the interactive states every control needs.
- Build interactive components so prototypes respond to hover and press.
- Show focus states clearly for keyboard users.
The idea
Interactive elements look different depending on what is happening to them. The common states are:
- Default: resting.
- Hover: a pointer is over it (desktop only, so never rely on it alone).
- Focus: selected by keyboard; needs a clearly visible indicator.
- Pressed or active: being clicked or tapped.
- Selected or checked: for toggles, tabs, checkboxes.
- Disabled: unavailable, ideally with a reason given nearby.
- Loading and error: for buttons that submit and fields that validate.
Interactive components
When states are variants in a component set, you can add interactions between the variants themselves: "while hovering, change to Hover", "on click, change to Pressed". Every instance then responds in prototypes without extra wiring.
Focus matters
Keyboard and switch users depend on the focus state to know where they are. Make it obvious, for example a 2px outline with an offset in a colour that contrasts with both the component and the background.
Why it matters in real projects
States are feedback: they tell people the interface noticed them. Missing states make products feel broken, and a missing focus state can make a product unusable for keyboard users. Designing states explicitly also prevents developers inventing their own inconsistent versions.
A realistic example
A developer asks what a checkbox looks like when it is focused and checked at the same time. The design only shows checked and unchecked.
The designer builds a checkbox set with properties for Checked (true, false, indeterminate) and State (default, hover, focus, disabled), adds an error version with a message, and wires interactive variants so it toggles on click in prototypes. The question never comes up again for that component.
Step by step
List states per component
For each control, write down every state it can be in.
Design focus first
Create a consistent, high-contrast focus style for all controls.
Build variants
Add each state as a variant value.
Add interactions
Wire hover, press and toggle between variants.
Test combinations
Check states that combine, such as focused and checked.
Document
Show a state matrix next to the component.
Common mistakes
Mistake No focus state.
Instead Design a clear focus indicator for every interactive element.
Mistake Disabled buttons with no explanation.
Instead Explain why nearby, or keep the button enabled and validate on submit.
Mistake Relying on hover to reveal information.
Instead Touch screens have no hover; make important things visible.
Check your understanding
Choose an answer, then check it. There is an explanation either way.
Practice exercise
Exercise · about 45 min
State matrix
Design a full state matrix for a text input.
Steps
- List states: default, hover, focus, filled, error, disabled, read-only.
- Build them as variants with labels and help text.
- Add focus interaction in a prototype.
- Check contrast of the focus indicator and error text.
Deliverable
A text input component with a documented state matrix.
Self-assessment
Tick each item when it is true of your exercise. Be honest; this is for you.
4 items
Summary
- Controls need default, hover, focus, pressed, selected, disabled, loading and error states.
- Focus is essential for keyboard users.
- Interactive components make prototypes respond automatically.
- Document states so nothing is invented later.
Further reading
Third-party sources, chosen for reliability. They open in a new tab.
- Focus visible (WCAG 2.4.7) (opens in a new tab)W3C WAI
- States (opens in a new tab)Material Design 3
Your notes
Marking complete updates your course and roadmap progress.