Essential UX Books Every Designer Should Read

These six books keep appearing on UX reading lists for a reason. Each one teaches something that can't be easily reduced to a Medium post or a YouTube tutorial.

The Design of Everyday Things — Don Norman

Who it's for: Everyone, but especially people new to design thinking.

This is the foundational text for understanding how humans interact with objects and interfaces. Norman introduces concepts like affordances, signifiers, feedback loops, and mental models — the vocabulary that underlies all of UX design. Reading it reframes how you see every door handle, elevator button, and software interface you encounter.

Key takeaway: When users fail to use a product correctly, it's almost always a design failure, not a user failure. Design for how people actually behave, not how you wish they would.

When to read it: Early in your UX career, before you get too attached to any one methodology. It will shift your baseline.

Don't Make Me Think — Steve Krug

Who it's for: Designers, product managers, and anyone who works on web products.

Short, practical, and opinionated. Krug argues that good usability means users never have to think about how to use your interface — it should just work. He covers navigation, search, homepage design, and mobile usability with clear examples and a sense of humor.

Key takeaway: Users don't read — they scan. Design for scanning, not reading. Remove anything that makes users stop and think.

When to read it: Before your first usability test. The chapter on how to run cheap, fast usability studies is worth the price of the book alone.

About Face: The Essentials of Interaction Design — Alan Cooper

Who it's for: Mid-career designers who want a deeper theoretical foundation for interaction design decisions.

Denser and more systematic than the others on this list. Cooper introduces the concept of Goal-Directed Design — designing for what users are trying to accomplish, not just the tasks they're performing. It's where you'll find rigorous thinking on personas, scenarios, and design patterns.

Key takeaway: Understand the difference between goals (what someone wants to achieve), activities (what they do to achieve it), and tasks (the specific steps). Design for goals, not tasks.

When to read it: After you've been working in UX for a year or two and want to formalize your thinking.

Lean UX — Jeff Gothelf and Josh Seiden

Who it's for: Designers working in agile or product teams.

Lean UX argues that heavy deliverables (full specification documents, polished annotated wireframes for every screen) are often a waste of time. Instead, work in smaller cycles, test assumptions quickly, and design collaboratively with your team rather than in isolation.

Key takeaway: Outcomes over outputs. The goal is behavior change in users (the outcome), not the number of screens you designed (the output).

When to read it: When you join your first product team and realize that your process from design school doesn't map onto sprint cycles.

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days — Jake Knapp

Who it's for: Designers who want a structured process for tackling ambiguous problems fast.

The Design Sprint is a five-day workshop process developed at Google Ventures for validating ideas before building them. The book walks you through each day: mapping the problem, sketching solutions, deciding on one direction, prototyping, and testing with real users. It's prescriptive in a useful way.

Key takeaway: You can test a major product hypothesis with a realistic prototype and five users in five days. Most "big decisions" don't need months of research — they need a well-structured sprint.

When to read it: Before you run your first design sprint, or when your team is stuck on a decision that keeps getting deferred.

Articulating Design Decisions — Tom Greever

Who it's for: Designers who struggle to get their work approved or who want to communicate better with stakeholders.

Greever addresses the practical challenge that nobody teaches in design school: how to talk about design in meetings where not everyone is a designer. The book covers how to present work, how to handle pushback, how to make a case for a design decision using business and user language.

Key takeaway: Design decisions need to be explained in terms of user goals, business outcomes, or technical constraints — not aesthetic preference. Learn the language that non-designers respond to.

When to read it: When you start presenting work to stakeholders and realize that being right about the design isn't enough — you also have to be persuasive about it.