SKILL.md
Interface Affordances
Affordances make possible actions perceptible. If people cannot tell what they can do, the interaction is incomplete even when the code works.
Defaults
- Visual cues must match real behaviour.
- Critical actions cannot depend on hover alone.
- Hit targets and spacing should match the input method.
- State changes should explain themselves (pressed, selected, expanded, disabled, loading).
- Decorative motion must not impersonate an affordance.
Prefer / Reject
| Prefer | Reject |
|---|---|
| Persistent cues for primary actions | Hover-only discovery of essential controls |
| Clear pressed/selected/expanded states | Identical resting and active styles |
| Cursor/keyboard/touch-appropriate targets | Tiny click areas with large visual icons |
| Disabled styles that also disable behaviour | Greyed-out controls that still fire handlers |
| Labels that name the action | Icon-only controls with no accessible name |
Checks by input mode
- Pointer: hover can enrich, not gate, essential actions.
- Touch: provide visible tap targets and avoid hover-dependent UI.
- Keyboard: focus styles are part of the affordance, not an afterthought.
- AT: names, roles, and states expose the same possibilities the visuals claim.
Review checklist
- Can a new user tell what is interactive?
- Does every interactive element have a perceptible state change?
- Are essential actions visible without hover?
- Do icons have names?
- Do disabled and loading states look and behave disabled/loading?
- Could reduced-motion or touch users still discover the action?
Source essays
- On affordances
- Ten principles for product delight
- On reduced motion