Version: 1.0 Status: Normative Scope: Interactive software interfaces across all form factors (desktop, mobile, tablet, wearable, automotive, spatial), applicable by extension to any designed artifact (physical products, environments, signage systems).
Normative language: The key words MUST, MUST NOT, SHALL, SHOULD, SHOULD NOT, MAY are to be interpreted per RFC 2119. Requirements are individually numbered (P-x.y for strategic principles, C-x.y for cognitive/perceptual principles, T-x.y for trade-off resolution rules, V-x.y for verification procedures) to permit traceability in design reviews.
- 0.1.1 The artifact under specification is a human interface. The term dates to 1978 in Apple's documentation lineage (the Human Interface Guidelines). The distinction is substantive, not cosmetic:
- User is clinical and anonymizing; it defines a person solely by their relation to the interface.
- Human encodes both fallibility (imperfection, error, fatigue, distraction — "I'm only human") and the highest qualities designers must serve (kindness, compassion, generosity, dignity).
- 0.1.2 Consequence: error tolerance, forgiveness, and emotional consideration are first-class requirements, not accommodations.
- 0.2.1 The goal of interface design is NOT to produce a beautiful, well-organized, simple, or focused app. Those are instrumental properties. The terminal goal is serving human beings — positively affecting the lives of the people who use the product.
- 0.2.2 The single evaluative criterion that dominates all others: how well does the artifact satisfy the emotional and practical needs of the people it is designed for?
- 0.2.3 Design is making something with intention. It is not merely how something looks, nor merely how something behaves; both definitions are incomplete. Design is the deliberate selection of what matters most to people and the concentration of effort there.
- 0.2.4 Every feature added to a product asks something of the person using it: their time, their attention, and their trust. These are scarce, non-refundable resources. Therefore choosing what to build is substantially a matter of deciding what not to include (see §1 Purpose, §6 Simplicity, §14 Progressive Disclosure).
Every well-designed interface MUST provision for all four needs. Each need maps onto specific principle clusters in this specification:
| # | Need | Definition | Principle clusters that satisfy it |
|---|---|---|---|
| N1 | Safety & predictability | People must be able to predict the consequences of their actions; the system must feel stable, solid, trustworthy | Wayfinding (§9), Feedback (§10), Consistency (§12), Mental Models (§13), Agency/forgiveness (§2), Responsibility (§3) |
| N2 | Knowledge, meaning & understanding | People must be able to make informed choices via clear, helpful information | Visibility (§11), Feedback (§10), Mapping (§15), Affordance (§16), Simplicity/clarity (§6) |
| N3 | Task accomplishment | People must be able to achieve personal and professional goals via streamlined, efficient workflows | Purpose (§1), Agency (§2), Progressive Disclosure (§14), Proximity/Grouping (§17), Flexibility (§5) |
| N4 | Beauty & joy | The experience must be aesthetically pleasing, enjoyable, and (at its best) delightful | Symmetry (§18), Craft (§7), Delight (§8) |
- 0.3.1 When an interface satisfies all four needs, users perceive the humanity of the people who designed it — the sense that every element exists for a purpose, everything is understandable, and full consideration was given to their needs. This perception is the empirical signature of successful design.
- 0.4.1 These principles express core truths about human perception, cognition, decision-making, and communication. They are universal and timeless: they apply equally to graphic design, architecture, interior design, retail design, landscape design, automotive design, and interactive software.
- 0.4.2 Principles specify why design decisions should be made, not how to execute them. Technique and process are downstream; principles are the foundation.
- 0.4.3 There is no formula — no fixed combination of principles guaranteeing an optimal solution. Principles are tools for weighing competing priorities. Leaning into one principle can compromise another (see §19 Trade-offs). Resolution requires designer judgment and intuition; this irreducibility is inherent to the discipline.
- 0.4.4 The most profound principles are often the simplest. Apparent obviousness does not diminish normative force; the recurring practical failure of "obvious" principles (grouping, feedback, visibility) in shipped products demonstrates that conscious, disciplined application is required.
Eight principles form the strategic layer: Purpose, Agency, Responsibility, Familiarity, Flexibility, Simplicity, Craft, Delight. They govern what to build and the ethical/experiential posture of the product. Part II (§9–§18) supplies the perceptual-cognitive mechanics that implement them.
Definition: Design starts with intention. Identify what matters most to the people you're designing for; focus on making those things great; the result is an experience people truly value.
- P-1.1 (Create value). The design process MUST maintain constant orientation toward what makes the product genuinely useful. At every development stage, the team MUST be able to answer: What is this product for? Does the current design serve that purpose?
- P-1.2 (Keep focused). The product MUST prioritize its most important features by aligning with how people actually want to use it, and concentrate quality investment there. A product with a clear use is measurably more effective at helping people meet goals than a diffuse one.
- P-1.3 (Differentiate deliberately). Teams MUST investigate existing solutions and MUST NOT re-create them without cause. The design MUST reflect an articulated answer to: What sets this product apart? How does the design express that?
- P-1.4 (Subtractive scoping). Because every feature consumes user time, attention, and trust (§0.2.4), feature selection MUST include explicit exclusion decisions. "What are we not building?" is a required design artifact, not an implicit byproduct.
- P-1.5 (Purpose precedes production). Purpose evaluation MUST occur before sketching or implementation — "before you draw a single sketch or write a line of code."
- Feature accretion without value analysis.
- Cloning competitor functionality absent differentiation rationale.
- Justifying features by internal stakeholder demand rather than user value.
Definition: An interface exists to help people accomplish their goals. Give them freedom to act, keep them informed, and make recovery from mistakes trivial. People are measurably more engaged when they control their own experience.
- P-2.1 (Stay out of the way). The design MUST route people directly to the task or content at hand. The best designs are unobtrusive, present only when needed.
- P-2.2 (Freedom to explore). People MUST be able to move through the interface and access features without being locked into prescribed flows or modes. Where a guided flow (onboarding, wizard) is genuinely necessary, it MUST be skippable/escapable so people reach the main experience quickly.
- P-2.3 (Self-paced entry). Rather than forcing a predetermined path, the design SHOULD let people dive directly into the experience and decide what to explore at their own pace.
- P-2.4 (Forgiveness — undo). Every user action SHOULD be reversible. People accidentally send, change, and delete things constantly; undo MUST be easy and MUST NOT cost the person time or work to invoke. Knowledge that any action can be reversed is what makes people feel capable, secure, and free to explore — forgiveness is the mechanism by which agency produces confidence.
- P-2.5 (Forgiveness — destructive confirmation). Before an irreversible or destructive action, the interface MUST double-check intent. Interruptions are permissible ONLY at this threshold — reserved for genuinely large mistakes — and MUST be used sparingly (interruption fatigue destroys their protective value).
- P-2.6 (Informed control). The system MUST keep people informed about what is happening (implemented via the Feedback machinery of §10).
- Modal funnels with no escape hatch.
- Confirmation dialogs on trivial actions (cry-wolf degradation of P-2.5).
- Irreversible operations without prior warning or subsequent recovery path.
Definition: The work has real impact on people's lives. Trust is earned by prioritizing safety and privacy and by transparency about what the product does and why.
- P-3.1 (Transparency from first contact). The product's intentions MUST be clear from the very first interaction; the relationship begins there.
- P-3.2 (Contextualized permission requests). Permission prompts MUST NOT be fired at launch before the person has understood what the app does. Requests for personal data MUST wait for the contextually right moment, MUST be accompanied by a clear rationale, and MUST ask only for what is necessary. (Reference model: the untrusted stranger demanding your phone number before explaining why — an interface behaving this way forfeits trust exactly as a person would.)
- P-3.3 (Data minimization & disclosure). Collect ONLY what the product needs to function; be explicit about what is collected and how it is used; handle it with care. Privacy is treated as a human right, not a preference.
- P-3.4 (Adversarial self-audit). For each feature, the team MUST answer: How could this feature be misused? Who would be harmed by it? How do we prevent that? Protections against abuse and unintended consequences MUST be designed in, anticipatorily.
- P-3.5 (Protection scope). Responsibility extends to anyone using the product AND anyone who could be affected by it (second-order harm).
- P-3.6 (AI/ML-specific safeguards). When integrating generative or intelligent features, the design MUST anticipate that models can produce unexpected or inaccurate output. Canonical hazard case: a recipe app where a person has logged an allergy — the model may suggest an allergenic ingredient, causing real-world physical harm; this failure mode MUST NOT be left to chance. Mandatory mitigations, in escalating order: previews, confirmations, disclaimers; and if residual risk to safety outweighs feature value, the feature MUST be removed entirely.
- Launch-time permission barrages.
- Rationale-free data collection ("I'll tell you once you give me your phone number").
- Shipping model-generated output into safety-relevant contexts without human-verifiable checkpoints.
Definition: People arrive with a lifetime of experience — knowledge of the physical world and conventions learned from other software. Drawing on both makes an interface feel immediately intuitive. Ground the experience in established physical and digital patterns and apply them consistently.
- P-4.1 (Metaphor as knowledge transfer). Interfaces SHOULD use metaphor to let people import real-world understanding. Canonical example: the trash can — unwanted items go in; mistakes are retrievable from it; both behaviors mirror the physical referent, so the mapping "instantly clicks."
- P-4.2 (Metaphor calibration). Metaphors MUST be calibrated between two failure poles:
- Too literal: the representation drags in irrelevant physical detail; people may not recognize what the interface is actually showing (e.g., an inspector rendered as a photorealistic object).
- Too abstract: the idea fails to transmit at all. A correct metaphor draws on something known AND lets people predict what it will do.
- P-4.3 (Metaphor integrity). A conventional symbol MUST NOT be repurposed. Using a trash-can icon for anything other than delete violates accumulated cross-software familiarity; equally, taking creative liberty with the delete glyph forfeits immediate recognition. For common actions: do not reinvent the wheel; use the established metaphor and make it do exactly what people expect.
(Full consistency mechanics in §12; the strategic layer requires:)
- P-4.4 (Look ⇒ behavior invariance). Things that look the same MUST behave the same. If visually identical buttons variously navigate, toggle, and open modals, no learnable pattern exists.
- P-4.5 (Placement invariance). Recurring actions MUST occupy consistent locations across screens and devices (e.g., macOS window-close is always top-left). Consistent placement eliminates search cost — people stop having to think about it.
- P-4.6 (Feedback conventionality). Use system-standard patterns for alerts, choices, and state changes so feedback itself is familiar (bridges to §10).
- P-4.7 (Scope of expectation modeling). Designers cannot directly observe users' prior experience, but MUST make informed inferences: expectations derive primarily from (a) similar apps in the domain and (b) other apps on the same platform. Platform conventions — iconography, terminology, navigation schemes, common task workflows — are therefore binding defaults (see C-12.4, the share-glyph case).
- Cross-platform self-consistency prioritized over platform-native convention (rational but wrong — §12.4).
- Novel glyphs/terms for solved concepts.
- Familiar-looking elements with unfamiliar behavior (see the Mortimer faucet, §13.4 — the most dangerous familiarity failure: visual similarity promising behavioral similarity that is then violated).
Definition: People use software in ways as unique as they are. The more the design acknowledges this, the more people feel welcome. Support diverse devices, interaction types, contexts, and perspectives.
- P-5.1 (Context multiplicity). The design MUST accommodate the distinct situations people actually occupy. Reference model — music listening: at home via speakers; running via AirPods + Watch (glanceable, minimal); driving via a fully hands-free experience. Each context receives an interaction model fitted to it.
- P-5.2 (Per-device intentionality). Each supported platform MUST receive a solution exploiting what makes that hardware unique: iPhone → quick touch-based interactions; Mac → deep workflows and precise pointer control. The product must feel polished and at home wherever it runs — equal care per platform, no least-common-denominator ports.
- P-5.3 (Context preservation across transitions). As the design adapts across platforms and configurations, content and controls MUST remain in consistent, predictable positions, with natural animations easing transitions, so the person's context survives the move.
- P-5.4 (Audience analysis). Teams MUST actively characterize their audience: age range, languages, expertise (pro vs. novice), reliance on accessibility features.
- P-5.5 (Accessibility as a start-of-project priority). Accessibility MUST be treated as a priority from the start, not retrofit. Inclusive design reaches the broadest audience and empirically improves the experience for all users. Complete coverage on day one is not required, but a continuing inclusivity examination is.
- P-5.6 (Input-method plurality). Design for as many input modalities as possible — voice, touch, keyboard, pointer, and beyond — so each person can use the product the way that works best for them.
- P-5.7 (Personalization where no single optimum exists). When no single layout/configuration can serve everyone (e.g., control arrangements), the design SHOULD let people rearrange controls to fit personal workflow and hide controls they never use. Flexibility is an investment; its return is demonstrated care ("you designed with them in mind").
- One-size interface shipped identically to phone/tablet/desktop.
- Accessibility as post-hoc compliance pass.
- Rigid control layouts in expert tools with heterogeneous workflows.
Definition: A well-designed experience removes the unnecessary; every element earns its place. Logical organization plus straightforward navigation ⇒ easier task completion.
- P-6.1 (Simplicity ≠ minimalism). Explicitly distinguished: burying all functionality in a single hidden location makes an interface look minimal but not be simple. Simple = frictionless + intuitive: people find what they need without effort. (Cross-reference: hiding navigation in a hamburger menu reduces clutter while destroying usability — §11.3.)
- P-6.2 (Concision — language). Interface copy MUST use plain language, strip jargon, avoid redundancy, and get to the point. Choose exactly the words needed to convey a concept or label a control; the simplest phrasing is typically the most universal and most helpful.
- P-6.3 (Concision — steps). Respect people's time: minimize the number of steps to task completion.
- P-6.4 (Clarity via hierarchy). Clarity MUST be constructed with hierarchy — order, spacing, and contrast guiding attention to what matters most. Test: the most important item on screen is always the most visually obvious one. A clear interface answers, without instruction: What do I pay attention to? What can I interact with? How do I interact with it?
- P-6.5 (Element justification). Every element MUST earn its place. Required distillation pass: Which information can be reduced to its essence? Would complex data communicate better as a graphic? Can information be summarized so people focus on what they care about? Every surviving element must clarify the point.
- P-6.6 (Additive simplicity). Sometimes simpler means adding information. Reference case: the video play/pause control — on return, the person needs context; adding position and time-remaining makes the control simpler to use because it supports informed decisions. Simplicity is measured against the person's task, not element count.
- P-6.7 (Termination criterion). You have arrived at simplicity when you have exactly enough — the focused, useful experience that keeps important things close and lets the rest fall away.
- Minimalism theater (hidden ≠ simple).
- Jargon-dense labels; redundant copy.
- Flat visual hierarchy forcing serial scanning.
Definition: The design reflects how much you care; it demonstrates dedication to the best possible experience. Take the time to do the work well.
- P-7.1 (Quality sets the tone; craft signals trust). People detect corner-cutting instantly — the software analog of the rickety door or the shirt that unravels: laggy button responses, jittery scrolling, misaligned icons, layouts that break on rotation. Such fragility makes people question the quality of the results the product will give them. Meticulous craft does the opposite: it inspires confidence. Perceived integrity generalizes from surface to substance.
- P-7.2 (High-quality materials). The concrete ingredient list: typefaces that render beautifully across devices; color systems that adapt seamlessly across light/dark environments; clear graphics and iconography; responsive animations that feel fluid and deliver immediate, natural feedback; all built on reliable, secure SDKs/foundations.
- P-7.3 (Deliberateness). Every decision MUST be deliberate; strive for stunning visuals, smooth animation, precise wording, thoughtful audio.
- P-7.4 (Iteration discipline). Craft emerges from iteration: prototype early; try new approaches; be willing to discard what doesn't work; set a high bar per feature, refine, repeat. Products MUST be tested in real-world settings for durability, reliability, and performance.
- P-7.5 (Maintenance — shipping isn't the finish line). Craft is an ongoing commitment. The interface MUST be kept current with new platform capabilities and design patterns; when new features or hardware appear, evaluate their fit. A product that evolves makes people feel supported and rewarded; great design has longevity because it is maintained.
- P-7.6 (Internal-consistency as craft evidence). Cohesion (matched glyph styles, restrained type ramp — §12.6) gives people a deeper sense of product integrity; they intuitively — and correctly — infer that choices were deliberate, because consistency requires self-control and restraint.
- Shipping on schedule at the cost of jank (perceived fragility → distrust in results).
- Set-and-forget releases that decay against evolving platform conventions.
Definition: People remember how a product makes them feel. Choose the emotions appropriate to the experience and deliver them in a way that is satisfying, enriching, and a joy to use.
- P-8.1 (Emotion as design input). Not all software should feel the same. The team MUST identify the target emotion — a fitness app might energize, a meditation app calm, a game thrill; alternatively relaxed / confident / excited — and let that emotion shape design decisions throughout, reinforced at every opportunity.
- P-8.2 (Defining moments). Every interaction — from a button press to an error message — is a candidate moment to express the product's character. Evaluate each for the opportunity to add a touch of character reflecting the design's spirit.
- P-8.3 (Delight ≠ decoration). Delight MUST NOT be implemented as confetti or flourishes tacked on at the end of the process. People are trying to accomplish tasks; pursuit of delight for its own sake MUST NOT obstruct core purpose. Aesthetic register varies: some designs want a considered practical touch, others whimsy — experiment to find the balance.
- P-8.4 (Delight as emergent sum). Delight is the culmination of everything a person experiences: freedom to act (§2), safety to explore (§2.4/§3), comfort of familiar metaphors (§4), flexibility across contexts (§5). It is the natural result of getting all other principles right — the sum of the consideration invested. It cannot be bolted on; it emerges from intent, focus, and care.
- P-8.5 (Humanity as micro-behavior). Delight frequently manifests as small, human inferences. Reference case: entering "June 31" (a nonexistent but commonly attempted date) — the well-designed system neither errors nor warns; it silently corrects to July 1. Subtle, brilliant, and "a very human thing to do" (cross-listed as error-prevention, C-10.17).
- Terminal-phase "delight pass" (animation/confetti sprinkling).
- Character flourishes that add steps to core tasks.
- Uniform emotional register regardless of product domain.
Ten principle clusters govern how interfaces are perceived, learned, and operated: Wayfinding, Feedback, Visibility, Consistency, Mental Models, Progressive Disclosure, Mapping, Affordance, Proximity & Grouping, Symmetry. Each is grounded in a real-world reference system demonstrating its universality.
Reference system: Airport signage. Airports serve people who are tired, jet-lagged, rushed, and stressed; their signage must therefore be maximally robust. The progression: approach signs → terminal signs → terminal-content detail → gate directions → gate confirmation → adjacent-gate redirection → emergency/exit marking.
A wayfinding system helps people navigate complex environments quickly and successfully, and is critical to feeling oriented and safe (Need N1). Correct systems exhibit all five properties:
- C-9.1 (Comprehensive location inventory). Offers a complete, understandable list of the general locations available.
- C-9.2 (Location detail). Provides needed detail about what each location contains.
- C-9.3 (Contextual specificity gradient). Is highly contextual — becomes increasingly specific as the person navigates deeper into the system.
- C-9.4 (Self-location). Clearly highlights current location relative to other locations.
- C-9.5 (Exit path). Provides a clear route out. The ability to return to somewhere familiar and start over is itself a comfort function — it underwrites exploratory confidence (couples to Agency P-2.2/P-2.4).
Every screen MUST answer all five; unanswered questions produce the subjective state of being lost:
- Where am I?
- Where can I go?
- What will I find when I get there?
- What's nearby?
- How do I get out?
The interface is one large wayfinding system. Canonical element→question mapping:
| Element | Question(s) answered |
|---|---|
| Navigation-bar title | Where am I? |
| Selected tab-bar item state | Where am I? |
| Tab bar + content area | Where can I go? What's nearby? |
| Simply rendered, recognizable tab glyphs + understandable labels | What will I find when I get there? |
| Back button | How do I get out? (and secondarily: what region of the app am I in?) |
- C-9.6 (Per-screen audit). REQUIRED verification: iterate through the app one screen at a time; score each screen against all five questions; any screen failing any question is defective and MUST be reworked (see V-20.1).
Reference system: Automobile interiors. Vehicles are two-ton objects moving at high velocity, operated by potentially tired people on unfamiliar roads; feedback is therefore engineered as a safety-critical channel and must be clear, immediate, and understandable. Interfaces inherit the same taxonomy and the same quality bar.
| Class | Function | Automotive exemplars | Interface exemplars |
|---|---|---|---|
| Status | Continuous state disclosure | Gear indicator (displayed twice: shifter + instrument cluster — redundancy proportional to criticality); fuel level (supports range prediction); speedometer (supports norm compliance) | Mail unread badges (read-prioritization); Calendar attendee-decline indicators (reschedule decisions); Camera recording state — three simultaneous cues: red dot + incrementing timecode + record-button state |
| Completion | Confirms an action succeeded (or visibly failed) | Engine start = audible turnover + felt vibration + cluster illumination (tri-modal); tactile detents traversing P→D; automatic door-lock click (feedback more important because action was automatic) | Lock sound on iPhone; mark-as-unread animation; delete animation; Apple Pay success = animation + sound (deliberately unmissable for a high-stakes action) |
| Warning | Pre-error anticipation | Low fuel / low brake pads / low oil — via indicator lamps, cluster messages, sounds, or all of the above; protects both person and machine | Inline form validation (real-time disclosure of acceptable values → course-correction before the error exists) |
| Error | Reports a failed operation | Start attempt with empty tank → explicit error message | Validation failures; operation errors |
- C-10.1 (Universality of completion feedback). EVERY action taken in the interface MUST produce some form of confirmation feedback. This is the mechanism by which the system says "it's all good — I'm doing exactly what you wanted," which releases the person's cognitive resources for their next task (the driver checks the mirror, not the door locks).
- C-10.2 (Discretion with salience). Completion cues SHOULD be discrete and non-invasive yet hard to ignore. Salience MUST scale with stakes (payment ≫ mark-unread).
- C-10.3 (Multimodal redundancy for critical state). State whose misreading is dangerous (gear position; recording status; payment) MUST be rendered through multiple simultaneous channels/locations.
- C-10.4 (Automaticity raises the bar). When the system acts autonomously (auto-lock, auto-save, auto-sync), feedback becomes MORE important, not less — the person had no initiating action to anchor their expectation.
- C-10.5 (Predictive status). Status displays SHOULD support forward inference (fuel → range; progress → completion time), not merely present-state readout.
- C-10.6 (Prevention over reporting). Errors are always disappointing and frustrating; the design hierarchy is: prevent (warnings, inline validation, constrained inputs) ≻ recover ≻ report.
- C-10.7 (Inferential correction). Where user intent is confidently recoverable from an erroneous input, the system SHOULD infer intent and do something reasonable rather than erroring — the June 31 → July 1 correction (P-8.5). No error dialog, no warning; just the humane repair.
- C-10.8 (The four feedback questions). Feedback collectively answers: What can I do? What just happened? What is currently happening? What will happen in the future?
- C-10.9 (Static-screen fallacy). Most feedback deficiencies trace to designing against static screens, losing sight of the fact that interaction is a temporal, turn-taking process with continuous back-and-forth.
- C-10.10 (Design-as-conversation). Good feedback is a conversation with the person who designed the product: the designer's channel for answering the person's unspoken questions, reporting how they're doing, and guiding them. Required design stance: imagine being in the room with the person — what would you say, and how?
- V-10.1 (Explain-the-design gap analysis). Procedure: (1) Recruit someone who has never used the app. (2) Have them think aloud — what they believe, what's unclear, what confuses. (3) Then explain to them how the app actually works, guiding attention. (4) Diff the explanation against what the interface itself communicates. Empirical regularity: the verbal explanation is far clearer than the design; the delta is the feedback specification the interface is missing. Humans communicate better in person — capture that content and encode it into the interface.
Definition: Usability improves greatly when controls and information are clearly visible. Deliberately obvious; systematically violated.
- C-11.1 (Feedback dependency). Visibility is the transport layer for §10: good feedback that isn't seen has no effect.
- C-11.2 (Instrument-cluster standard). The reference case embraces clutter: text, numbers, moving gauges, blinking lamps, status indicators — all deliberately positioned directly in the line of sight, readable without moving head or body, because the information is operation-critical. Relocating or hiding it would cause critical feedback to be ignored.
- C-11.3 (Surfacing rule). Key status information MUST surface at the highest reasonable hierarchy level. Mail badges: deleting them looks cleaner but forces navigation into every message to recover the same information — grossly inefficient and tedious. Clock-app tab bar: burying navigation in a hamburger menu hides the app's functional range beyond the current view.
- C-11.4 (Explicit trade-off clause). Visibility is NOT absolute: densely packed interfaces can overwhelm and slow decision-making, especially for novices. Visibility MUST be weighed against Simplicity (§6) and Progressive Disclosure (§14) per the resolution rules of §19.
Reference system: Automotive conventions — a shared, industry-wide design vocabulary: symbols (door lock, window, fuel, headlights, battery, oil), terminology (park / drive / reverse), and control configuration (brake left, accelerator right). Because of this, nobody relearns driving per vehicle. Inverse formulation (often the clearer one): inconsistency undermines usability.
- C-12.1 (Expectation source). People's expectations come from the other software they use — primarily (a) similar apps and (b) apps on the same platform. Exact priors are unknowable; informed inference is mandatory (P-4.7).
- C-12.2 (Binding conventions). Platform iconography, terminology, navigation schemes, and common task workflows are binding defaults.
- C-12.3 (Deviation clause). Innovation is genuinely encouraged — it's how progress happens — but inconsistency in simple things (icons, labels) trips people. Deviate ONLY with strong justification.
- C-12.4 (Case study — the share glyph). iOS represents "action/share" as an arrow pointing up out of a box. A different, widespread glyph (common on the web/other platforms) is a perfectly good symbol — but it is not what iOS users know best. Teams adopt it to stay consistent across their own platforms/website: a rational, reasonable decision that is nonetheless wrong, because the governing frame is the user's familiarity, not the org chart's. Cross-platform self-consistency < platform-native user consistency.
- C-12.5 (Cohesion requirements). Controls share a matching look and feel; glyphs share one visual style; typography restricted to a limited set of faces, sizes, and colors.
- C-12.6 (Integrity signal). Internal consistency makes the product feel cohesive/whole; people intuitively (and correctly) infer deliberate, thoroughly considered choices — because consistency demonstrably requires self-control and restraint (feeds Craft P-7.6).
- C-12.7 Look-alikes MUST behave alike (P-4.4). Recurring actions in fixed locations (P-4.5). Established appearance/behavior, once set, MUST be applied throughout — this is how people learn quickly and trust that new interactions will work as expected.
- C-13.1 (Mental model). For every system a person has ever used, they carry an internal model representing it as parts + functions + behaviors. Properties: (a) an oversimplification — never captures full internal workings; (b) experience-dependent — sophistication grows with exposure; (c) built from an incomplete set of facts; therefore (d) unique per individual.
- C-13.2 (System model). The sub-model of how the system works. Faucet reference: two independent supply lines (hot, cold); mixing yields a temperature range; the system is not immediately responsive — variable latency between adjustment and temperature change, especially just after turn-on (hence the learned probe-wait-probe behavior).
- C-13.3 (Interaction model). The sub-model of how one interacts: adjust temperature and flow via the provided handles; hot conventionally on the left (a consistency convention embedded inside the model).
- C-13.4 Intuitive and unintuitive are not intrinsic properties of designs. System matches the person's mental model → expectations met (typically below conscious awareness) → perceived as intuitive. System contradicts the model → expectations broken → perceived as unintuitive. Intuitiveness is a relation between design and expectation, not an attribute of the design.
An expert faucet designer conceives a genuine improvement: one lever for temperature, one for flow — eliminating the classic cross-coupling error (adjusting flow perturbs temperature and vice versa). Objectively superior mechanism. It fails because:
- C-13.5 (Model mismatch). The designer's (sophisticated, superior) model does not match the installed base of user models; users experience only broken expectations → "unintuitive."
- C-13.6 (Familiar-form aggravation). The Morty faucet looks nearly identical to a conventional faucet while behaving totally differently — turning "hot" yields no water. Familiar form makes a promise the behavior breaks; the mismatch between expected behavior and experienced reality is a major usability failure (worst case of §4.3).
- C-13.7 (Weak remediation). Labels and subtle form variation are remedies to symptoms, not the disease: such cues are easily overlooked precisely when notions of how the system works are deeply ingrained.
- C-13.8 (Risk scaling). Attempting to change people's mental model of a product is risky, and risk scales with user familiarity. ANY change to a long-lived product will be hard to adjust to, regardless of how good or necessary the change is.
- C-13.9 (Burden of proof). Before big changes to an existing product: attain effectively 100% confidence the change yields clear wins for current users. "Change for its own sake" is categorically insufficient justification. Required process: go carefully; test the design; prove beyond a shadow of a doubt that the innovation is objectively better. Only then push through — people will come around eventually.
Reference system: Ordering a cheeseburger. The decision tree is serialized by the waiter: burger → doneness → cheese type (cheddar/Swiss/jack/…) → toppings (bacon/egg/avocado/none) → side (salad/fries/onion rings) → [side-conditional: fries would open regular/truffle/garlic]. Confronting the full Cartesian product at once would be complex and daunting; stepping through one decision at a time is tractable. Early choices prune later subtrees: no fries ⇒ fries varieties never presented.
- C-14.1 Progressive disclosure (a) gradually eases people from the simple to the complex, and (b) hides complexity so basic tasks are accomplishable through simple, approachable surfaces.
- C-14.2 (The rub — inherent hazard). The same mechanism that simplifies also buries information and functionality. The garlic-fries problem: the option was never surfaced because an earlier branch pruned it — yet had the person known, they'd have chosen differently. Every disclosure hierarchy is simultaneously a discoverability filter.
- C-14.3 Pareto structure: ~80% of a system's benefit derives from ~20% of its functions; ~80% of users use only ~20% of functionality. Percentages vary; the asymmetry is the invariant law: not all information/functionality is created equal.
- C-14.4 (Allocation directive). For complex products it is correct and desirable to make the vital 20% easy to find by hiding the remaining 80% behind disclosure.
- C-14.5 (Reference case — print dialog). Default surface: printer, copies, page range — far less than 20% of available functions, satisfying what people want far more than 80% of the time. Full option set: one click away.
- C-14.6 (Dual protection). Correct disclosure (a) reduces clutter and decision load, and (b) prevents people from confusing/altering settings they don't understand — the "family member changed something and now nothing works" support-call scenario. Novices stay unintimidated, un-overwhelmed, and out of trouble; experts reveal what they need, understand, and can use, quickly.
- C-14.7 (Skill-graded pathways). Disclosure structure = the interface's expertise gradient: simple by default, deep on demand.
Reference system: Hotel-room window shade and light switches.
- C-15.1 (Form correspondence). A control's form SHOULD mirror the behavior of its target. Shades move up and down ⇒ the control moves up and down ⇒ zero ambiguity about how to raise/lower, and control state (down = closed) is legible at a glance.
- C-15.2 (Configuration correspondence). Multi-control arrangements SHOULD mirror the spatial layout of their targets: three switches for three ceiling-light banks arranged to match the lights' layout. Attending to mapping directly resolves control position, order, and even control-type selection.
- C-15.3 (Labels as diagnostic). Labels appear where mapping is unclear — the tell-tale sign of mapping failure (the undifferentiated bank of identical switches). Labels are a weak fix: reading costs time and does not build spatial/muscle memory of control locations or interactions.
- C-15.4 (Interface realizations). Horizontal property ⇒ horizontal slider. Rotation ⇒ dial (superior to slider or stepper).
- C-15.5 (Direct manipulation supremacy). The best mapping is the most direct mapping: manipulate the object itself — pointer on macOS, gestures on iOS — for maximal straightforwardness, intuitiveness, and precision.
Reference system: The dinner plate. Smooth ⇒ appears rotatable/slidable; rim gap ⇒ appears graspable/liftable; food surface ⇒ "put food on it"; frisbee-like ⇒ conceivably throwable. Not perceived: drinking vessel.
- C-16.1 (Relational definition). Affordance is NOT an attribute of the object; it is a relation between an individual and an object, varying with physical ability and therefore from person to person. A frisbee affords catching and throwing to a human; to a dog, catching but not throwing. A plate affords eating-from to both.
- C-16.2 (Likelihood weighting). Perception of an affordance scales with the likelihood of the associated action. A plate would make an excellent saucer, but glass-placing is an unlikely act, so the affordance goes unperceived; food-placing is highly likely, so that affordance is immediately perceived.
- C-16.3 (Ubiquity). Affordances are perceived for every environment/object ever encountered: the human-sized door affording passage (body imaginable moving through unobstructed), the continuous ground plane affording walking without stumbling, the chair affording sitting, the table affording placement, the floor affording foot rest.
- C-16.4 (Cue obligation). Manufactured objects — and interfaces — MUST include cues evoking their affordances: what actions are possible, with the obviousness/visibility of cues indicating the correct or intended interactions.
- C-16.5 (Canonical widget cues). Slider: knob-on-track affords dragging; drop shadow separates knob from track, suggesting independent movability — though even a filled circle over a line suffices for most people. Dial affords rotation. Button affords tap/click — a highly abstracted descendant of the physical button, connected by as little as corner rounding. Communication at maximum efficiency.
- C-16.6 (Abstraction drift). Populations grow comfortable with increasing abstraction over time; the minimum sufficient cue is a moving target that has historically moved toward less.
- C-16.7 (Animated affordance). Motion can carry the cue: the weather app's content nudging upward on entry suggests — truthfully — scrollability.
- C-16.8 (Failure mode). If action possibilities are not made clear: people interact in unsupported ways, and mistake controls for static objects (and vice versa).
Reference system: Hotel-room light switches — bathroom switch in the bathroom, hallway switch in the hallway, bedroom switches in the bedroom.
- C-17.1 (Proximity → connection inference). The closer a control is to an object, the stronger the assumed causal connection between them.
- C-17.2 (Ergonomic co-location). Proximity also matches intent: nearness to a region of interest predicts desire to control it — the bathroom switch beside the door is at arm's reach exactly when needed.
- C-17.3 (Proximity among controls). Spacing expresses inter-control relationships: in a wall bank where one switch is known to control lights, all co-located switches are presumed lights; a shade control mixed in invites error — separate it, and the separation itself becomes the memory aid for which is which.
- C-17.4 (Grouping). Clustering related elements is fundamental to giving a design structure and communicating element relationships. Understood by everyone; effectively used by few — easy to overlook, so it MUST be an explicit design pass.
- C-17.5 (Application exemplars). Keynote: view menu adjacent to navigator+canvas (its targets); object-creation tools directly above the canvas (where objects land); animate/format/document toggles directly above where those panels appear. Sketch: clustered grouping controls, transform/edit tools, pathfinding ops, layer-ordering actions.
- C-17.6 (Scale dependence). Need intensifies with interface area (Mac > iPad > iPhone > Watch) but the principles remain crucial at every size.
Reference system: The reef. Bilateral symmetry (fish), radial/rotational symmetry, translational symmetry (schooling repetition) — ubiquitous across marine life and essentially all plants and animals on land, sea, and air; likewise most human artifacts (switches symmetric about both axes; faucets; cars — for functional reasons and aesthetic ones: an asymmetric car reads as damaged, "very rational reason not to get in").
- C-18.1 (Taxonomy). Three operative classes: reflectional/bilateral, radial/rotational, translational (repetition along a translation vector).
- C-18.2 (Perceptual effects). Symmetric forms are efficient forms; they connote good health, stability, balance, orderliness, and are aesthetically pleasing — plausibly for evolutionary reasons. Symmetric elements are perceptually integrated: two facing square brackets are unconsciously bound into one coherent object despite physical disconnection (Gestalt closure).
- C-18.3 (Interface application — reflectional). Balance via median-line centering of key elements with counterbalanced flanking elements: weather, camera, clock, phone apps.
- C-18.4 (Interface application — translational). Structure and order via even repetition of like elements: repeated city rows in clock; even cadence of locations in weather.
- C-18.5 (Directive). In layout, actively seek opportunities to deploy symmetry for balance (reflectional) and order (translational). Attractive interfaces typically mix both.
Principles are individually true and jointly conflicting. Design is substantially the activity of resolving these conflicts. The best designers struggle with exactly this; there is no algorithmic resolution — only structured judgment.
Every principle has an over-application failure mode. Documented saturation points:
- T-19.1 Too much feedback → annoying (alert fatigue; devalued confirmations).
- T-19.2 Too much visibility → distracting (attention competition; density-induced decision slowdown, especially for novices).
- T-19.3 Too much progressive disclosure → inefficient workflows (expert task friction; buried functionality — the garlic-fries loss).
- T-19.4 (Generalization) Measured application, judgment, and discretion are REQUIRED per principle, per context.
| Tension | Poles | Resolution rule |
|---|---|---|
| Visibility ↔ Simplicity/Disclosure | Surface everything vs. hide complexity | Partition by 80/20 (C-14.3): operation-critical + high-frequency state stays surfaced at high hierarchy levels (C-11.3); low-frequency depth goes behind disclosure with a ≤1-step reveal (C-14.5) |
| Familiarity/Consistency ↔ Innovation | Convention vs. novelty | Innovation encouraged in substance; convention binding for simple vocabulary (icons, labels, placements) absent strong justification (C-12.3). Never pair familiar form with novel behavior (C-13.6) |
| Org consistency ↔ Platform consistency | Self-consistent across products/web vs. native per platform | Platform-native user familiarity wins (C-12.4). Rationality of the org-side argument does not make it correct |
| Agency ↔ Responsibility | Freedom vs. protection | Freedom by default (P-2.1–2.3); interruption reserved for genuinely destructive thresholds (P-2.5); undo everywhere makes freedom safe (P-2.4) |
| Simplicity ↔ Informed decision-making | Remove vs. add | Simplicity is task-relative: add context where it enables informed action (P-6.6); remove where elements fail to earn their place (P-6.5) |
| Delight ↔ Purpose | Character vs. efficiency | Delight must never obstruct the core task (P-8.3); prefer delight expressed through competence (P-8.5) over decoration |
| Disclosure ↔ Discoverability | Approachability vs. option awareness | Accept the filter consciously; audit pruned branches for high-value hidden options (the garlic-fries audit, C-14.2) |
| Flexibility ↔ Consistency | Personalization vs. predictability | Personalize arrangement/inclusion of controls (P-5.7) while holding behavior and vocabulary invariant (C-12.7) |
- T-19.5 Principle relevance varies with: product category, platform, screen size, use case, and the experience level of the audience. These factors MUST explicitly modulate which principles dominate at any decision point.
- T-19.6 Proximity/grouping pressure scales with interface area (C-17.6); disclosure pressure scales with functional surface; consistency pressure scales with user-base tenure (C-13.8).
- V-20.1 (Wayfinding audit). Per-screen, all Five Questions (§9.2). Any unanswered question on any screen = defect.
- V-20.2 (Feedback audit). Enumerate every user action and every autonomous system action; verify each produces classified feedback (status/completion/warning/error per §10.1); verify salience scales with stakes (C-10.2) and multimodality with criticality (C-10.3).
- V-20.3 (Explain-the-design gap analysis). Full protocol per V-10.1: novice think-aloud → live designer explanation → diff → encode the delta into the interface. What you say to fill the gaps is the specification of missing feedback.
- V-20.4 (Convention conformance pass). Diff all glyphs, terminology, navigation schemes, and workflow patterns against platform convention; every deviation carries a written strong justification or is reverted (C-12.3).
- V-20.5 (Mental-model change gate). For any change to a shipped product with an installed user base: evidence of clear wins for current users at effectively full confidence, via testing, before release (C-13.9). "Because it's better designed" is insufficient without proof; "for the sake of change" is void.
- V-20.6 (Misuse review). Per feature: misuse vectors, harmed parties, mitigations; removal where residual safety risk exceeds value (P-3.4, P-3.6).
- V-20.7 (Element justification pass). Per screen: every element must earn its place (P-6.5); every candidate for distillation (data→graphic, detail→summary) evaluated.
- V-20.8 (Affordance/mapping walkthrough). Verify every interactive element carries a sufficient cue (C-16.4) and every control's form/arrangement corresponds to its target (C-15.1–15.2); treat every label added to disambiguate a control as a mapping-defect flag (C-15.3).
- V-20.9 (Craft QA in the wild). Real-world environment testing for durability, reliability, performance; regression watch on responsiveness, scroll fluidity, alignment, rotation/layout adaptation (P-7.1, P-7.4).
- V-20.10 (Emotional register check). Named target emotion exists; each defining moment (P-8.2) reviewed for reinforcement vs. obstruction of it.
| Strategic (Part I) | Implemented primarily via (Part II) |
|---|---|
| Purpose | 80/20 allocation (§14.2); element justification (P-6.5) |
| Agency | Wayfinding exit paths (C-9.5); undo/forgiveness; feedback (§10) as the informed-control channel |
| Responsibility | Warning/error classes (§10.1); prevention hierarchy (C-10.6); disclosure as protective containment (C-14.6) |
| Familiarity | Consistency (§12); mental-model matching (§13); metaphor (§4.1); affordance conventions (§16) |
| Flexibility | Personalizable grouping/arrangement (§17, P-5.7); per-platform mapping and input models (§15, P-5.6) |
| Simplicity | Progressive disclosure (§14); hierarchy (P-6.4); visibility trade-off management (C-11.4) |
| Craft | Internal consistency (C-12.5–12.6); feedback material quality (P-7.2); symmetry (§18) |
| Delight | Symmetry/aesthetics (§18); inferential correction (C-10.7); defining moments (P-8.2); emergent sum of all above (P-8.4) |
- Affordance: Perceived relation between an individual and an object defining possible actions; person-relative, not object-intrinsic (C-16.1).
- Completion feedback: Confirmation that a performed action succeeded or failed (§10.1).
- Grouping: Spatial clustering of related elements to encode relationship and structure (C-17.4).
- Human interface: Interface framing centered on human fallibility and dignity rather than the clinical "user" (§0.1).
- Interaction model: Sub-model of how one operates a system (C-13.3).
- Mapping: Correspondence between a control's form/arrangement and its target's behavior/layout (§15).
- Mental model: Individual, experience-derived, simplified internal model of a system (C-13.1).
- Progressive disclosure: Serialization and stratification of complexity from simple to complex (C-14.1).
- System model: Sub-model of how a system works internally (C-13.2).
- Wayfinding: Orientation system answering the Five Questions on every screen (§9.2).
- 80/20 rule: Pareto asymmetry — most benefit from a small fraction of functions; governs disclosure allocation (C-14.3).
These principles express fundamental truths about human perception and cognition. They are a framework for understanding and a shared language for articulating a design's strengths and shortcomings. Applying them is not easy — principles pull in different directions, saturate when overused, and vary in weight by context — but design becomes tractable when the fundamentals are understood. Let the principles be the North Star: they guide toward products that serve the humans they are designed for. That is the thing that matters most — and the people on the other side of the glass will sense, in the thoughtfulness and care, the humanity of the people who made it.