saglitzdesign-mcp 0.3.1

package/knowledge/books/design-of-everyday-things.md

@@ -0,0 +1,155 @@
+---
+id: design-of-everyday-things
+title: "The Design of Everyday Things — Interaction Fundamentals (Don Norman)"
+category: book
+platform: both
+tags: [interaction-design, usability, feedback, mental-models, error-prevention]
+sources: ["The Design of Everyday Things (Don Norman, revised ed. 2013)"]
+updated: 2026-07-08
+---
+
+# The Design of Everyday Things — Applied to Screens
+
+Norman's core claim: when people fail to use something, it is the design's fault, not the user's. Every UI decision should answer two questions the user is silently asking: **"What can I do here?"** and **"What just happened?"** The frameworks below turn that into enforceable rules.
+
+## 1. Affordances — what an element actually allows
+
+An affordance is the relationship between the user and what an object lets them do (a button affords pressing, a text field affords typing). On screens, affordances are virtual, so they only work if they are perceivable.
+
+**Rules:**
+- Every interactive element must *look* interactive. Buttons need a shape/fill/border that separates them from static text; links need a persistent visual difference (color and/or underline), not hover-only styling — hover doesn't exist on touch devices.
+- Never make non-interactive elements look clickable (e.g., underlined headings, card-like boxes that do nothing). False affordances erode trust in real ones.
+- Match the control to the interaction it affords: sliders for continuous ranges, steppers for small integer ranges, toggles for binary state, dropdowns for 5+ mutually exclusive options, radio buttons for 2–5 visible options.
+- On touch: anything tappable must meet minimum target size (~44×44pt iOS / 48×48dp Android) — a visually small icon can keep its size but must get a larger hit area.
+
+## 2. Signifiers — the perceivable clue
+
+Norman later split "affordance" from "signifier": the signifier is the *signal* that communicates the affordance. Most usability failures are missing signifiers, not missing capability.
+
+**Rules:**
+- If a surface scrolls, show partial content cut off at the fold ("peek") so users know more exists. Never end a scrollable region at a clean visual boundary that looks like the end.
+- If content is swipeable (carousels, tab views, list actions), show dots, arrows, a peeking next card, or a one-time hint. Invisible gestures are undiscoverable by default.
+- Placeholder text is a weak signifier that disappears on focus — always pair inputs with persistent labels.
+- Disabled states must look disabled (reduced contrast, no pointer cursor) AND explain why when the reason isn't obvious (tooltip or helper text: "Add at least one item to continue").
+- Icons alone are signifiers only for a handful of universal meanings (search, close, home, settings, play). For anything else, add a text label or use text only.
+
+## 3. Mapping — controls should relate spatially/logically to their effects
+
+Good mapping = the relationship between control and outcome is obvious from layout alone (stove knobs arranged like the burners).
+
+**Rules:**
+- Place controls next to the thing they affect: an "Edit" button on the card it edits, not in a global toolbar; volume/zoom controls oriented in the direction of the change (up = more).
+- Keep list-item actions inside the list item; keep page-level actions at page level. Users infer scope from position.
+- Order form fields in the order users think about the data (name → address → payment), and order wizard steps in causal order.
+- Sliders and progress: left/low = less/earlier, right/high = more/later (mirror for RTL locales).
+- In settings screens, the toggle's label must describe the ON state ("Enable notifications", not "Notification behavior") so the mapping between switch position and outcome is unambiguous.
+
+## 4. Feedback — every action gets an immediate, proportionate response
+
+**Rules:**
+- Acknowledge every user action within ~100ms: pressed states on buttons, ripple/highlight on tap, immediate optimistic UI where safe.
+- For operations 0.1–1s: subtle inline spinner. 1–10s: progress indicator with the button disabled and labeled ("Saving…"). >10s: progress bar with estimate or step count, and let the user leave/cancel.
+- Confirm outcomes, not just receipt: after "Save", show "Saved" (toast, checkmark, or updated timestamp). After delete, show the item gone plus an Undo affordance.
+- Feedback must be proportionate: don't use a modal dialog to confirm a trivial success; don't use a 2-second toast to report a destructive failure. Errors deserve louder, more persistent feedback than successes.
+- Never leave a dead click. If an action can't complete, say why, right where the user acted.
+
+## 5. Conceptual models — the story the UI tells about how it works
+
+Users build a mental model from the interface itself (the "system image"). If the UI implies the wrong model, users will make systematic, repeated errors.
+
+**Rules:**
+- Decide the model first, then design to express it. Is it a document you edit and save, or a live-synced canvas? Files-and-folders or a search-first pool? Make one model visible and consistent everywhere.
+- If saving is automatic, kill the Save button and show sync state ("All changes saved"). A Save button in an autosaving app teaches a false model and creates anxiety.
+- Use metaphors users already have (cart, inbox, trash-with-restore) and then honor them completely — a "trash" that permanently deletes immediately violates the model it advertises.
+- Surface system state that the model depends on: online/offline, draft vs. published, filtered vs. full list. Hidden state is the top source of "the app is broken" reports.
+- Consistency is model-preservation: the same gesture/icon/word must mean the same thing on every screen.
+
+## 6. The Seven Stages of Action — a checklist for any flow
+
+Norman's cycle: (1) form the goal → (2) plan → (3) specify the action → (4) perform it → (5) perceive the result → (6) interpret it → (7) evaluate against the goal.
+
+**Use as an audit on every key task:**
+1. **Goal:** Does the screen help users recognize what they can accomplish here? (Clear page title, value-oriented empty states.)
+2. **Plan:** Are the available options visible without exploration? (Don't bury the primary path in an overflow menu.)
+3. **Specify:** Is the next step unambiguous? (One clearly primary CTA per view.)
+4. **Perform:** Is the action low-effort and forgiving? (Big targets, sensible defaults, autofill.)
+5. **Perceive:** Is there visible change after acting?
+6. **Interpret:** Does the change use the user's vocabulary? ("Order placed", not "Transaction 201 committed".)
+7. **Evaluate:** Can users tell the goal is done and what's next? (Confirmation screens with next-step links.)
+
+If a support ticket or usability failure exists, locate which stage broke and fix that stage — don't redesign the whole flow.
+
+## 7. Gulf of Execution & Gulf of Evaluation
+
+- **Gulf of Execution** = the gap between what users want to do and how the UI lets them do it. Bridge it with signifiers, constraints, conventions, and fewer steps. Symptom: "How do I…?" questions.
+- **Gulf of Evaluation** = the gap between what the system did and the user's ability to tell. Bridge it with feedback and clear state display. Symptom: "Did it work?" questions and double-submissions.
+
+**Rule:** classify every usability complaint into one of the two gulfs; the fix category follows automatically (execution → clearer controls/fewer steps; evaluation → better feedback/state visibility).
+
+## 8. Constraints and forcing functions
+
+**Rules:**
+- Prevent invalid input structurally instead of validating after the fact: date pickers over free-text dates, max-length enforced live, disable "Submit" only when structural requirements are unmet (and say what's missing).
+- Use forcing functions for high-risk actions: require typing the project name to delete it; require scrolling terms before accepting only when legally necessary (otherwise it's just friction).
+- Interlocks: don't allow step B before step A completes (grey out "Pay" until an address exists — with an explanation).
+- Reserve confirmations for genuinely destructive, hard-to-undo actions. Over-confirming trains reflexive "OK"-clicking, which defeats the one confirmation that matters.
+
+## 9. Errors: slips vs. mistakes — different causes, different fixes
+
+- **Slips** = right intention, wrong execution (fat-fingered the wrong button, typo). Users know the goal; their hand failed.
+- **Mistakes** = wrong intention from a wrong mental model (user deletes "archive" thinking it's a duplicate).
+
+**Fix slips with:**
+- Bigger/better-separated targets; never place destructive and primary actions adjacent (keep "Delete" away from "Save"; separate them spatially and by color).
+- Undo everywhere possible — undo beats confirmation because it doesn't interrupt the 99% correct case.
+- Inline validation that catches typos (email format, card checksum) at field-exit, not at submit.
+
+**Fix mistakes with:**
+- Better conceptual models and clearer labels ("Archive (you can restore later)" vs. bare icon).
+- Previews of consequences: "This will remove 34 files for 5 team members."
+- Error messages that teach: state what happened, why, and the exact next step, in plain language. Never blame ("Invalid input") without direction.
+
+**Universal error rules:** preserve the user's work through any error (never clear a form on failed submit); log-friendly but human-first wording; make recovery a one-click path.
+
+## 10. Knowledge in the world vs. in the head
+
+Don't require memorization — put the needed knowledge in the interface.
+
+**Rules:**
+- Recognition over recall: show recent items, autocomplete, visible menu options instead of command syntax; show format examples inside/next to inputs ("MM/YY").
+- Persist context across steps: in a checkout, keep the cart summary visible; in a wizard, show completed steps and their values.
+- Shortcuts (knowledge in the head) are for experts — always keep a discoverable in-the-world path to the same action.
+
+## 11. Worked example — applying the framework to a "delete account" flow
+
+- **Affordance/signifier:** "Delete account" lives in Settings → Account, styled as a quiet destructive (red text) row — findable, but not adjacent to routine actions.
+- **Mapping:** the control sits inside the Account section it affects, at the bottom (last-resort position matches last-resort meaning).
+- **Conceptual model:** the screen explains the model before the action: "Your data is kept for 30 days, then permanently erased." No hidden state.
+- **Constraints/forcing function:** the confirm button stays disabled until the user types their account email — a slip becomes structurally impossible.
+- **Feedback:** after confirming, an explicit outcome screen ("Your account is scheduled for deletion on Aug 7") plus an email — evaluation gulf closed.
+- **Error design:** the 30-day window is the undo; the confirmation email contains a one-click "Cancel deletion" link. Mistakes remain recoverable even after the forcing function passed.
+
+Use this pattern of reasoning for any high-stakes flow: walk each concept in order and check it has a concrete answer.
+
+## 12. Discoverability and understanding — the two-question test
+
+Norman reduces good design to two properties. Run both as a final gate on every screen:
+
+- **Discoverability:** can users figure out what actions are possible and where to perform them, purely from looking? If any core action requires being told, add signifiers or restructure.
+- **Understanding:** can users tell what everything means, how the product is meant to be used, and what all the indicators say? If any icon, state, or number needs explanation, label it or remove it.
+
+A screen that passes both needs no onboarding tour. Treat a required tour as a symptom, not a feature.
+
+## Quick audit checklist
+
+- [ ] Every interactive element visibly interactive; nothing non-interactive looks clickable
+- [ ] Scroll/swipe/hidden content is signified
+- [ ] Controls sit next to what they affect; labels describe the ON/positive state
+- [ ] Every action acknowledged <100ms; every outcome confirmed; system state always visible
+- [ ] One consistent conceptual model; no false metaphors; no hidden state
+- [ ] Destructive actions: separated from primary actions, undoable, consequence-previewed
+- [ ] Error messages: what happened + why + next step; work is never lost
+- [ ] Nothing requires memory that the screen could carry instead
+- [ ] Every complaint triaged to a gulf (execution vs. evaluation) and a stage (1–7) before fixing
+- [ ] High-stakes flows use constraints/forcing functions plus a recovery window, not just a confirm dialog
+- [ ] Screens pass the two-question test (discoverability + understanding) without a tour

package/knowledge/books/dont-make-me-think.md

@@ -0,0 +1,154 @@
+---
+id: dont-make-me-think
+title: "Don't Make Me Think — Web Usability Rules (Steve Krug)"
+category: book
+platform: web
+tags: [usability, navigation, content, scanning, usability-testing]
+sources: ["Don't Make Me Think, Revisited (Steve Krug, 3rd ed. 2014)"]
+updated: 2026-07-08
+---
+
+# Don't Make Me Think — Applied Web Usability
+
+Krug's first law: **a page should be self-evident — obvious, self-explanatory — or at worst self-explanatory with minimal effort.** Every question mark that pops into a user's head ("Is that clickable?", "Where am I?", "Why is it called that?") adds cognitive load and erodes confidence. The designer's job is to eliminate question marks.
+
+## 1. Design for how people actually use the web
+
+Three facts that invalidate most "careful reader" assumptions:
+
+1. **People scan, they don't read.** They're on a mission, they know they don't need most of the page, and scanning has worked their whole lives.
+2. **People satisfice.** They don't weigh all options and choose the best; they click the first thing that looks plausibly right. If it's wrong, they hit Back (cheap) and try again.
+3. **People muddle through.** They don't read instructions or care how things are "supposed" to work; they form just-enough theories and keep them if they work at all.
+
+**Consequences (rules):**
+- Design pages as billboards, not essays. Assume every visitor is skimming at speed.
+- Don't rely on users reading anything before their first click. Instructions placed before an action are usually skipped — put guidance at the point of need instead.
+- Since users satisfice, the *most plausible-looking* option wins, not the technically correct one. Label things so the right choice is also the most plausible one.
+- Don't punish wrong clicks: keep Back working (no broken history, no hijacked navigation), make recovery instant, never lose entered data.
+
+## 2. Build billboard-style pages for scanning
+
+**Rules:**
+- Strong visual hierarchy: the most important thing is the most prominent; logically related things are visually grouped; nesting is shown visually (things inside a section look contained by it).
+- Headings must sit closer to the content they introduce than to the content above (space-before > space-after), be visibly different in size/weight, and be front-loaded with keywords.
+- Break pages into clearly defined zones: users decide within seconds which areas to attend to and which to ignore. Ambiguous zones get ignored wholesale.
+- Format for scanning: short paragraphs (1–3 sentences), bulleted lists for anything list-like, bolded keywords sparingly, generous line spacing in lists.
+- Make clickable things unmistakably clickable, and keep one visual language for links/buttons across the whole site. Users shouldn't spend a single neuron deciding what's clickable.
+- Reduce visual noise ruthlessly: busyness (everything shouting), background noise (textures, faint clutter), and plain overcrowding all slow scanning. When in doubt, remove.
+
+## 3. Mindless choices beat few choices
+
+Krug's refinement of the "3 clicks" myth: **users don't mind many clicks if each click is a mindless, unambiguous choice.** Three agonizing clicks are worse than six obvious ones.
+
+**Rules:**
+- Optimize for choice-confidence, not click-count. It's fine to add an intermediate page if it splits an ambiguous choice into two obvious ones.
+- Every choice point (nav item, button pair, filter) should be answerable without thought. If users must deliberate, either relabel, reorder, or add a one-line disambiguator ("Not sure? Most people want X").
+- When guidance is genuinely needed, make it: brief (the smallest amount that helps), timely (exactly at the decision point), and unavoidable (in the flow, not in a help page).
+
+## 4. Omit needless words
+
+Krug's third law: **get rid of half the words on each page, then get rid of half of what's left.**
+
+**Rules:**
+- Kill "happy talk" — welcome-mat introductions, mission-statement paragraphs, self-congratulation. Users skip them; they only add noise and push content below the fold.
+- Kill most instructions. If something needs instructions, first try redesigning it so it doesn't. What remains should be cut to the bone ("Enter your work email" not "Please fill in the email field below with the email address you use at work").
+- Cutting words makes real content more prominent, pages shorter, and scanning faster — it's a hierarchy tool, not just an editing habit.
+- Practical pass for any screen: delete every sentence, then re-add only the ones whose absence causes a failure.
+
+## 5. Navigation is the product
+
+Users can't rely on physical cues (no sense of scale, direction, or location on the web), so persistent navigation must do that work. Navigation isn't just wayfinding — it tells users what the site contains, how to use it, and whether the builders knew what they were doing.
+
+**Rules — every page (except stripped-down flows like checkout) needs:**
+- **Site ID/logo** top-left (or top-center), linking home.
+- **Sections (primary nav)** with the current section visibly highlighted.
+- **Utilities** (sign in, account, cart, help) small and top-right.
+- **Search**: a box + button on every page for search-dominant users; don't hide it behind an icon on desktop if search matters to your product.
+- **Page name**: every page needs a name, in the right place (framing the page's content), prominent, and matching the words the user clicked to get there. Click-target text ≠ page title is a top trust-breaker.
+- **"You are here" indicators**: highlighted nav item, breadcrumbs for deep hierarchies (start with "Home", use > separators, bold the last item).
+- Follow conventions unless you have a genuinely better idea *and* the resources to prove it works. Conventions (cart icon, logo-links-home, blue-ish links, footer legal) are pre-learned — novelty taxes every visitor. "Innovate when you know you have a better idea; copy when you don't."
+- Tabs are excellent primary navigation when drawn correctly: the active tab must visually connect to the page area (same background color, front-most), instantly communicating "you are in this drawer."
+
+## 6. The Trunk Test — audit for disorientation
+
+Imagine being blindfolded and dropped onto a random interior page. Glancing at it, you must be able to answer, at a glance, not by deduction:
+
+1. What site is this? (site ID)
+2. What page am I on? (page name)
+3. What are the major sections? (primary nav)
+4. What are my options at this level? (local nav)
+5. Where am I in the scheme of things? (highlighting, breadcrumbs)
+6. How can I search?
+
+**Rule:** run this on interior pages, not the homepage — deep links (search engines, shared URLs) mean most sessions start mid-site. Any question that takes more than a glance to answer is a defect to fix.
+
+## 7. The homepage — everyone's fighting for it, clarity must win
+
+The homepage must convey at a glance: what this is, what you can do here, what they have, and why you should be here rather than elsewhere — while surviving every stakeholder's pet promo.
+
+**Rules:**
+- Get the value proposition across with a tagline near the site ID (clear and informative beats clever), a concise welcome blurb, and obvious "start here" entry points (search, browse, sign up).
+- The bigger the fight for homepage space, the more ruthless the pruning must be: everything added to the homepage dilutes everything already there.
+- Never let internal politics decide prominence; let user tasks decide. Preserve the top entry points for the top 2–3 user goals.
+- Don't count on users reading the homepage at all — many arrive deep-linked. Every page must carry identity and orientation on its own (see Trunk Test).
+
+## 8. Goodwill: the reservoir model
+
+Every visitor arrives with a reservoir of goodwill; friction drains it, kindness refills it, and an empty reservoir means they leave (and remember).
+
+**Drains (avoid):** hiding information users want (support numbers, shipping costs, prices); punishing users for not doing things your way (rigid input formats — accept phone numbers with or without dashes); asking for information you don't truly need; fake sincerity and marketing fluff; obstacles like unskippable promos; amateur-looking sloppiness.
+
+**Refills (do):** make the top 3 tasks effortless; be upfront about costs and limitations; save users steps (pre-fill, remember state); answer likely questions where they arise; make recovery from errors easy; apologize when the system genuinely can't do something.
+
+## 9. Cheap usability testing — Krug's method
+
+Testing one user early beats testing fifty at the end. Formal, expensive testing is the enemy of any testing at all.
+
+**The method (rules an assistant can prescribe):**
+- **3 users per round, one morning a month**, testing whatever is ready that month (sketches, prototypes, live site). Fixed cadence beats "when it's ready."
+- Recruit loosely: testing people outside the exact target audience still finds most problems ("recruit loosely and grade on a curve").
+- Tasks: give realistic missions ("Find a dress shirt under £50 and get to checkout"), have users **think aloud**, and never help or lead. Also start with a "get it?" test: show the homepage/landing page and ask what they make of it before any tasks.
+- The whole team watches (live or recording); debrief over lunch the same day.
+- **Fix the most serious problem first, and prefer the smallest change that removes the problem** — a tweak you'll actually ship this week beats a redesign you won't. Resist adding things (instructions, banners) as fixes; usually the fix is taking something away.
+- Ignore "kayak" problems: momentary wobbles users self-correct in seconds without noticing.
+
+## 10. Mobile: same principles, tighter constraints
+
+Krug's 3rd-edition position: mobile is not a different discipline — it's the same usability under scarcer space and fatter pointers. The main new sins are mobile-specific.
+
+**Rules:**
+- **Tradeoffs shift, principles don't.** Small screens force prioritization, which is healthy — but "mobile users are rushed and need less" is a myth. If content exists on desktop, mobile users must be able to reach it: never amputate features, relocate them (progressive disclosure, secondary screens).
+- **No teleporting:** a link shared from mobile must open equivalent content on desktop and vice versa. If separate mobile pages exist, cross-link every page to its counterpart.
+- **Affordances suffer most on touch:** no hover means no hover-revealed anything. Every tappable element must look tappable at rest; every swipe/long-press needs a visible alternative or hint.
+- **Tappable ≥ 44pt with breathing room** — adjacent small targets cause the most rage-taps.
+- **Flat design warning:** stripping gradients/borders/shadows removes the cues that said "this is clickable." If you go flat, compensate with color, placement conventions, and button-shaped buttons.
+- Speed is usability: mobile users on slow connections experience every extra kilobyte as friction — performance budget is a UX deliverable.
+
+## 11. Usability as common courtesy — forms and asks
+
+- Ask only for what the task needs. Every extra form field is both effort and suspicion ("why do they want this?").
+- Accept input in any reasonable format (spaces in card numbers, any phone format) — normalizing is the computer's job, not the user's.
+- Explain *why* you need sensitive data at the point of asking ("Phone: only used for delivery issues").
+- Preserve everything on error; return the user to the exact field with a specific message.
+- Say what happens next before they commit ("You won't be charged until dispatch").
+
+## 12. Accessibility is usability
+
+Krug's take: the single best thing you can do for accessibility is fix the usability problems that confuse *everyone* — then add the specifics:
+- Real heading structure (h1–h3 used semantically) — screen-reader users scan by headings just like sighted users scan visually.
+- Alt text on informative images; empty alt on decorative ones.
+- Full keyboard operability and visible focus states.
+- Form labels programmatically attached to inputs.
+- Sufficient text contrast and user-resizable text.
+These overlap almost entirely with billboard design and Trunk Test discipline — accessible sites are just sites where the scanning cues are machine-readable too.
+
+## Quick audit checklist
+
+- [ ] Zero question marks: everything clickable looks clickable, every label instantly plausible
+- [ ] Page scannable as a billboard: clear zones, real hierarchy, headings attached to their content
+- [ ] Word count halved, then halved again; no happy talk, no avoidable instructions
+- [ ] Persistent nav: site ID, sections + highlight, utilities, search, page name matching the clicked link
+- [ ] Passes the Trunk Test from any interior page
+- [ ] Homepage states what/why at a glance; top user tasks get top billing
+- [ ] Formats forgiving, prices/costs upfront, Back always safe — goodwill preserved
+- [ ] Monthly 3-user think-aloud test scheduled; last round's #1 issue fixed with the smallest viable change

package/knowledge/books/grid-typography-classics.md

@@ -0,0 +1,152 @@
+---
+id: grid-typography-classics
+title: "Grid Systems & Typography Classics — Müller-Brockmann, Lupton, Bringhurst"
+category: book
+platform: both
+tags: [grids, typography, layout, hierarchy, detailing]
+sources: ["Grid Systems in Graphic Design (Josef Müller-Brockmann, 1981)", "Thinking with Type (Ellen Lupton, 2nd ed. 2010)", "The Elements of Typographic Style (Robert Bringhurst, 4th ed. 2012)"]
+updated: 2026-07-08
+---
+
+# Grid Systems & Typography Classics — Applied to Screens
+
+Three print-era canons, translated. Müller-Brockmann supplies the grid method, Lupton the working typographer's toolkit, Bringhurst the detailing standard. Shared thesis: **structure and restraint are what make design look intentional** — the grid and the type system are decisions made once, then obeyed.
+
+## Part 1 — The Grid (Müller-Brockmann)
+
+The grid is not decoration; it is an ordering system that expresses clarity, objectivity, and economy. It makes layouts faster to produce, easier to extend by a team, and legible to users because repeated structure teaches itself.
+
+### 1.1 Construction order (do it in this sequence)
+
+1. **Start from the type, not the canvas.** Choose body size and line-height first; the baseline rhythm derives from line-height, and everything else derives from that.
+2. **Define the content frame:** max content width and outer margins. Screens: cap reading content at a width giving 45–75 characters per line (~640–720px for 16px body text); app shells and dashboards can use wider frames but individual text blocks stay capped.
+3. **Divide into columns:** 12 columns is the pragmatic web standard because it subdivides into 2/3/4/6 layouts. Fix the **gutter** (one spacing-scale unit, commonly 16–32px) and keep it constant; column width flexes, gutters don't.
+4. **Add rows to get a modular grid** when the page composes many heterogeneous blocks (dashboards, portfolios, card galleries, magazine-style homepages). A module = column × row cell; every component spans whole modules. Müller-Brockmann's guidance: more modules = more flexibility but more discipline required; fewer modules = stronger, simpler layouts. Start coarse (e.g., 12×6) and refine only under pressure.
+5. **Bind vertical rhythm to the baseline:** make spacing steps and component heights multiples of a base unit derived from the body line-height (in practice: an 8px or 4px system where body text is 16/24 and 24 = 3×8). Perfect print-style baseline locking is impractical on the web; consistent vertical multiples deliver the same perceived order.
+
+### 1.2 Using the grid
+
+- **Every element aligns to grid lines** — text blocks, images, cards, form fields. One misaligned element is more visible than a uniformly loose layout.
+- **Span whole columns.** Components occupy 1..n columns plus intervening gutters; never a column and a half.
+- **Violate the grid only deliberately and rarely.** A single full-bleed image or an element breaking the grid gains enormous emphasis *because* everything else conforms. Two violations per screen and the grid — and the emphasis — is gone.
+- **The grid persists across breakpoints as a system, not a fixed count:** 12 columns desktop → 8 tablet → 4 phone, same gutters-and-margins logic, same spacing scale. Components re-span, they don't reshape arbitrarily.
+- **Empty modules are content.** Müller-Brockmann treats unfilled cells as compositional material — resist filling every cell; asymmetric fill against a symmetric grid is the classic Swiss look.
+- **Photos/illustrations obey the grid too:** crop images to module boundaries; consistent image sizes (1, 2, 4 modules) beat per-image "best crop".
+
+### 1.3 What the grid buys you (why to enforce it)
+
+Consistency across a team, faster layout decisions (the grid answers "where?" so you only answer "what?"), and a UI users subconsciously trust because repeated structure signals competence. If a layout feels chaotic, the first audit is: does a grid exist, and does everything sit on it?
+
+## Part 2 — Typographic Hierarchy (Lupton)
+
+Lupton's frame: typography is an interface — the visual form of language is itself information. Hierarchy is expressed through contrast, and contrast has multiple independent dials.
+
+### 2.1 The hierarchy toolkit
+
+- **You have ~6 dials: size, weight, color/contrast, case, spacing/position, and style (italic/family).** Each level of hierarchy should differ from its neighbor by **1–2 dials, not all six.** A heading that is bigger AND bolder AND colored AND uppercase AND indented is shouting through a megaphone — pick two.
+- **Define levels as a closed system:** display, H1, H2, H3, body, secondary, caption/label — each with fixed size/weight/line-height/color, then reuse exactly. Two levels that differ only slightly should be merged; if you can't instantly tell H3 from H4, users can't either.
+- **Signal hierarchy by position and space as much as by size:** indentation, space-above, alignment changes, and rules (thin lines) are all hierarchy markers that don't inflate font sizes. Small caps or letterspaced uppercase at small sizes make excellent labels/eyebrows — hierarchy without height.
+- **Avoid "typographic dressing" without semantic difference:** every visual distinction must map to a real content distinction. If two things look different, users assume they *are* different.
+
+### 2.2 Choosing and pairing typefaces
+
+- **One family is enough** for most products — a versatile sans with many weights covers UI + marketing. **Two maximum** as a default rule (e.g., a serif for editorial headings + a sans for UI); pair by contrast (serif+sans, geometric+humanist), never two near-identical sanses.
+- **Match typeface to function:** UI text needs tall x-height, open apertures, distinguishable Il1 0O, and real rendering quality at 12–16px. Display personality fonts live only at large sizes.
+- **Text is a texture:** evaluate body settings by squinting at a full paragraph block — even grey texture is the goal; blotchy means bad spacing, wrong weight, or wrong leading.
+
+### 2.3 Setting text (Lupton's working rules, screen-adapted)
+
+- Body: 16px minimum on web; line-height ~1.4–1.6 for body, tightening as size grows (headlines 1.1–1.25).
+- Line length 45–75 characters; enforce with max-width on every prose container, not on the page alone.
+- One space after periods; real quotation marks and apostrophes (“ ” ’ not " '); real dashes (en dash for ranges, em dash—or spaced en dash—for breaks); ellipsis character (…) not three periods.
+- Don't letterspace lowercase body text; do letterspace all-caps and small-caps labels (+3–8%).
+- Left-align (ragged right) as the default for screens; watch the rag for ugly shapes; avoid justification unless hyphenation is on; never center more than ~3 short lines.
+
+## Part 3 — Typographic Detailing (Bringhurst)
+
+Bringhurst's governing principle: **typography exists to honor content.** Every choice serves reading; virtuosity that draws attention to itself at the text's expense is failure. His rules are the finishing standard.
+
+### 3.1 Rhythm and proportion
+
+- **Choose a base ratio and stick to it.** Bringhurst builds pages on proportional systems; on screens this means a modular type scale (e.g., 1.2 or 1.25 ratio: 12.8 → 16 → 20 → 25 → 31…, rounded to a fixed set) and a spacing scale in the same spirit. Arbitrary values are the enemy of rhythm.
+- **Vertical motion:** consistent leading is the page's heartbeat. Space between blocks should be whole multiples/simple fractions of the body leading (one blank line = 1 leading unit; heading gets, say, 2 above and 1 below — always more above than below, binding it to its content).
+- **Horizontal motion:** the measure (45–75ch, ~66 ideal) governs comfort; if a design forces a wide measure, increase leading to compensate; if narrow (sidebars, mobile), slightly tighten leading and reduce paragraph spacing.
+
+### 3.2 Micro-details that separate professional from amateur
+
+- **Hang or mark paragraphs one way, not two:** either indent first lines OR space between paragraphs — never both. On screens, spaced paragraphs are the convention.
+- **Kerning/spacing at display sizes:** large headlines need manual tightening (negative letter-spacing ~-1–2%); the bigger the type, the more visible the loose fit.
+- **Figures:** use tabular (monospaced) figures in tables, timers, and anything that updates in place; proportional figures in running text. Right-align numeric columns.
+- **True small caps and real italics** where the font provides them; never faux-bold, faux-italic, or scaled caps (browsers synthesize badly — load the actual weights/styles).
+- **Punctuation niceties:** hanging punctuation for large pull-quotes; thin/narrow no-break space between values and units (24 px → 24 px as one unit — at minimum use a non-breaking space); non-breaking spaces to prevent orphaned short words after titles (Mr. Smith).
+- **Avoid widows/orphans in headings and key copy:** a heading wrapping to leave one word on its own line looks broken — fix with `text-wrap: balance`, manual breaks, or rewording.
+- **Emphasis is singular:** italic OR bold OR color — one at a time, and sparingly. A page where much is emphasized has no emphasis (converges with Refactoring UI's de-emphasize principle).
+
+### 3.3 Restraint as the master rule
+
+Bringhurst: choose faces that suit the task, then "add nothing without reason." For products: no decorative flourishes that don't encode meaning; the test of good typography is that readers absorb the content without noticing the type — until they look, and find it beautiful.
+
+## Part 4 — Unified screen workflow (all three books)
+
+Apply in this order when designing or auditing any screen:
+
+1. **Type first:** body size (≥16px web), line-height, measure cap. Derive the spacing unit from the line-height (16/24 body → 8px unit; small UI can justify 4px).
+2. **Scale second:** a modular type scale rounded to fixed values; a spacing scale of multiples of the unit; both defined as tokens, never improvised.
+3. **Grid third:** margins, 12-column (→8→4 responsive) with fixed gutters from the spacing scale; add rows (modular grid) for card-heavy compositions.
+4. **Hierarchy fourth:** map content roles to a closed set of type levels; each adjacent pair differs by 1–2 contrast dials; more space above headings than below.
+5. **Detail last:** real punctuation, tabular figures in data, letterspaced caps for labels, balanced heading wraps, tightened display type, loaded (not synthesized) weights.
+6. **Break the grid once, if at all,** for the single element that deserves the emphasis.
+
+## Part 5 — Reference tokens (a defensible default system)
+
+Concrete starting values embodying all three books; adjust deliberately, never ad hoc.
+
+**Type scale (1.25 ratio, rounded):**
+- caption/label: 12px, line-height 16, +5% letterspacing if caps
+- secondary: 14px / 20
+- body: 16px / 24 (the base unit source)
+- large body / H4: 18px / 28
+- H3: 20px / 28, weight 600
+- H2: 25px / 32, weight 600–700, letterspacing -0.5%
+- H1: 31px / 36, weight 700, letterspacing -1%
+- display: 39–48px / ~1.1, weight 700–800, letterspacing -1.5–2%
+
+**Spacing scale (8px unit from 24px body leading):** 4, 8, 12, 16, 24, 32, 48, 64, 96.
+
+**Grid:** content max-width 1200–1280px; margins 24px (mobile 16px); 12 columns / 24px gutters desktop; 8 columns tablet; 4 columns / 16px gutters phone. Prose max-width 65ch regardless of container.
+
+**Heading spacing:** space-above = 2× space-below (e.g., H2: 48 above / 24 below). Paragraph spacing = 1 leading unit (24px); no first-line indents on screens.
+
+**Numbers:** `font-variant-numeric: tabular-nums` on tables, counters, prices in lists; right-align numeric columns; align mixed-size number+unit pairs on the baseline.
+
+## Part 5b — Dark mode and screen-rendering adjustments
+
+Print rules need adaptation for emissive screens; the classics' principles still decide the direction:
+
+- **Light text on dark appears heavier/blurrier (halation).** Compensate: drop one weight step (400 → 350/300 territory if available, or keep 400 but avoid 500+ body), or add +0.5–1% letterspacing on dark backgrounds.
+- **Pure white on pure black vibrates.** Use off-white text (~#E6E6E6-range) on near-black surfaces (#0E–#16 range) — Bringhurst's "honor the reading" applies to contrast comfort, not just ratio minimums.
+- **Thin hairline rules disappear or glare on dark.** Prefer background-shade separation between surfaces; where lines are needed, use low-opacity white (~8–12%).
+- **The grid and scale are theme-independent:** identical columns, spacing, and type levels in both modes; only color tokens change. If dark mode needs layout changes, the light layout was leaning on color to do structure's job.
+
+## Part 6 — Common violations and their fixes
+
+- **"It looks scattered":** no grid, or components sized to content whims. Fix: snap every block to columns; standardize card sizes to module multiples.
+- **"The headings float":** equal space above and below. Fix: double the space above.
+- **"Text feels tiring":** measure over 80ch or leading too tight for the width. Fix: cap at 65–75ch, or raise line-height toward 1.6.
+- **"Hierarchy is mushy":** six near-identical text styles. Fix: collapse to a closed set; force each adjacent pair to differ visibly on 1–2 dials.
+- **"Headline looks cheap":** default tracking at 40px+. Fix: -1–2% letterspacing, tighter leading, check the rag/wrap.
+- **"Table looks jittery":** proportional figures and left-aligned numbers. Fix: tabular figures + right alignment.
+- **"Fonts clash":** two similar sanses, or synthesized bold/italic. Fix: one family with real weights, or a genuinely contrasting pair.
+- **"Feels dated/fussy":** decoration without meaning — gradients on text, multiple rules, mixed alignments. Fix: Bringhurst's razor — remove everything that has no reason.
+
+## Quick audit checklist
+
+- [ ] A real grid exists: fixed gutters, whole-column spans, everything aligned; ≤1 deliberate violation per screen
+- [ ] Vertical spacing is multiples of one base unit tied to body line-height
+- [ ] Prose measure 45–75ch everywhere text runs long; wide measure compensated with leading
+- [ ] Closed type-level system; adjacent levels differ by 1–2 dials; no orphan near-duplicate styles
+- [ ] ≤2 type families; real weights/italics loaded; UI face legible at 12–16px with distinct Il1 0O
+- [ ] Headings bound to their content (space-above > space-below); no one-word heading wraps
+- [ ] Smart quotes, correct dashes, ellipsis character, non-breaking spaces where needed
+- [ ] Tabular figures + right alignment in numeric columns; caps labels letterspaced
+- [ ] Nothing decorative without a reason; the type disappears into the reading