From interaction-and-control-principles
Use this skill when the design has interactive capability but users aren't *seeing* it — when the affordance is technically present but the signifier (the visible cue that tells users "you can do this") is missing or weak. Trigger when reviewing flat-design UIs where everything looks the same, when designing custom controls, when stakeholders ask "should this be more obvious?", or when picking signifier strength for primary vs. secondary actions. Sub-aspect of `affordance`; read that first.
How this skill is triggered — by the user, by Claude, or both
Slash command
/interaction-and-control-principles:affordance-signifiersThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
In Norman's later refinement (2008), he distinguished *affordance* (the underlying possibility — a button can be pressed) from *signifier* (the visible cue that tells the user about the affordance — the button looks pressable). The distinction matters because designers control signifiers; affordances often exist regardless. A button that's missing a signifier still affords pressing — but no one...
In Norman's later refinement (2008), he distinguished affordance (the underlying possibility — a button can be pressed) from signifier (the visible cue that tells the user about the affordance — the button looks pressable). The distinction matters because designers control signifiers; affordances often exist regardless. A button that's missing a signifier still affords pressing — but no one knows.
Every interactive element should carry one or more signifiers. The strongest are perceivable preattentively (within the first 200ms of viewing) without conscious thought.
cursor: pointer). Desktop only.For new-user surfaces, lean on strong signifiers. For dense expert tools, medium signifiers are acceptable because users develop spatial memory.
A useful rule: signifier strength should match the action's importance and consequence.
Primary action (Submit, Buy, Continue)
→ Strongest signifier: filled background + brand color + cursor + hover
Secondary action (Cancel, Save Draft)
→ Medium signifier: outlined border + cursor + hover
Tertiary action (Help, More info)
→ Lighter signifier: text-only + color + underline on hover
Destructive action (Delete, Remove)
→ Different signifier: distinct color (red) + cursor + hover, often after a confirmation step
When the primary action has the same signifier as the tertiary, the user doesn't know which is most important. Signifier strength is a hierarchy decision.
Static signifiers tell the user "this is interactive." Response signifiers tell them "you've engaged it."
outline: 2px solid var(--ring); outline-offset: 2px).cursor: not-allowed.These should layer. A button with a strong static signifier should still respond to hover and focus.
.btn {
/* static signifier */
background: hsl(220 90% 50%);
color: white;
padding: 8px 16px;
border: 0;
border-radius: 6px;
cursor: pointer;
transition: background 100ms;
}
.btn:hover { background: hsl(220 90% 45%); }
.btn:focus-visible {
outline: 2px solid hsl(220 90% 50%);
outline-offset: 2px;
}
.btn:active { background: hsl(220 90% 40%); }
.btn[disabled] {
background: hsl(0 0% 92%);
color: hsl(0 0% 50%);
cursor: not-allowed;
}
Five distinct states; each communicates something different. Stripping any of them weakens the signifier system.
cursor: grab on hover, cursor: grabbing on active.affordance (parent).affordance-false-and-anti — the inverse problem: when signifiers suggest interactivity that isn't there.hierarchy (perception) — signifier strength is a hierarchy decision.accessibility-perceivable (process) — signifiers must be perceivable across abilities.feedback-loop — response signifiers (hover, focus, active) are micro-feedback.Guides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.
Dispatches multiple subagents concurrently for independent tasks without shared state. Use when facing 2+ unrelated failures or subsystems that can be investigated in parallel.
npx claudepluginhub hdeibler/universal-design-principles --plugin interaction-and-control-principles