design-everyday-things

---
name: design-everyday-things
description: Use when a product feels confusing or unintuitive — apply affordances, signifiers, constraints, feedback, and conceptual models to diagnose discoverability and usability gaps.
category: Design
version: 1.0.0
tools: []
---

# Design of Everyday Things Framework

Foundational design principles for building products that are intuitive, discoverable, and understandable — applicable to physical products, software, and any human-designed system.

## Core Principle

Good design is harder to notice than poor design, because good designs fit our needs so well the design becomes invisible. When something fails, users blame themselves, but the fault is almost always in the design. Great design bridges what people want to do and what the product allows: it is discoverable (users can figure out what to do) and understandable (users can figure out what happened).

## Scoring

Goal: 10/10. Score 2 points per satisfied row of the Quick Diagnostic (5 rows: discoverability, evaluation, error recovery, mapping, constraints). Bands: 9-10 = users act without instructions, understand every outcome, and recover from any error; 5-6 = one gulf or error path is broken; ≤3 = users must consult a manual or routinely blame themselves. Report the current score and which diagnostic rows are failing it.

## The Two Gulfs

Every interaction requires bridging two gulfs. The **Gulf of Execution** is the gap between what users want to do and what the product lets them do ("How do I do what I want?") — bridge it with clear signifiers, natural mappings, constraints, and familiar conceptual models. The **Gulf of Evaluation** is the gap between what the product did and what users understand happened ("What happened? Did it work?") — bridge it with immediate visible feedback, clear system-state indicators, meaningful error messages, and progress indicators. The design goal is to make both gulfs as narrow as possible so action and understanding feel immediate.

## Seven Fundamental Design Principles

### 1. Discoverability
Can users figure out what actions are possible and how to perform them? Test: put a new user in front of the product — if they can't figure out what to do within 10 seconds, discoverability is broken. Anti-pattern: "the user manual explains it" — if users need a manual, the design failed.

### 2. Affordances
The relationship between an object's properties and a user's capabilities that determines how the object could be used. Affordances exist whether or not they're perceived — what matters for design is *perceived* affordance. Types: **real** (a button affords pressing), **perceived** (a raised area looks clickable), **hidden** (a right-click context menu), **false** (a decorative element that looks clickable but isn't), **anti-affordance** (a barrier that blocks action). Digitally: buttons afford clicking (signal with raised/colored/shadow/hover states), text fields afford input (signal with border/placeholder/label), scroll areas afford scrolling (signal with scroll bar/edge fade/partial content). Common failures: flat design erasing perceived affordances (button or label?), too-small touch targets, interactive and decorative elements that look identical.

### 3. Signifiers
Signals that communicate where an action should take place. Affordances determine what you CAN do; signifiers show WHERE and HOW. Types: **deliberate** ("Push" label on a door, placeholder text), **accidental** (a worn path in grass), **social** (a line of people indicating an entrance). Digitally: cursor change/hover state signals interactivity, icons + labels communicate function, color + position signal status/category/hierarchy (red = error, green = success; close button top-right). Design rule: when in doubt, add a signifier — better to over-communicate than leave users guessing.

### 4. Mappings
The relationship between controls and their effects. Natural mapping means the spatial layout of controls matches the layout of what they control — a volume slider where up means louder works; a light-switch panel or stovetop-knob row with no spatial correspondence fails. Digital principles: put controls near what they affect, mirror layout to content, match direction to expectation (scrolling down moves content up), group related controls. Techniques: proximity (edit button next to content), spatial (map controls matching compass directions), cultural (red = stop/danger, green = go/safe), sequential (steps 1, 2, 3 in natural order).

