Subjects

Visual Design Fundamentals

Covers modular type scales and why a constrained set of sizes beats arbitrary pixel values, line-height and line-length rules grounded in how eyes actually track text, color as a functional (not just decorative) property with an explicit link to WCAG contrast and color-blind failure modes, the 8-point spacing grid versus layout-grid columns/gutters as two distinct systems people conflate, the four levers of visual hierarchy with a worked form redesign, Jakob's Law and where consistency is non-negotiable versus where novelty is safe, and the diagnostic question for knowing when a visual fix is the right fix versus a coat of paint on a structural problem.

UX Writing and Microcopy

Covers the distinction between voice and tone with a worked example, the what/why/how-to-fix structure for error messages, the difference between first-use and cleared/filtered empty states, progressive disclosure and tooltip overload in onboarding copy, why specific button labels prevent destructive mistakes, why lorem ipsum breaks real layouts and what content-first design does instead, and the localization pitfalls (text expansion, idioms, fixed-width containers) that microcopy written only for English misses.

Information Architecture and Navigation

Covers what information architecture actually is versus the navigation UI that surfaces it, the three organization schemes (hierarchy, sequence, matrix) and when each fits, the depth-vs-breadth tradeoff and Hick's Law, open and closed card sorting, tree testing as the validation step, Indi Young's mental-model-vs-system-model gap, the core navigation patterns (hub-and-spoke, tab bars, hamburger menus, breadcrumbs, mega menus) and how to choose between them, and when search should replace browse instead of papering over a broken structure.

Design Critique, Feedback, and Portfolio Presentation

Covers the 'I like / I wish / What if' critique framework and why it beats unstructured reactions, separating critique of the work from the person, the difference between vague and actionable feedback with concrete rewrites, how to receive feedback without getting defensive, the Problem/Process/Decisions/Outcome structure for presenting a case study in an interview, the most common portfolio mistakes that read as junior, and how to answer 'what would you do differently' well.

Responsive and Mobile Design

Covers the precise difference between responsive, adaptive, and mobile-first approaches and why mobile-first is now the default; breakpoints and fluid grids using relative units; the exact touch-target minimums (44x44pt iOS, 48x48dp Material) and their Fitts's Law justification; the key iOS HIG vs. Material Design differences and when to follow platform convention vs. diverge for brand consistency; mobile gesture vocabulary and the discoverability problem; and progressive disclosure as Hick's Law applied to small screens.

Design Ethics and Dark Patterns

Covers Harry Brignull's dark pattern taxonomy (confirmshaming, roach motel, forced continuity, sneak into basket, trick questions, misdirection, privacy zuckering) with a named example per pattern, the practical test for where persuasive design becomes manipulative, privacy-by-design and informed consent by default, GDPR and emerging dark-pattern regulation as a business risk beyond ethics, and a concrete escalation playbook for the classic interview scenario of being asked to implement a pattern that crosses the line.

Design Systems, Components, and Dev Handoff

Covers the real distinction between a style guide, a component library, and a full design system; Brad Frost's atomic design methodology (atoms through pages) worked through a product card example; design tokens as platform-agnostic data that make theming and rebrands a single-source edit; component library governance (single source of truth, versioning, the rule-of-three contribution model); how Figma Dev Mode and shared tokens change what a 'redline' communicates and what still needs a handoff conversation; when a formal design system pays off versus becomes premature overhead for a small team; and component API design as a design decision, not just an engineering one.