Menu

Individual skill

constraint

Use this skill whenever the design must structurally prevent invalid actions — input validation, disabled states, required fields, type-restricted inputs, mode locks, role-based gates, hardware lockouts. Trigger when designing forms, picking input types, designing destructive flows, gating multi-step procedures, or thinking about how to prevent a class of errors from being possible at all. Constraint is one of the foundational principles in 'Universal Principles of Design' (Lidwell, Holden, Butler 2003) and one of the strongest design moves available — preventing wrong actions is more powerful than detecting them after the fact.

plugins/HDeibler/universal-design-principles/plugins/interaction-and-control-principles/skills/constraint/SKILL.md

Read pinned source

Source commit d780783eba4ecc7c8b9429f95c9362df95f07c61

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Network or broad shell
Last checked
Nov 4, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
1,537
Repository last updated
Nov 7, 2026
License
Apache-2.0

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Constraint

A constraint is anything that limits the actions a user can perform on a system. Some constraints are physical (you can't insert a USB-C connector upside-down because the shape rejects it). Some are psychological (you don't try to push a door labeled "PULL" because the convention overrides the impulse). Both kinds work upstream of error: instead of catching wrong actions after they happen, constraints make wrong actions hard or impossible.

## Definition (in our own words)

A constraint is a deliberate limitation on what the user can do. The limitation may be implemented in the physical structure of the design (a slot that only accepts one shape), in the system's software (a button disabled until preconditions are met), or in the user's psychology (a convention that makes the wrong action feel obviously wrong). All three reduce error rates dramatically — constraints are usually cheaper than recovery, because they prevent the recovery from being needed.

## Origins and research lineage

- **Donald Norman**, *The Design of Everyday Things* (1988). Introduced constraints as one of the central tools for usable design. Norman distinguished four types: *physical, semantic, cultural, logical*. Lidwell, Holden, and Butler simplify to two (physical and psychological), with psychological encompassing semantic, cultural, and logical.
- **Lidwell, Holden & Butler** (2003) compactly distinguish:
  - **Physical constraints**: paths (channels that direct motion), axes (rotary controls), barriers (block undesired actions).
  - **Psychological constraints**: symbols (semantic communication), conventions (learned practices), mappings (perceived control-effect relationships).