### 5. Constraints
Limiting possible actions to prevent errors. Types: **physical** (a USB plug only fits one way), **cultural** (red means stop), **semantic** (a rearview mirror only makes sense facing backward), **logical** (only one hole left for the last screw). Digitally: input validation restricts entry (date picker vs. free text), disabled states gray out unavailable options ("Submit" disabled until the form is valid), forced sequence with undo locks steps in order while allowing reversal (a wizard with locked steps; Gmail's "Undo send"). Design rule: every constraint added is one less error the user can make — make wrong actions impossible rather than punishing them.

### 6. Feedback
Communicating the results of an action back to the user. Feedback must be immediate (within 0.1s for direct manipulation), informative, appropriately dosed, and non-intrusive. Types: visual (button press animation, color change, checkmark), auditory (success chime, error sound), haptic (vibration on key press), progress (progress bar, spinner, skeleton screen). Response-time thresholds: 0.1s feels instantaneous; 1s is a noticeable delay (change the cursor); 10s loses attention (show a progress bar); beyond 10s users leave (show a percentage, allow backgrounding). Common failures: no feedback (did my click register?), delayed feedback (feels broken), unclear feedback, alert overload.

### 7. Conceptual Models
The user's mental model of how a product works. Three models exist: the **design model** (how the designer thinks it works), the **user's model** (how the user thinks it works), and the **system image** (what the product actually communicates) — the system image is the only bridge between the other two. Matching models let users predict outcomes and recover from errors; mismatches breed confusion, self-blame, and support calls. Example: a thermostat's design model is "set a temperature, the system maintains it," but a common wrong user model is "higher setting heats faster," leading users to crank it to 90°F. Build correct models with familiar metaphors (desktop, trash), visible system state, clear feedback, consistent behavior, and progressive disclosure.

## Human Error

Norman's key insight: there is no such thing as "human error" — only bad design. When someone errs, look for the design flaw, not the person's flaw.

**Slips** (correct intention, wrong action): action slip — wrong action on the right target (clicking "Delete" instead of "Edit"; fix: separate destructive actions); memory lapse — forgetting a step (forgetting an attachment after writing "attached"; fix: Gmail's attachment reminder); mode error — right action, wrong mode (typing in caps lock; fix: show mode state clearly); capture error — habit overrides intention (driving to the old office on autopilot; fix: interrupt at decision points).

**Mistakes** (wrong intention, executed correctly): rule-based — applying the wrong rule (fix: provide context, confirm); knowledge-based — an incomplete or wrong mental model (fix: build a better conceptual model); memory lapse — forgetting the goal or plan (fix: reminders, history).

Design for error by preventing it (constraints that make errors impossible, undo/redo everywhere, confirmation for destructive actions, sensible defaults, forgiving input) and by supporting recovery (clear error messages, never erase the user's work, partial saves, easy reset to a known-good state). Error message checklist: says what went wrong in human language, says how to fix it, doesn't blame the user, preserves the user's work, provides an alternative path.

## The Seven Stages of Action

Norman's model for how humans interact with products: (1) Goal — "I want to adjust the temperature"; (2) Plan — "I'll use the thermostat"; (3) Specify — "I'll press the up arrow"; (4) Perform — presses the button — *Gulf of Execution* spans stages 1-4; (5) Perceive — sees the display change; (6) Interpret — "the number went up"; (7) Compare — "is this what I wanted?" — *Gulf of Evaluation* spans stages 5-7. Support stages 1-3 with signifiers, mappings, and constraints; stage 4 with good affordances; stages 5-7 with feedback and visible state. Walk any interaction through each stage to find where users get stuck.

## Human-Centered Design (HCD) Process

Observation → Idea Generation → Prototyping → Testing → iterate. In Observation, don't ask users what they want (they don't know) — watch for workarounds and frustrations in real contexts. In Testing, use real users, not designers — 5 users reveal roughly 85% of problems, so prioritize observing behavior over collecting opinions and iterate.

## Common Mistakes

No signifiers (users can't find features → add visual cues for every interactive element). No feedback (users don't know if an action worked → respond within 0.1s). Blaming users (ignores design flaws → look for the design cause of every "user error"). Feature creep (complexity overwhelms → apply constraints, progressive disclosure). Inconsistency (breaks the conceptual model → same action should always produce the same result). Ignoring context (designed for ideal conditions → observe real usage environments).

## Quick Diagnostic

Audit any design against five questions: Can users figure out what to do? (If no: poor discoverability — add signifiers, improve affordances.) Do users understand what happened? (If no: gulf of evaluation too wide — add feedback, show system state.) Can users recover from errors? (If no: build in undo, forgiving input, clear recovery paths.) Do controls map naturally to their effects? (If no: fix the mapping so spatial layout aligns with function.) Do constraints prevent the wrong action? (If no: add constraints so the error becomes impossible.)