About interface-affordances
Interface Affordances is a design skill for reviewing whether interface actions are perceptible and behave as their visual cues suggest. It provides checks for pointer, touch, keyboard, and assistive-technology use.
Key features
- 01Align visual cues with behaviour
- 02Keep essential actions visible without hover
- 03Review targets for each input method
- 04Check pressed, selected, and disabled states
- 05Verify accessible names, roles, and states
Use cases
- 01Reviewing discoverability of interface controls
- 02Checking touch and keyboard interaction cues
- 03Auditing disabled and loading controls
- 04Evaluating accessible control labels and states
Install
Copy the command and run it in a terminal.
$
npx skills add https:/After installing, type/interface-affordancesin Claude Code to confirm it loaded.
Details
From the project READMEInterface 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
Comments
Markdown supported