ConcertoNotes Physical constraints
Physical constraints prevent invalid actions through the structure of the design — the shape of a connector, the boundary of a screen, the channel of a slider. The user can't take the wrong action because the structure rejects it. Stronger than psychological constraints; not always available.
The three subtypes (from the book)
Paths
Channels that direct motion. The user can move along the path; off-path movement is impossible or rejected.
Software examples:
- Sliders constrain motion to one dimension.
- Range inputs constrain values to a defined min/max.
- Scroll bars constrain scrolling direction.
- Dropdown lists constrain selection to provided options.
<!-- Path constraint: value must be 0-100 -->
<input type="range" min="0" max="100" value="50" />
<!-- Path constraint: choice from fixed set -->
<select>
<option>Small</option>
<option>Medium</option>
<option>Large</option>
</select>
Axes
Rotary controls. Convert applied force into rotation; effectively infinite range in a small space.
Software examples:
- Rotation gestures in canvas tools.
- Color-wheel pickers that constrain hue selection to a circular path.
- Dial-style controls for continuous values.
Barriers
Block, slow, or redirect motion.
Software examples:
- Modal dialogs block interaction with content beneath.
- Disabled buttons block their action.
- Permission gates block access to features.
- Screen edges stop cursor motion (Fitts's edge advantage).
- Form-validation blocks prevent submission when invalid.
Patterns
Input-type constraints (paths)
<input type="email" /> <!-- only accepts email format -->
<input type="number" min="0" /> <!-- only non-negative numbers -->
<input type="date" /> <!-- only valid dates -->
<input type="color" /> <!-- only valid hex colors -->
The browser enforces the constraint; the user can't submit invalid data.
Drop-zone constraints (barriers)
A drag-and-drop interaction can constrain valid drops at the API level:
dropZone.addEventListener('dragover', e => {
if (isValidTarget(draggedItem, dropZone)) {
e.preventDefault(); // allow drop
}
// not preventing default = drop won't fire
});
The browser's drag-and-drop API itself uses constraint: preventDefault opens the channel; absence keeps it blocked.
Modal as barrier
<dialog open>
<h2>Required action</h2>
<p>You must complete this step before continuing.</p>
<button
</dialog>
The dialog blocks interaction with the page beneath. Use sparingly; barriers irritate when they don't serve a clear purpose.
Disabled state (block)
<button id="submit" disabled>Submit</button>
The button can't trigger its action until enabled. Pair with explanation of what would enable it.
When to use physical over psychological
- When the consequence of the wrong action is severe (data loss, security breach, irreversible operation). Physical constraints are stronger.
- When the user is novice or the system is unfamiliar — psychological constraints rely on prior knowledge that may not exist.
- When there's no acceptable failure mode — make the wrong action impossible.
When physical constraints over-restrict
- Format constraints stricter than necessary — phone fields that reject parentheses; name fields that reject apostrophes.
- Hardware-style barriers in software contexts — a modal that blocks because of a non-blocking concern.
- Disabled states that don't explain themselves — user can't act and doesn't know why.
The discipline: constrain real requirements; explain when surprises occur.
Resources
- Norman, D. The Design of Everyday Things (1988, 2013).
- Lidwell, Holden & Butler (2003).
- WCAG — input-type and validation constraints contribute to accessibility.
Related sub-skills
constraint(parent).constraint-psychological— the other half; symbols, conventions, mappings.affordance— affordance + constraint = the action space.accessibility-operable— physical constraints must be operable across assistive technologies.