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.npx claudepluginhub hdeibler/universal-design-principles --plugin interaction-and-control-principlesProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Searches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.