Reference Library. Everything you will want to look up again.
The other twenty guides teach. This one is for the moments after: when you need a name, a number, a term, a checklist before you ship, or the next book to read. Keep it open in a tab while you work. It is built to be searched, filtered and ticked, not read once.
TeachersAbout a hundred people, from Bush to Ink & Switch
By the end you will be able to
Place any designer or idea you meet on a map of the field: who came first, who learned from whom (understand)
Define the core vocabulary of product design in one plain sentence each, and know which guide goes deeper (remember, understand)
Recall the handful of numbers that decide most interface arguments: target sizes, contrast ratios, line lengths, timing (apply)
Run twelve master checklists on your own product, from a problem brief to a 60-item ship check (evaluate)
Diagnose the sixty mistakes solo creators make most, and name the fix (analyse)
Plan a reading path of real books, essays and talks matched to your level, much of it free (create)
How to use this library
A reference is a tool you reach for in the middle of work, so it should answer one question fast and then send you somewhere deeper.
Every entry here is short on purpose. A designer gets three sentences, a term gets one, a mistake gets a line and a fix. Each one points to the guide that teaches it properly. If an entry is enough, close the tab and keep working. If it is not, follow the link.
There are five shelves. The first is people: who shaped the field and what to study first from each of them. The second is words and rules: the glossary, the laws, the numbers. The third is checklists, the most practical shelf, meant to be run on your own product again and again. The fourth is mistakes. The fifth is where to learn next: books, essays, talks and the places to look for references.
Five shelves, five questions. Reach for the shelf that matches the question in your head. Checklists sit in the middle because they turn the rest of the course into something you can run on Friday afternoon.
Do
Keep this guide pinned in a tab while you design and build.
Run one checklist per working session, not all twelve at once.
Use the search boxes. Every list here is filterable.
Follow the link when an entry raises a question.
Don't
Try to read it top to bottom in one sitting.
Treat a one-line definition as understanding. It is a reminder.
Collect names instead of studying the work. Pick one person per month.
Tick a checklist item you have not actually checked.
For the solo creator
You have no design reviewer, no QA team and no copy editor. The checklists in Part three are those people, compressed. Your ticks are saved in this browser, so you can run the ship checklist across a week of evenings and pick up where you left off.
Warm-up
You are about to release a new onboarding flow tonight. You have twenty minutes. Which shelf of this library earns those twenty minutes best?
With a deadline and a concrete artefact, the highest-value move is to check the thing against a checklist. The other shelves are for learning and orientation, which matter, but not twenty minutes before shipping.
Diagnostic
A friend says "the button is too small, Fitts says so". What is the most precise version of that argument?
Fitts's law relates movement time to distance and width. It sets no fixed pixel size; the platform minimums come from guidelines. Option d describes Hick's law. If this felt shaky, the Laws card in Part two and The Human Mind cover it.
Part one
People and lineage
Design is a conversation that has been running for a century. Knowing who said what, and who they were answering, keeps you from rediscovering old ideas badly and helps you read new ones critically. These four chapters give you a timeline, a family tree, a directory of about a hundred people, and the ten ideas they keep repeating.
1
A timeline of product design, 1945–2026
Drawn from the history taught across the course
Most of what you use daily was invented decades before you met it: the mouse in the 1960s, windows in the 1970s, the grid in the 1950s, the core usability rules by the early 1990s.
The timeline has three lanes. The top lane is objects, graphics and type: the physical and visual tradition that gave software its sense of order. The middle lane is interaction and software: the machines and products themselves. The bottom lane is ideas, books and standards: the moments when someone wrote down what the field had learned.
Read it in three ways. First, look for clusters. The years 1968 to 1984 hold almost the whole personal computer, from Engelbart's demo to the Macintosh. The years 2007 to 2014 hold almost the whole mobile era, from the iPhone to Material Design. Second, look for gaps between lanes: ideas often arrive long before products (Bush described a linked personal library in 1945; the web arrived in the 1990s). Third, look at the bottom lane and notice how few of the books are recent. The fundamentals settled early. What changes is the material.
1945 to 1989: the foundations. Industrial design (Braun, the Butterfly Stool), Swiss graphic design and the first human factors research arrive in the same decade, then the personal computer is invented between Sketchpad (1963) and the Macintosh (1984).1990 to 2026: the spread. The web, then mobile, then AI. Notice the steady drumbeat of standards (WCAG 1.0, 2.0, 2.2) and of small, opinionated books (Don't Make Me Think, Refactoring UI, Shape Up). On narrow screens, scroll the figure sideways.
Five turning points worth knowing in detail
1968, the Mother of All Demos. Douglas Engelbart showed the mouse, hypertext links, shared screens and live collaborative editing in one 90-minute presentation in San Francisco. Much of the next fifty years was spent shipping what he showed.
1973 to 1981, Xerox PARC. The Alto and then the Star brought windows, icons, menus, a pointer and WYSIWYG editing together. Larry Tesler's work on modeless editing and cut, copy and paste came from here.
1984, the Macintosh. The graphical interface became a product people could buy. Susan Kare's icons and Bill Atkinson's QuickDraw and MacPaint set the visual and interaction vocabulary. Apple's Human Interface Guidelines were published as a book in 1987.
2007, the iPhone. Direct manipulation with a finger, inertial scrolling and rubber-band bounce made the physics of a list part of its meaning. A year later the App Store opened, and a solo developer could reach the world.
2022, ChatGPT. A conversational interface to a large language model reached a mass audience within weeks. Designers now work with systems whose output is probabilistic, which reopened old questions of feedback, trust and control. See Designing with AI.
Myth
"Flat design began with iOS 7." Swiss graphic design, Otl Aicher's pictograms and Microsoft's Metro design language (Windows Phone 7, 2010) were all flat before iOS 7 in 2013. What iOS 7 did was make flatness the default for a huge software platform, and it was followed by Material Design in 2014, which added depth back as a system of elevation.
Do
Read an old source when a new trend cites it. The original is usually more careful.
Ask of every new interface idea: which earlier idea is this a version of?
Notice which ideas have survived forty years. Those are the safe bets.
Don't
Assume the latest platform style is the best one. Styles cycle: skeuomorphic, flat, glassy.
Treat history as trivia. It is a library of solved problems.
Confuse a launch date with an invention date.
In the wild
Apple Liquid GlassApple, 2025
A translucent material across Apple's platforms, introduced at WWDC 2025. It echoes Aqua (2001) and the depth debates of 2013. Visual styles return in cycles; the principles of legibility and hierarchy do not change.
Command palettesSublime Text, VS Code, Linear, Raycast
Type to find any action. A modern form of the command line and of Raskin's argument for fast, modeless commands. Many "new" patterns are old ideas meeting a new audience.
Local-first appsInk & Switch essay, 2019
Software that keeps your data on your device and syncs, rather than living only on a server. A reaction to cloud-only software, built on decades of work on personal computing.
Exercise 1.1 30 minutes · on a product you use daily
Date the ideas in your favourite app
Open an app you use every day, such as your notes or reading app.
List ten interface ideas you can see: windows, a sidebar, pull-to-refresh, swipe actions, search, undo.
For each, write the earliest date and source you can place it at, using this timeline and the directory below.
Mark the one idea that seems genuinely new (after 2015). Ask what older idea it extends.
You're done when: you have a ten-row table of idea, earliest date, source, and one sentence on the newest idea's ancestry.
Beginner
Competent
Strong
Lists ideas with guesses at dates.
Dates most ideas correctly and names the source product or person.
Traces the newest idea to at least two ancestors and says what it changed.
2
Who learned from whom
A map of seven threads
The field is a few long threads, not a crowd of separate geniuses: functional industrial design, quiet Japanese design, typography and the grid, augmenting human intellect, information graphics, usability science, and calm technology.
Each row of the map is one thread. Solid lines mean a direct link: someone worked with, studied under or took over from someone else. Dashed lines mean a link of ideas: someone cited, admired or extended the earlier work. The map is deliberately incomplete. Its job is to show you that when you study one person, you are joining a conversation, and to point you at the hubs.
Seven threads, four eras. Rows from the top: function and reduction, quiet Japanese design, type and grid, augmenting intellect, information graphics, usability science, calm technology. Bold-edged boxes are hubs: study one of them and the rest of the row makes sense. Some links are left out to keep the map readable; for example Bret Victor's talks also build openly on Engelbart and Kay, and the founding staff of the Mac team included several people from PARC.
Reading the threads
Function and reduction. The Bauhaus taught that form should come from purpose and industrial production. The Ulm School of Design (HfG Ulm) made that systematic, and Braun's collaboration with Ulm teachers shaped Dieter Rams. Jony Ive has spoken openly of admiring Rams. In software, this thread shows up as restraint: fewer controls, honest materials, nothing decorative that does not help. Study it in Breakdowns: Objects.
Quiet Japan. The mingei (folk craft) movement of Soetsu Yanagi valued anonymous, everyday objects. His son Sori Yanagi designed the Butterfly Stool and plain kitchen tools. MUJI, founded in 1980 with Ikko Tanaka as art director, sold "no-brand quality goods"; Kenya Hara took over as art director in 2002 and Naoto Fukasawa joined its advisory board. The lesson for software is emptiness as a receptive space, not as a lack. See MUJI as a system.
Type and grid. Jan Tschichold's New Typography argued for asymmetric, functional layout; Swiss designers such as Josef Müller-Brockmann turned the grid into a discipline; Massimo Vignelli carried it into corporate and transit design. Robert Bringhurst wrote the modern bible of book typography, and Matthew Butterick and Oliver Reichenstein brought that care to screens. See Typography.
Augmenting intellect. Vannevar Bush imagined the memex. Douglas Engelbart, who read Bush, built the first working system for augmenting human intellect. Alan Kay and colleagues at PARC designed personal, graphical computing. The Mac team shipped it. The iPhone team made it physical. Bret Victor keeps asking what this thread forgot.
Information. William Playfair invented the line and bar chart; Charles Minard drew Napoleon's march to Moscow in 1869. Jacques Bertin named the visual variables. Edward Tufte turned this into a design ethic for data. See Information & Data.
Usability science. Gestalt psychologists described how we group what we see. Experimental psychologists measured pointing (Fitts), choosing (Hick) and remembering (Miller). Card, Moran and Newell applied this to computers; Norman and Nielsen turned it into a profession; Krug and Yablonski made it short enough to use daily. See The Human Mind.
Calm technology. Mark Weiser and John Seely Brown at PARC argued that technology should move between the center and periphery of attention. Amber Case turned that into eight practical principles; Ink & Switch argue for local-first software that respects ownership. See Honest & Calm.
Key idea
Study one hub per thread, not twenty names. Rams, Hara, Bringhurst, Engelbart, Tufte, Norman and Weiser will carry you through almost everything else.
For the solo creator
Choose the two threads closest to your product and go deep on them. If you make a reading app, that is type and grid plus calm technology. If you make a data tool, it is information plus usability science. Depth in two threads beats a shallow tour of seven.
Do
When you read someone, look up who they cite. Read one of those next.
Notice when two threads meet in a product: iA Writer is type and grid plus calm.
Keep your own map. Add people as you meet them.
Don't
Treat any one person as the source of truth. Every hub had teachers.
Copy a thread's visual style without its reasons.
Assume influence where there is only resemblance.
Check yourself
You are designing a quiet, text-first journaling app. Which two threads should you study most closely?
A text-first, quiet product lives or dies on typography and on how it treats attention. Usability science always matters, but the specific taste of this product comes from the type and calm threads, and MUJI-style emptiness.
3
The designer directory
About a hundred people, in eight groups
For each person: what they did, the idea worth keeping, the one thing to study first, and where this course goes deeper.
The groups follow the threads from the lineage map, plus two practical ones: the scientists whose experiments the laws of UX quote, and the people who teach the practice of finding problems and shipping. Use the filter to show one group or search for a name or idea. Try searching for "attention", "grid" or "free".
A rule for using this directory: study the work, not the person. Every entry ends with something concrete to read, watch or use. Do that, then try the idea on your own product, then move on. One person per week is a good pace; one per month is fine.
Lab: filter the directory
0people shown
The bars show how many matches each group holds. Search looks inside the whole entry, so "Japan", "1984" or "PARC" all work.
Cognition and usability
The people who turned psychology into rules you can use on a screen.
Cognition and usability. Norman's two gulfs, the shared core of this group: good design narrows both.
Don Norman
Cognitive scientist; Apple, then co-founder of Nielsen Norman Group
Gave designers their working vocabulary: affordances, signifiers, mapping, constraints, feedback and conceptual models. His core claim is that when people make errors with a device, the design is usually at fault, not the person.
Study firstThe Design of Everyday Things (1988, revised 2013), chapters 1 and 2.
Usability engineer; co-founder of Nielsen Norman Group
Made usability cheap and routine. His ten usability heuristics (first published with Rolf Molich in 1990, refined in 1994) remain the most used checklist in the field, and his discount usability argued for small, frequent tests over big studies.
Study firstThe ten heuristics article on nngroup.com, then Usability Engineering (1993).
People do not read, they scan; they do not optimise, they satisfice; and they muddle through. So make every page self-evident, and if it cannot be, self-explanatory. He also made a monthly do-it-yourself usability test feel achievable for anyone.
Study firstDon't Make Me Think (2000; Revisited, 2014). A short afternoon.
Argued that software should be designed around users' goals rather than tasks or features, and introduced personas as a design tool in The Inmates Are Running the Asylum (1999). About Face is his long manual of goal-directed design.
Study firstAbout Face (1995; later editions with Reimann, Cronin and Noessel), part one.
Early Apple human-interface designer; Nielsen Norman Group partner
"Tog" helped write Apple's early interface guidelines and later published a widely used list of first principles of interaction design: anticipation, autonomy, consistency, defaults, latency reduction and more.
Study firstHis essay "First Principles of Interaction Design" on asktog.com.
Coined "direct manipulation" (1983), wrote the Eight Golden Rules of interface design, and summed up information visualization as "overview first, zoom and filter, then details on demand". Later turned to human-centered AI.
Study firstDesigning the User Interface (first edition 1987), then Human-Centered AI (2022).
Information architect; co-founder of Adaptive Path
Drew the five planes of user experience, strategy, scope, structure, skeleton and surface, as a stack where each plane constrains the one above. Also coined the term Ajax in 2005.
Study firstThe Elements of User Experience (2002). The diagram alone is worth it.
Wrote the standard book on organising, labelling, navigation and search systems, known as "the polar bear book". Morville's UX honeycomb (useful, usable, desirable, findable, accessible, credible, valuable) is a handy lens.
Study firstInformation Architecture for the World Wide Web (1998; now Information Architecture).
Collected the psychology most useful to interface designers into a short set of named laws, Fitts, Hick, Jakob, Miller, Tesler, peak-end and others, each with a plain explanation and examples.
Study firstThe website lawsofux.com, then the book Laws of UX (2020).
Usability researcher; founder of UIE, co-founder of Center Centre
Known for evidence-driven stories about design and business, such as "The $300 Million Button" (2009), where removing a forced registration step at checkout raised a retailer's sales. Champions designing from observed user behaviour.
Study first"The $300 Million Button" essay, then his articles on design maturity.
Programmer, author, co-creator of the Head First books
Argues that successful products make users better at something they care about, so design for the user's skill and the context of use, not for your product's features. Watch out for cognitive leaks that drain the willpower people need to get good.
Study firstBadass: Making Users Awesome (2015). Highly visual, quick to read.
Made the case for designing mobile first: the small screen forces you to decide what matters. Also wrote the practical, evidence-based book on web forms, labels, layout and inline validation.
Study firstMobile First (2011), then Web Form Design (2008).
Gave the small moments of a product a structure: triggers, rules, feedback, and loops and modes. A microinteraction done well is where a product earns its feel.
Teaches information architecture for everyone, as making sense of messes: name the things, agree on the language, then structure it. Practical and friendly.
The researchers whose experiments the laws of UX quote, often loosely. Read the originals once.
Scientists behind the laws. Fitts's law: a far, big target can be as fast to hit as a near, tiny one. The ratio matters.
Paul Fitts
Psychologist, US Air Force and Ohio State
In 1954 showed that the time to move to a target grows with distance and shrinks with target width, in a predictable logarithmic way. This is the reason for big touch targets, edge and corner menus, and context menus at the pointer.
Study firstRead a plain summary first; his 1954 paper on the information capacity of the human motor system is short.
Measured in 1952 and 1953 that decision time grows with the logarithm of the number of equally likely choices. It applies to unfamiliar, comparable options; it does not mean fewer menu items is always faster.
Study firstThe Hick's law entry in Laws of UX, then the chapter in The Human Mind.
His 1956 paper "The Magical Number Seven, Plus or Minus Two" showed limits on how much we can hold and judge at once, and introduced chunking. It is often misquoted as a rule for menu length; it is not one.
Study firstThe paper itself, which is readable, then Cowan below.
Argued in 2001 that working memory holds about four chunks, not seven. Design consequence: do not ask people to remember anything across screens if you can show it instead.
Study firstHis 2001 paper "The magical number 4 in short-term memory".
Stuart Card, Thomas Moran and Allen Newell's The Psychology of Human-Computer Interaction (1983) modelled people as information processors, with the GOMS and keystroke-level models for predicting task time. The book that made HCI a science.
Study firstRead about the keystroke-level model; use it to compare two flows by counting steps.
Wertheimer, Koffka and Köhler described how perception organises parts into wholes: proximity, similarity, closure, continuity, figure and ground. Every layout decision about grouping relies on these.
Study firstAny good summary of the Gestalt principles, then test them on your own screen.
Her feature integration theory (1980) explained why some things pop out instantly (a single red item among grey) while others need serial search. The basis of using one accent colour for one important thing.
Study firstA summary of feature integration theory and preattentive features.
Their 1999 "invisible gorilla" experiment showed that people counting basketball passes often miss a person in a gorilla suit walking through. Attention is narrow; a change you do not draw attention to may be missed.
Showed with Amos Tversky how judgement departs from rational models: framing, anchoring, loss aversion. With colleagues he described the peak-end rule: we remember an experience by its most intense moment and its end.
Study firstThinking, Fast and Slow (2011), parts one and five.
Coined "satisficing": people choose the first option that is good enough. In The Sciences of the Artificial (1969) he defined design broadly as devising courses of action to change existing situations into preferred ones.
Study firstThe Sciences of the Artificial, chapter five on design.
His behaviour model says a behaviour happens when motivation, ability and a prompt meet at the same moment (B = MAP). Useful for designing helpful habits, and a warning about how easily it is misused.
Described flow: deep, absorbed engagement that happens when challenge matches skill and feedback is clear. A design goal for tools of thought, and a reason to protect people from interruption.
Study firstFlow: The Psychology of Optimal Experience (1990).
Studies how people switch attention at work. Her research on interruptions shows how long it can take to return to an interrupted task, and how screens fragment focus.
Makers of physical things whose lessons translate directly to software: restraint, honest materials, one clear control.
Industrial and object design. The shared move: remove until one obvious control and one clear surface remain.
Dieter Rams
Industrial designer; Braun, 1955–1995; Vitsœ
Wrote ten principles of good design (innovative, useful, aesthetic, understandable, unobtrusive, honest, long-lasting, thorough, environmentally friendly, as little design as possible) and lived them in radios, shavers, calculators and shelving. "Less, but better" is his phrase.
Study firstLess and More (2009), and Gary Hustwit's documentary Rams (2018).
Designs objects that fit behaviour people already have, "without thought". His wall-mounted CD player for MUJI starts with a pull cord, like a kitchen fan. With Jasper Morrison he curated Super Normal (2006), a show of perfected ordinary things.
Study firstThe MUJI CD player, then Super Normal: Sensations of the Ordinary.
Distinguishes Western simplicity from Japanese emptiness: an empty vessel that invites the user to bring meaning. His exhibitions and books treat design as the reawakening of the familiar.
Study firstDesigning Design (English edition 2007), the chapters on emptiness and MUJI.
Champions the "super normal": objects whose quality comes from fitting everyday life so well that you stop noticing them. Distrusts design that shouts for attention.
Study firstSuper Normal (with Fukasawa), then his essays on the everyday.
Designed furniture (the Lounge Chair, 1956), exhibitions and films such as Powers of Ten (1977). Their working method was relentless prototyping and attention to how details serve the whole.
Study firstWatch Powers of Ten (9 minutes), then read their "Design Q&A".
Led Apple's design through the iMac G3, iPod, iPhone and iPad, and led the 2013 iOS 7 redesign. His work shows the power of material honesty and obsessive finish, and the risk of thinness at the expense of use.
Study firstStudy the original iPod's click wheel, then the iOS 7 transition.
Co-founder and head of design, Teenage Engineering
Teenage Engineering's OP-1 synthesizer (2011) and Pocket Operators made constraint and playfulness a brand. The company also designed the hardware of Panic's Playdate.
Study firstWatch someone use an OP-1; notice how every control is visible and labelled.
Designed the Butterfly Stool (1954) and plain, durable kitchen tools still in production. Son of Soetsu Yanagi, founder of the mingei folk-craft movement; believed good design comes from use, not from a drawing.
Study firstThe Butterfly Stool and his stainless kettle: notice the absence of style.
Created the Game & Watch and the Game Boy. His idea of "lateral thinking with withered technology" means using cheap, mature technology in new ways, which gave the Game Boy its battery life and durability.
Study firstThe Game Boy chapter in Breakdowns: Objects.
Designed telephones, tractors and thermostats starting from the human body. Designing for People (1955) and his "Joe and Josephine" body-measurement charts made ergonomics a design discipline.
Study firstDesigning for People, the opening chapters.
Known for the MAYA principle, "most advanced yet acceptable": people embrace the new when it is still familiar enough to recognise. A good test for any redesign.
Study firstRead about MAYA; apply it to your next visual refresh.
The grid, the typeface and the page. Most of a screen is type, so this group teaches most of what a screen looks like.
Graphic design and type. The grid is the invisible agreement that makes a page feel calm.
Massimo Vignelli
Graphic designer, New York
Believed in a few typefaces, a grid, and discipline. Designed the 1972 New York subway map and the Unigrid system for the US National Park Service brochures.
Study firstThe Vignelli Canon (2010), a short free PDF.
A central figure of the Swiss international style. His concert posters for the Zurich Tonhalle and his manual on the grid taught generations to organise a page objectively.
Wrote Die neue Typographie (1928) for asymmetric, functional modernism, then later returned to classical book design and set composition rules for Penguin Books in the late 1940s. Designed Sabon.
Study firstThe Form of the Book, essays on classical book typography.
Made simple, durable corporate marks: IBM, ABC, UPS (1961), and NeXT (1986). Argued that a logo is identification first and only gains meaning through the thing it represents.
Graphic designer; co-founder of the Ulm School of Design
Designed the pictograms and identity for the 1972 Munich Olympics and the Lufthansa identity. His pictograms on a strict grid are the ancestors of modern icon sets.
Study firstLook at the Munich 1972 pictograms side by side; notice the shared grid and angles.
Designed Univers (1957), a family planned as a system of weights and widths, and Frutiger, created for signs at Charles de Gaulle airport and later a classic UI and signage face.
Study firstCompare Univers' numbered weights to a modern variable font.
Designed Verdana and Georgia (1996) for Microsoft, drawn first as screen bitmaps for low-resolution displays, as well as Bell Centennial for phone books. The model for designing type for the medium.
Study firstSet a paragraph in Verdana and Georgia at 13 px on a low-resolution screen.
His book is the standard reference on typographic style: measure (45 to 75 characters, around 66 for a single column), leading, scales, and the idea that typography exists to honour content.
Study firstThe Elements of Typographic Style (1992), chapters 1 and 2.
Wrote a free web book that makes typography practical for anyone who writes. Points out that most text you set is for reading, so body text deserves most of your care.
Study firstButterick's Practical Typography (free online), "Typography in ten minutes" first.
Inventors of the interfaces you use, and the independent makers who refined them. Study their products, not just their words.
Software and interaction. Direct manipulation and immediate feedback, the shared core of this group.
Vannevar Bush
Engineer; director of US wartime research
In "As We May Think" (1945) imagined the memex, a desk that stores a person's books and records and links them with associative trails. The idea behind hypertext and personal knowledge tools.
Study firstThe essay itself, in The Atlantic, July 1945.
Set out to augment human intellect. In 1968 demonstrated the mouse, hypertext, outlining, windows and real-time collaboration in what became known as the Mother of All Demos.
Study firstWatch parts of the 1968 demo; read his 1962 report "Augmenting Human Intellect".
Coined "hypertext" in the 1960s and imagined Project Xanadu, with two-way links and visible connections between documents. A reminder that the web left out some of the best ideas.
Imagined the Dynabook, a personal computer for children of all ages, and led work on Smalltalk and the overlapping-window interface at PARC. Thinks of computers as a medium for thinking, not a tool for clerks.
Study firstHis 1972 paper "A Personal Computer for Children of All Ages".
Fought modes in interfaces (his licence plate read NOMODES), and worked on modeless editing and cut, copy and paste at PARC. Tesler's law: every application has irreducible complexity, and someone must deal with it, either the user or the maker.
Study firstRead about Tesler's law, then look for modes in your own app.
Wrote QuickDraw and MacPaint for the original Macintosh, and created HyperCard (1987), which let non-programmers build linked, interactive stacks. Showed that a tool can make people authors.
Study firstRead about HyperCard and why so many people built with it.
Designed the original Macintosh icons and fonts (Chicago, Geneva) on a 32 × 32 grid, and later the card deck for Windows 3.0 Solitaire. Proved that a few pixels can carry warmth and meaning.
Study firstStudy her trash can, watch and happy Mac icons at actual size.
Known for the inertial scrolling and rubber-band bounce of the original iPhone, which made a list feel like a physical object. Prototyped interactions in code to feel them rather than describe them.
Study firstScroll to the end of any iOS list slowly, then fast. Notice the physics.
Designer; Delicious Library, Apple, Push Pop Press, Facebook Paper
Made interfaces that feel like physical objects you can push, peel and fling, from Delicious Library's shelves to Facebook Paper (2014). Built prototypes with real physics.
Study firstSearch for his 2011 talk demonstrating Push Pop Press's Our Choice book.
Created Tweetie, which introduced pull-to-refresh, and the word game Letterpress (2012). A model of the solo maker who designs and builds every detail.
Study firstStudy Letterpress: flat colour, one font, every action animated meaningfully.
Reeder made RSS calm and fast through typography, gesture and restraint. In 2024 he released a new Reeder built around a single timeline and moved the old app to Reeder Classic.
Study firstUse Reeder Classic for a week; notice what the gestures save you.
Wrote "Web Design is 95% Typography" (2006), then built iA Writer (2010): a writing app with almost no settings, focus mode and syntax highlighting for prose. Writes long, careful essays about design decisions.
Study firstHis essay, then iA Writer's focus mode.
Built Instapaper (2008), which made saving and reading articles later calm and readable, and Overcast (2014), a podcast player with smart speed and voice boost. First lead developer at Tumblr.
Study firstInstapaper's reading view and Overcast's settings: few, well chosen.
A small Portland company making carefully crafted Mac software (Transmit, Coda, Nova), publishing games (Firewatch, Untitled Goose Game) and the Playdate handheld. Proof that a small team can sustain craft for decades.
Study firstLook at the polish of Transmit or Nova, and at Playdate's crank.
Argues that creators need an immediate connection to what they create. "Magic Ink" (2006) says most software is information software and should reduce interaction; "Inventing on Principle" (2012) shows live, direct tools. Now works on Dynamicland.
Study firstWatch Inventing on Principle, then read Magic Ink (both free).
Previously led design systems work at Airbnb. Linear made fast, keyboard-first, opinionated issue tracking a design benchmark: few options, strong defaults, speed as a feature.
Study firstUse Linear's command menu and keyboard shortcuts for an hour.
Refactoring UI teaches visual design tactics for developers: hierarchy by de-emphasis, a spacing scale, limited colours and type sizes. Wathan also created Tailwind CSS, which bakes those constraints into code.
Wrote ten laws of simplicity (reduce, organise, time, learn, differences, context, emotion, trust, failure, the one) and for years published the Design in Tech reports on design's role in technology companies.
Study firstThe Laws of Simplicity (2006), under 100 pages.
Writes about books, reading and software with care: "Books in the Age of the iPad" (2010), "Subcompact Publishing" (2012), "Fast Software, the Best Software" (2019). Designs his own newsletters and walking books.
Study first"Fast Software, the Best Software", then "Books in the Age of the iPad".
The Shape of Design (2012) is about the why of design; his talk-essays "The Web's Grain" (2015) and "Everything Easy is Hard Again" (2017) are about building with the medium.
Study firstThe Shape of Design (free to read online).
Wrote Shape Up: fix the time (the appetite), shape the work at the right level of abstraction with breadboards and fat-marker sketches, bet on it, and let the builders find the details.
With colleagues, popularised jobs to be done: people hire a product to make progress in a particular circumstance. Look at the job, not the demographic.
Shows that positioning is context: who it is for, what they would use otherwise, and what makes you different and valuable. Bad positioning makes good products look bad.
The opportunity solution tree connects an outcome to customer opportunities, then to solutions and experiments. Recommends weekly contact with customers.
Showed that simple checklists save lives in surgery by catching the steps experts skip under pressure, and distinguished do-confirm from read-do lists. The reason this library has checklists.
How to show numbers and evidence honestly, so a reader can think with them.
Information and data. Tufte's small multiples: comparison is the point of most charts.
Edward Tufte
Statistician and information designer
Maximise the share of ink that shows data, remove chartjunk, compare with small multiples, and show causality and evidence honestly. Coined "sparkline".
Study firstThe Visual Display of Quantitative Information (1983).
Their 1984 experiments ranked how accurately people read encodings: position on a common scale best, then length, angle, area, and colour worst. The reason bars usually beat pies.
Study firstTheir 1984 paper on graphical perception.
The conscience of the field: attention, honesty, ownership and who gets left out.
Ethics, calm and inclusion. Weiser and Brown's center and periphery, and the ethic of not stealing attention.
Mark Weiser and John Seely Brown
Researchers, Xerox PARC
Weiser described ubiquitous computing (1991); with Brown he argued for calm technology (1995), which informs without demanding focus and moves easily between the center and periphery of attention.
Study first"Designing Calm Technology" (1995), short and free.
Turned calm technology into eight principles: require the smallest possible amount of attention, inform and create calm, use the periphery, amplify the best of technology and humanity, and more.
Coined "dark patterns" in 2010 to name interfaces that trick people, and catalogued them. Now uses "deceptive patterns" and works as an expert witness in cases about them.
Study firstDeceptive Patterns (2023), and deceptive.design.
Co-founded the Center for Humane Technology (2018) and campaigned for "time well spent", criticising products designed to capture attention at users' expense.
Study firstHis "How a handful of tech companies control billions of minds" TED talk (2017).
Their 2019 essay "Local-first software" (Kleppmann, Wiggins, van Hardenberg, McGranaghan) set out seven ideals for software that keeps data on your device, works offline and still collaborates. Behind the Automerge library.
Reframes disability as a mismatch between a person and their environment, and shows how solving for one person can extend to many: permanent, temporary and situational.
No one matches. Try a shorter word, or choose "All".
A note on accuracy
Entries state only well-documented facts: published works, products and dates. Where a date is approximate it says so. Many famous design "quotes" online are misattributed, so this directory paraphrases ideas instead of quoting. If you want the exact words, read the source named in "Study first".
For the solo creator
The independent makers in the software group (Brichter, Rizzi, Reichenstein, Arment, Panic) are your closest peers: small teams or single people who design and build. Study their products more than their talks. Open the app, use it for a week, and write down three decisions you would steal.
Do
Pick one person a week and do their "study first" item.
Write one paragraph after each: the idea, and where it applies in your product.
Prefer primary sources (their book, talk or product) over summaries of them.
Don't
Collect quotes for slides. Use ideas for decisions.
Follow only people from one group. The interesting work is where groups meet.
Take any one person's rules as universal; each wrote for a context.
Exercise 3.1 4 weeks · 1 hour a week
A four-person apprenticeship
Pick four people from four different groups whose work relates to your product.
Each week, do one person's "study first" item. Take notes by hand.
Write a one-page memo: the idea, a picture of where it shows up in a real product, and one change it suggests for your own product.
Make the change, or write down precisely why you will not.
You're done when: you have four one-page memos and at least two shipped changes traced back to a named person's idea.
Beginner
Competent
Strong
Summarises what each person said.
Connects each idea to a specific screen in your product.
Ships changes, and notes where two people's ideas conflict and which you chose.
4
Ten ideas everyone keeps repeating
A synthesis of the whole directory
Read enough of the people above and the same ten ideas come back in different clothes. Learn the ten and you can read anyone in the field quickly.
When Norman says feedback, Rams says understandable, Victor says immediate connection and Tufte says show the data, they are making versions of one argument: people should be able to see what is going on. This chapter names ten such arguments. The matrix shows which groups lean on each one. It is an editorial summary, not a measurement; use it to find where to read next.
Ten ideas against eight groups. Rows are ideas, columns are the directory's groups. Read a row to find who to read on an idea; read a column to see a group's priorities. Notice that "less, but better" crosses almost every group, and that honesty is shared by object designers, data designers and ethicists.
Idea
In their words, paraphrased
Go deeper
1. Make state visible
Norman: feedback and a good conceptual model. Rams: a product should be understandable. Victor: let creators see what they are making. Tufte: show the data.
Ideas only matter when they change a pixel. Here is the same simple save flow drawn twice. The first ignores most of the ten; the second applies them. Count how many you can name in the second.
Don't
Ten ideas ignored. A wall of unlabelled icons, a modal that interrupts, three equal red buttons with vague labels, and no sign of whether the work is safe.
Do
Ten ideas applied. Autosave removes the question, a quiet status makes state visible, text gets the space, and undo plus history make it honest and safe. No modal, no choice to get wrong.
Key idea
When two designers seem to disagree, check whether they are applying the same idea to different contexts. Usually they are.
Do
Use the ten as a lens in reviews: which idea does this screen break?
Write your product's own principles as local versions of the ten.
Notice when two ideas conflict (less, but better against make state visible) and decide on purpose.
Don't
Treat the ten as a style. They produce very different looks in different products.
Use one idea to win every argument. Each has a cost.
Stop at the slogan. Each idea has a mechanism; learn it in the linked guide.
In the wild
iA WriteriA, 2010 onward
Content first, less but better, respect attention: one typeface family, a focus mode, almost no settings. Three of the ten, applied without compromise, make a product's identity.
Google Docs version historyGoogle
Autosave plus a browsable history make state visible and every action recoverable. Undo and history are honesty about mistakes.
Kindle e-readersAmazon, 2007 onward
E-ink with no backlight glare in early models, no notifications while reading, progress shown quietly. Respecting attention can be the main feature.
Check yourself
Your minimal app hides sync status entirely "to keep it clean". A user loses an hour of work believing it had synced. Which two ideas are in conflict, and which should have won?
Minimalism removes what does not help. Sync status helps exactly when it matters. A small, quiet indicator respects both ideas; hiding it entirely breaks the more important one. Blaming the user (d) is what Norman warns against.
Connect the ideas
Which pairing of person and idea is correct?
Raskin's The Humane Interface argues against modes. Small multiples are Tufte's; the five planes are Garrett's; Bertin named the visual variables; pull-to-refresh came from Loren Brichter's Tweetie.
Part two
Words, laws and numbers
Shared words let you think precisely and search well. Laws give you predictions about people. Numbers settle arguments that taste cannot. This part is the lookup heart of the course: a searchable glossary of 160 terms, a quick card of the laws and principles, and a table of the numbers worth knowing by heart, with two labs to check your own values.
5
Master glossary
180 terms, A to Z, each linked to the guide that teaches it
A precise word is a compressed idea. When you can name a thing, such as "gulf of evaluation" or "information scent", you can notice it, search for it and fix it.
Each definition is one line, written to be correct rather than complete. The link after each term opens the chapter that teaches it with pictures, examples and exercises. Search matches both terms and definitions, so you can search for a symptom ("forget", "slow", "cancel") and find the concept behind it.
Words come in families. Most terms belong to one of five families; the most useful ones, such as default, feedback and contrast, sit where families meet.
Lab: search the glossary
180of 180 terms shown
Search a symptom, not only a name. "Forget" finds working memory and recognition over recall; "cancel" finds the roach motel.
Another name for an empty state, especially the first one a new user sees.
No term matches. Try fewer letters, or clear the guide filter.
Do
Use the exact term in your own notes and commit messages, so you can search them later.
Explain a term out loud in one sentence before you claim to know it.
Add terms you meet to your own glossary, with a link to where you met them.
Don't
Use jargon in the product itself. These words are for you, not your users.
Mistake knowing a name for knowing how to apply it.
Use "intuitive" as a design term. Say what makes it learnable instead.
For the solo creator
You will often be the only person who reads your design notes. Precise words still pay off: in six months, "add a stopping cue to the feed" is a clear task, while "make the feed feel better" is not.
Exercise 5.1 20 minutes a day for 5 days
Teach-back drill
Each day, filter the glossary to one guide you have read.
Cover the definitions and explain ten terms aloud in your own words, with an example from your product.
Check against the definition and the linked chapter. Mark any you got wrong.
On day five, redo only the ones you missed.
You're done when: you can explain fifty terms with a product example each, and your list of misses is empty.
Beginner
Competent
Strong
Recites definitions.
Gives a correct example from a real product for each.
Spots each term at work in your own app and names the fix it implies.
A law of UX is a prediction about people, borrowed from research, with a limited range where it holds. Use each one as a question to ask of a design, not as a rule that wins arguments.
Most of these "laws" come from experiments under narrow conditions. Fitts measured tapping between two plates; Hick measured reaction to lights. They generalise well enough to be useful, but each has a boundary. The table gives, for each law, what it says, how to use it, and where it breaks. The pictures show eight of them at a glance.
Eight laws in eight pictures. If you can redraw these from memory, you know the laws well enough to use them in a review.
Law or principle
What it says
Use it to
Where it breaks
Fitts's law (1954)
Time to reach a target grows with distance and shrinks with size.
Make frequent targets big and near; use screen edges and corners; put actions near the pointer.
Ignores the time to decide what to click.
Hick–Hyman law (1952–53)
Decision time grows with the log of the number of equally likely choices.
Reduce or group choices in unfamiliar decisions; highlight a recommended default.
Experts scanning a familiar, ordered menu are not slowed much by length.
Miller (1956) and Cowan (2001)
We can hold only a few chunks in working memory, about four.
Show, do not make people remember; chunk codes and numbers.
Not a limit on menu items you can see. Visible lists do not need memorising.
Jakob's law (Nielsen)
People expect your product to work like the others they use.
Follow platform conventions for common tasks; save novelty for your core idea.
Conventions can be bad; break them with care when you have a better reason.
Tesler's law
Every task has irreducible complexity; someone must handle it.
Move complexity from the user into the software where you can.
Hiding complexity can remove control experts need.
Postel's law (robustness)
Be liberal in what you accept, conservative in what you send.
Accept phone numbers and dates in many formats; output one clean form.
Over-liberal parsing can guess wrong silently. Show what you understood.
Doherty threshold (1982)
Responses under about 400 ms keep people productive and engaged.
Respond instantly with feedback, even if the work takes longer.
Fake speed (spinners for show) erodes trust.
0.1 / 1 / 10 seconds
0.1 s feels instant, 1 s keeps the train of thought, 10 s is the limit of attention.
Pick feedback by expected wait: none, a subtle indicator, a progress bar with an estimate.
Context changes tolerance; a search can take longer than a button press.
Peak-end rule
Experiences are judged by their peak and their end.
Make the end of a flow good: clear success, a calm finish.
Does not excuse a painful middle; it changes memory, not the experience.
Serial position effect
First and last items in a list are remembered best.
Put key navigation at the ends; important items first.
Matters for memory, less for visible menus people scan.
Von Restorff (isolation) effect
The item that differs is noticed and remembered.
Make one primary action distinct. Only one.
Two distinct items cancel each other out.
Zeigarnik effect
Unfinished tasks stay in mind.
Show progress and what is left; let people resume.
Easily abused to nag. Use for the user's goals, not yours.
Goal-gradient effect
Effort rises as people approach a goal.
Show progress; give credit for steps already done.
Artificial progress (fake head starts) is manipulative if hidden.
Aesthetic-usability effect
Attractive designs are perceived as easier to use.
Invest in polish; it buys patience.
Can mask real usability problems in tests. Watch behaviour, not opinions.
Gestalt: proximity, similarity, common region, closure, continuity, figure-ground
The eye groups by space, likeness, boundaries and continuity.
Group with space first, then with boxes only if needed.
Conflicting cues (close but different colour) confuse; pick one.
Recognition over recall
Recognising is easier than remembering.
Show recent items, suggestions, visible options.
Too much shown at once becomes clutter.
Progressive disclosure
Show what most people need; reveal the rest on request.
Keep advanced settings one level down.
Hiding something people need often is just hiding.
Occam's razor
Among equal solutions, prefer the simplest.
Remove elements that do not earn their place.
"Simple" for you can mean "missing" for the user.
Pareto principle
Roughly 80% of effects come from 20% of causes.
Polish the few screens people use most.
The ratio is a heuristic, not a measurement.
Parkinson's law
Work expands to fill the time available.
Set an appetite and ship within it.
Some quality work genuinely needs more time.
Gall's law
Complex systems that work evolved from simple systems that worked.
Ship the simple version first, then grow it.
Not an excuse to skip structure you know you will need.
MAYA (Loewy)
Most Advanced Yet Acceptable.
Introduce new ideas inside familiar forms.
Too acceptable becomes timid.
Kano model (1984)
Features are basic expectations, performance features or delighters, and delight decays into expectation.
Get basics right before adding delight.
Categories shift over time and across audiences.
Three short sets of principles worth knowing by number
Visibility of system status.
Match between system and the real world.
User control and freedom.
Consistency and standards.
Error prevention.
Recognition rather than recall.
Flexibility and efficiency of use.
Aesthetic and minimalist design.
Help users recognize, diagnose, and recover from errors.
Seek universal usability (earlier editions: enable shortcuts for frequent users).
Offer informative feedback.
Design dialogs to yield closure.
Prevent errors.
Permit easy reversal of actions.
Keep users in control.
Reduce short-term memory load.
From Designing the User Interface. See Foundations.
Is innovative.
Makes a product useful.
Is aesthetic.
Makes a product understandable.
Is unobtrusive.
Is honest.
Is long-lasting.
Is thorough down to the last detail.
Is environmentally friendly.
Is as little design as possible.
Each begins "Good design…". Translated to software in Foundations.
Don't
Von Restorff, cancelled. Three highlighted buttons means none stands out, and Delete is as easy to hit as Send.
Do
One distinct thing. One big primary action near the thumb (Fitts), one quiet secondary, and destructive actions tucked into the overflow menu.
Myth
"Miller proved menus should have seven items or fewer." Miller's paper was about absolute judgement and immediate memory span, not menus. A visible menu does not need to be memorised. Group long menus for scanning instead of cutting them to an arbitrary number.
Do
Phrase each law as a question in reviews: "What is the Fitts cost of this button?"
Learn the boundary of each law along with the law.
Prefer watching five people use the screen over citing a law at it.
Don't
Use a law to override evidence from your own users.
Quote numbers ("seven items") the original research never claimed.
Apply persuasion findings (goal gradient, Zeigarnik) to push people toward your goals instead of theirs.
In the wild
macOS menu barApple, since 1984
Menus pinned to the top edge of the screen: you cannot overshoot, so the target is effectively very tall. Fitts's law via the screen edge.
Stripe CheckoutStripe
Card number fields that accept spaces or none, and format as you type. Postel's law: accept loosely, show clearly.
Duolingo lesson endDuolingo
Each lesson ends on a celebratory summary screen. Peak-end at work; also a reminder to check whose goal the celebration serves.
Check yourself
Your settings screen has 40 options in one list. A friend cites Hick's law and says to cut it to seven. What is the better response?
Hick's law is about deciding between equally likely, unfamiliar choices. In settings, people usually look for one known item, so scanning and grouping matter more than count. Progressive disclosure keeps the common case quick. The number seven is a misreading of Miller.
Exercise 6.1 40 minutes · on your own product
A laws walkthrough
Pick one core flow, such as creating and saving an item.
For each screen, ask four questions: What is the Fitts cost of the main action? How many equal choices does Hick charge here? What must the user remember (Miller, Cowan)? Who carries the complexity (Tesler)?
Note how the flow ends (peak-end) and whether anything stands out by accident (Von Restorff).
Change the two worst answers and redraw those screens.
You're done when: you have an annotated sketch of the flow with one law per note and two redrawn screens.
Beginner
Competent
Strong
Names laws that seem relevant.
Applies each law with its boundary in mind and changes two screens.
Confirms the changes by watching two people use the old and new versions.
7
Numbers to remember
From WCAG 2.2, Apple and Google guidelines, Bringhurst, Nielsen and others
A handful of numbers settle most interface arguments before they start. Learn them, put them in your design tokens, and you will not have to decide them again.
These come in two kinds. Some are hard minimums from standards (contrast, target size, flashing). Ignore them and real people cannot use your product, and in some places you may break the law. Others are well-tested starting points (line length, motion durations, a spacing grid). Start there and move only for a reason you can name.
Draw small, hit big. A 20 px icon can sit inside a 44 pt hit area. Pad the button, not the icon. Units differ (pt, dp, CSS px) but all map to roughly the same physical size on their platforms.Match the feedback to the wait. A spinner on a 50 ms action is noise; a spinner on a 30 s export is a broken promise. Add progress, an estimate and a way to cancel as waits grow.45 to 75 characters. Set a max-width in ch units (for example 66ch) on reading text. Leading should grow a little as lines get longer.
Lab: check your product's numbers
Set the sliders to your product's real values (measure them, do not guess). Green is a sound default, amber needs a reason, red fails a standard or a well-tested guideline.
Lab: contrast checker
Heading at 24 px
Body text at 16 px. Can you read this comfortably at arm's length?
Caption at 12 px, the size people most often make too faint.
0:1
#767676
#ffffff
Uses the WCAG 2 relative luminance formula. Grey #767676 on white is about the lightest grey that passes 4.5:1. Try white on amber to see why yellow buttons usually need dark text. This demo uses literal colours because colour is its subject.
For the solo creator
Put these numbers in code once: a spacing scale, a type scale, a max-width for text, a minimum hit area in your button component, motion durations as tokens, and a contrast check in your palette file. Then you stop deciding them screen by screen. See Systems: scales.
Do
Treat the standards numbers as floors, not targets.
Measure real values in the browser or simulator, not in your design file.
Write the numbers into tokens and component defaults.
Don't
Shrink hit areas to make a layout fit. Make the layout fit the hit areas.
Check contrast only in light mode.
Use long, decorative motion on frequent actions.
Common mistakes with numbers
Passing contrast on one theme only
You tune colours in light mode and invert for dark, assuming the ratio holds.
Check every text and UI token pair in both themes; muted text is the usual failure.
Confusing drawn size with hit size
A 16 px icon looks right, so the tappable area ends up 16 px too.
Give the button padding or a minimum size of 44 pt; keep the icon small inside it.
Check yourself
Your reading app sets body text at 15 px, line height 1.2, in a column 900 px wide on desktop. Which change helps most first?
At 15 px, 900 px is well over 100 characters per line, so the return sweep is hard. Fix the measure first, then size and leading. Extra leading alone cannot rescue a very long line, and maximum contrast is not the issue.
Exercise 7.1 45 minutes · on your own product
A numbers audit
Pick your three most used screens.
Measure in the running app: body size, line length, line height, smallest hit area, slowest common response, typical transition.
Run each colour pair for text and controls through the contrast lab, in light and dark.
Enter the values in the numbers lab. Write down every red and amber.
Fix the reds today. For each amber, write the reason it stays or fix it.
You're done when: you have a one-page table of measured values, every red is fixed, and the fixes live in tokens or components, not one-off styles.
Beginner
Competent
Strong
Measures some values; fixes visible problems.
Measures all values in both themes; fixes all reds.
Encodes the numbers in tokens and adds an automated contrast check.
Part three
Master checklists
Twelve checklists, from the problem brief to ship day. Each distils one or more guides into statements you can check against a real product. Ticks are saved in this browser, so you can run a long checklist across several sessions. The first chapter explains how to use checklists well; the rest group the twelve by when you need them.
8
How to use a checklist, and the problem brief
Taught by Atul Gawande, with the aviation tradition he drew on
A checklist does not make you a good designer. It stops a good designer from forgetting the things they already know, especially when tired, rushed or proud.
Gawande's The Checklist Manifesto (2009) describes how short checklists cut complications in surgery. The mechanism is simple: experts skip steps they consider obvious, and under pressure, obvious steps are exactly the ones that get skipped. A checklist moves those steps out of memory and into the world.
He distinguishes two kinds. A read-do checklist is followed step by step, like a recipe. A do-confirm checklist is used after you have worked from memory: you pause and confirm nothing was missed. Most of the checklists here are do-confirm. Design the screen your way, then run the list. The exception is the problem brief, which is read-do: answer each item before you start.
Twelve lists across one loop. The brief comes first and once. The screen review runs on every screen. The craft passes run when a feature is nearly done. Ship and ethics run on every release. On narrow screens, scroll sideways.
Five rules for checklists that work
Short beats complete. Gawande suggests five to nine items per pause point. Long lists here are split into groups; run one group at a time.
Check the product, not your memory of it. Open the real screen on a real device. Most false ticks come from checking from memory.
Write each item as a statement that can be false. "Errors are friendly" cannot fail. "Error messages say what went wrong and how to fix it" can.
An unticked item is a decision, not a failure. If you choose to skip an item, write why. That note is design rationale.
Edit the list. When you make the same mistake twice, add it. When an item never catches anything, cut it.
Don't
Launch checklist ☐ Make it good ☐ Check design ☐ Accessibility ☐ Test everything ☐ Polish
Unfalsifiable. Every item can be ticked by anyone, any time. It checks nothing.
Do
Launch checklist ☐ Core flow done by 3 people without help ☐ Text contrast ≥ 4.5:1, both themes ☐ Keyboard-only run of sign-up ☐ Cancel is as easy as subscribe ☐ Restore from backup tested
Checkable. Each item is specific, observable, and could fail today.
Checklist 1. Before you design: the problem brief
The problem
The bet
The constraints
For the solo creator
You will be tempted to skip the brief because you already "know" the problem. Write it anyway; it takes thirty minutes. Its real value comes later, when you are deep in building and need to decide whether a feature belongs. The brief answers that question in the voice of your earlier, clearer self. See Problems Worth Solving.
Do
Run do-confirm checklists after you design, not instead of designing.
Keep a copy of each checklist in your project repo and edit it.
Run them on a real device.
Don't
Tick items from memory.
Run all twelve at once; you will skim.
Treat a full set of ticks as proof of quality. Users decide that.
In the wild
Aviation checklistsSince the 1930s
Pilots use short read-do and do-confirm lists at fixed pause points, however experienced they are. Expertise and checklists are allies, not opposites.
The WHO Surgical Safety ChecklistWorld Health Organization, 2008
A one-page list run at three pause points in an operation, the subject of Gawande's book. Pause points matter as much as the items.
Pull request templatesGitHub and others
Many teams add a checklist to every pull request: tests, screenshots, accessibility. Put the checklist where the work already happens.
Check yourself
You keep shipping screens where long names overflow their cards. What is the best change to your process?
Repeated mistakes are the best source of checklist items, and the item must be specific enough to fail. Seeding test data moves the check into the world so you do not have to remember it.
9
The screen review
Distilled from Foundations, Interaction, Visual, Words and Accessibility
Thirty items you can run on any screen in fifteen minutes. If you run only one checklist, run this one.
The review moves from big to small: purpose, orientation, layout, interaction, states, then words and look. That order matters. There is no point polishing type on a screen that has two competing purposes. If you fail an item in "Purpose", stop and fix it before going further, because the fix may change everything below.
Below is the same settings screen before and after a review. Toggle between them, then look for which checklist items each change answers.
One screen, before and after the review
Prefsv2.3.1-b
sync_mode
Enter sync mode…
notif_freq
Enter frequency…
Invalid values will be rejected by server (ERR_422).
Before: internal names as labels, placeholders doing a label's job, faint text below 4.5:1, a vague "Submit", an error code nobody understands, and Delete account sitting beside Reset at equal weight.
After: user words, visible labels with help text, controls that cannot hold invalid values, autosave with a visible status, and the destructive action moved away and named. Eight checklist items fixed in one pass.
Checklist 2. Every screen review
Purpose
Orientation
Layout
Interaction
States
Words and look
For the solo creator
Do the review with fresh eyes: the next morning, on a different device, ideally after a walk. You cannot unknow your own design, but distance helps. Reading the screen aloud as if explaining it to a stranger catches surprising amounts. See Self-critique and fresh eyes.
Do
Run it in order, big to small.
Screenshot before and after; keep both in your design log.
Fix "Purpose" failures before anything else.
Don't
Review in your design tool only; check the built screen.
Skip states because the happy path looks great.
Treat thirty ticks as a substitute for watching a user.
Exercise 9.1 45 minutes · on your own product
Review your three most used screens
Pick the three screens people spend most time on.
Run the 30-item review on each, on a real device.
List every unticked item with a one-line fix or a one-line reason to leave it.
Fix the three cheapest, most visible issues today.
You're done when: you have before and after screenshots of three screens and a list of remaining issues ranked by severity.
Beginner
Competent
Strong
Ticks items and notes failures.
Fixes the visible failures and ranks the rest.
Turns repeated failures into component or token fixes so they cannot recur.
10
Forms and screen states
From Interaction, Words and Accessibility
Forms are where people give you something; states are where your product admits it is not ready. Both are where trust is won or lost, and both are usually designed last.
A form is a conversation in which you ask for effort. Each field is a question, and each question costs attention. The forms checklist is about asking less, asking clearly, and forgiving mistakes. The states checklist covers the screens nobody draws in the first mock-up: empty, loading, partial and error. Real users see them constantly: on first use, on bad networks, after deleting the last item.
Five states, one screen. Draw all five for every screen that shows data. Empty and error each end in an action; loading keeps the layout's shape so nothing jumps. See Interaction: screen states.
Don't
Email
Phone
Invalid input
Submit
Placeholders as labels, vague error. Labels vanish while typing; "Invalid input" does not say what is wrong; "Submit" does not say what happens.
Do
Email
rohit@example.com
Phone (optional)
98765 4321
⚠ Phone numbers in India have 10 digits. This one has 9.
Create account
Labels that stay, errors that help. Visible labels, "optional" marked, an error with an icon and a specific fix, and a button that names the result.
Checklist 3. Forms
Ask less
Labels and help
Errors
Flow
Checklist 4. Empty, loading and error states
Empty
Loading
Partial and error
For the solo creator
Build states into your components, not your screens. A list component that takes loading, empty and error props, each with a sensible default, means every new list gets all five states for free. Write the empty and error copy once, well.
Do
Seed test data with empty, huge and broken cases.
Throttle your network in dev tools for a day.
Write error messages while building the feature, not after.
Don't
Ship a blank white screen as the empty state.
Show raw error codes or stack traces to users.
Clear a form after a failed submit.
11
Craft passes: visual, typography, motion
From Visual Design, Typography and Motion & Feel
Polish is many small consistencies. The craft passes catch the one-offs: the stray 13 px gap, the third grey, the 600 ms fade on a button.
Run these when a feature works and its words are settled. Polishing earlier wastes effort on screens that will change. Each pass takes about twenty minutes per screen. Work at 100% zoom and at 200%, in both themes, and on the slowest device you support.
Before
Before. Ragged left edges, three greys, a pill next to a square.
After
After. One left edge at 16, one text grey, one radius (6 inside 10).
Type, too
Chapter 3
“Sync is on.” Last run 12:04, 1,204 items.
Recent
Details. Curly quotes, tight heading leading, roomy body leading, tracked small caps label.
Checklist 5. Visual polish
Structure
Colour and depth
Details
Checklist 6. Typography
Choice
Setting
Details
Checklist 9. Motion
Purpose
Timing
Safety and craft
For the solo creator
Most craft failures are one-off values. Search your code for raw pixel values, hex colours and millisecond numbers outside your token files. Each hit is either a missing token or a mistake. This one search often fixes more polish than an afternoon of eyeballing. See Systems: tokens.
Do
Polish after the words and flow are stable.
Fix at the token or component level.
Check motion with reduced-motion turned on.
Don't
Add a new grey, size or radius to fix one screen.
Animate to impress; animate to explain.
Judge type at a zoom level nobody uses.
12
Accessibility and copy passes
From Accessible & Inclusive and Words
Two passes that are cheap to run and expensive to skip: one checks that everyone can use the product, the other that everyone can understand it.
The accessibility pass is a quick pass, not an audit. It catches most common barriers in under an hour for a small product: contrast, keyboard, labels, motion and zoom. The deep work, including screen reader testing across flows, is in Testing accessibility on your own. The copy pass reads every word as a user would. The most effective single technique is reading aloud: your ear catches what your eye skips.
Don't
Oops! Something went wrong 😬
Error 0x80070057. Please try again later or contact your administrator.
OK
Cute, vague, useless. No cause, no fix, a code, a dead-end "OK", and a tone that jars when someone just lost work.
Do
Couldn't save “Chapter two”
You're offline. Your changes are kept on this device and will save when you reconnect.
Try again now
What, why, what next. Names the thing, explains the cause, reassures about data, offers a specific action.
Checklist 7. Accessibility quick pass
Perceive
Operate
Understand and robust
Checklist 8. Copy pass
Clarity
Actions
Tone
Edit
For the solo creator
Turn on VoiceOver or TalkBack once a week for ten minutes and use your own app. You will feel the problems faster than any checklist can describe them. For copy, keep a single file of all user-facing strings; reading them together reveals inconsistent terms immediately.
Do
Use native controls first; they come with accessibility built in.
Read every screen aloud.
Test with system text size at its largest.
Don't
Rely on automated checkers alone; they catch only part of the problems.
Add ARIA to fix what a native element would handle.
Write jokes into error messages.
13
The ship checklist
From every guide, with the launch chapters of Identity & Launch
Sixty-one items across eleven areas. Run it before every significant release, over several sessions if you need to, and do not ship with an unticked item you have not consciously accepted.
This is the longest list in the course because shipping touches everything. It is grouped so you can run one area per sitting. Some areas will be quick (you already ran the screen and accessibility passes); others, like reliability and trust, are easy to forget because they are invisible until they fail. A backup you have never restored is a hope, not a backup.
Where the checks are. Invisible areas (reliability, trust, after launch) hold almost as many checks as visible ones. Solo makers skip them most.
Checklist 10. The ship checklist
Problem and scope
Core flows
Screens and states
Visual and type
Accessibility
Performance
Reliability and data
Trust and legal
Words and help
Launch surfaces
After launch
Watch out
Legal requirements for privacy, consumer rights and accessibility differ by country and change over time. The trust items here are prompts, not legal advice. If you sell in the EU, read about the GDPR and the European Accessibility Act; in India, the Digital Personal Data Protection Act, 2023. See Accessibility: the law.
For the solo creator
You cannot do all sixty-one items perfectly for a first release. Rank them. The non-negotiables are: no data loss, the core flow works for strangers, accessibility basics, honest pricing and cancellation, and a way for users to reach you. Everything else can be "accepted, with a note".
Do
Start the ship checklist a week before launch, not the night before.
Write a note for every item you consciously skip.
Rerun it on each major release.
Don't
Launch on a Friday night with no time to fix.
Assume backups work.
Add analytics for everything "just in case".
In the wild
Show HN and Product Hunt launchesCommon pattern
Launches often hit problems no one tested: a sign-up that breaks at scale, a pricing page that confuses. The ship checklist exists because launch day is the worst time to find these.
Staged rolloutsApp Store phased release, Google Play
Both stores let you release an update gradually to a share of users. A rollback plan and gradual release turn a bad bug into a small one.
Exercise 13.1 3 evenings · on your next release
A dry-run launch
Pick your next release, however small.
Run four areas of the ship checklist each evening.
For each unticked item: fix it, or write a one-line acceptance note.
Restore a backup to a scratch environment and confirm the data.
After release, note which items caught something real. Edit the list.
You're done when: all 61 items are ticked or carry a note, the backup restore is proven, and your own edited copy of the checklist lives in your repo.
Beginner
Competent
Strong
Runs most of the list once.
Runs all of it, with notes for every skip and a tested restore.
Automates the repeatable checks (contrast, links, performance budgets) and trims the list based on evidence.
14
Ethics and trust, and reading apps
From Honest & Calm, Reading & Writing and Breakdowns: Reading
The last two lists are about respect: for people's choices and attention, and, in a reading product, for the text and the person reading it.
The ethics list is phrased so you can catch yourself. Nobody sets out to build a roach motel; it happens one growth experiment at a time. A useful test from the Honest & Calm guide: would you be comfortable if your users could see exactly how and why a feature was designed? The reading list is specific to the learner's favourite category, products for reading text, and doubles as a scorecard when you study Kindle, Kobo, Reeder or Instapaper.
Don't
Obstruction, urgency, shame. A fake timer, guilt, a giant "keep" and a near-invisible, shaming cancel link.
Do
Plain and fair. Clear consequences, data reassurance, the user's chosen action easy to take, an export link.
Checklist 11. Ethics and trust
Honesty
Control
Attention
Harm
Checklist 12. Reading-app specific
The page
Attention
Tools
Access and devices
For the solo creator
As a solo maker you have an advantage big companies lack: no growth team pushing for engagement at any cost. Make honesty part of your positioning. "Cancel in one click", "export everything", "no tracking" are features people choose products for. See Honest & Calm.
Do
Make cancel and delete as easy as subscribe and create.
Use the reading checklist as a scorecard when studying other apps.
Ask "whose goal does this serve?" of every engagement feature.
Don't
Run "small" dark-pattern experiments; they add up.
Put upsells inside the reading view.
Lock highlights and notes inside your app.
Connect the ideas
Your reading app's retention dips. A friend suggests a daily streak with a push notification at 9 pm that says "Don't lose your 12-day streak!". Which checklist items does this risk failing?
Loss-framed streak reminders use loss aversion to pull people back for your metric. That runs into several ethics items and into the reading app's calm. A better approach: an optional, user-scheduled reading reminder with neutral wording, and a look at why people actually stopped.
Part four
The mistakes compendium
Every guide in the course has its own common mistakes. This part collects the sixty that solo creators make most often, in ten areas of six. Each has a name, the reason it happens, the fix, and a link. Reading the reasons is the point: a mistake you understand is one you stop making.
15
Sixty common mistakes, and their fixes
Collected from all twenty guides
Most product design mistakes are not failures of taste. They are defaults: the tool's default, the fastest code path, the way you have always done it. Fixing them means replacing a default with a decision.
Notice how many of the "why it happens" lines describe a solo creator's natural situation: you know the product too well, you test on your own fast machine, you write the error message last, you designed with perfect sample data. None of that is a character flaw. It is a position, and the fix is to change your position: fresh eyes, slow devices, real data, other people.
Change your position, not just the pixel. Each of the sixty mistakes traces back to one of these four. Fixing the source prevents a whole family of mistakes.
Don't
Designed with perfect data. Short names, photos for everyone, tidy amounts. Real data will break it on day one.
Do
Designed with real data. A long name truncates with room for the amount, initials stand in for photos, lakh formatting for Indian rupees, a placeholder for a missing name.
Lab: find a mistake
60of 60 mistakes shown
Search the symptom you see in your product ("nobody finds", "slow", "cancel") or pick an area to review before a pass.
Problems and scope
Building the solution before finding the problem
You love the idea and building feels like progress.
Write the problem brief and talk to five people about their past behaviour before writing code.
No mistake matches. Try another word, or "All areas".
My top five: mistakes I know I make
For the solo creator
Keep a "mistakes I made" file in your project. Each entry: what happened, which of the four sources it came from, and the checklist item you added. After a year it will be the most valuable design document you own.
Do
Read the "why" before the fix.
Fix the source when you can: a component, a token, a test fixture.
Use the search as a diagnostic when something feels off.
Don't
Try to fix all sixty at once.
Feel bad about recognising many of them. Everyone does.
Fix the instance and leave the default that produced it.
Check yourself
Three different screens in your app shipped with unreadable error states. What is the strongest fix?
The repetition shows a missing default. A component that requires the three parts makes the right thing the easy thing for every future screen. Fixing by hand (b) leaves the source in place.
Part five
Where to learn next
The course ends; the practice does not. This part gives you 59 readings, talks and references, marked by level and by cost (19 are free), a suggested order, and the places and tools worth keeping close.
16
The reading list
59 books, essays, talks and references, by level
Read fewer books, more slowly, and apply each one to your product before starting the next. One book a month, applied, beats ten skimmed.
Each entry is marked Start, Intermediate or Deep, and Free when it can be read or watched at no cost. "Start" means short, practical, and useful the same week. "Intermediate" assumes you have shipped something and want depth in one area. "Deep" means classic, demanding and slow; read these when a specific problem sends you to them.
Fifteen months, fifteen books. The first row builds fundamentals in a few months. The second adds the practice and the details. The third is the deep tradition: type, data and emptiness. Do the related guide's exercises alongside each book.
Lab: filter the reading list
0items shown
Tick "Free only" with "Start" for a reading plan that costs nothing: Practical Typography, Laws of UX, Shape Up, Getting Real, the heuristics, the HIG and WCAG.
The Design of Everyday Things
Don Norman · 1988, revised 2013 · book
Start
The vocabulary of the whole field: affordances, signifiers, mapping, feedback, conceptual models, and why errors are design problems.
Don't Make Me Think, Revisited
Steve Krug · 2014 · book
Start
How people really use screens: scanning, satisficing, muddling through. Read in an afternoon, use for years.
Refactoring UI
Adam Wathan and Steve Schoger · 2018 · book
Start
Practical visual design for developers: hierarchy by de-emphasis, spacing scales, colour, depth. The fastest way to make your screens look designed.
Butterick's Practical Typography
Matthew Butterick · online, 2013 onward · book
StartFree
Typography rules for anyone who writes, with clear reasons. Start with "Typography in ten minutes".
The Mom Test
Rob Fitzpatrick · 2013 · book
Start
How to talk to customers so they cannot lie to you. Two hours that will change every user conversation.
Laws of UX
Jon Yablonski · website, and book 2020 · book
StartFree
Short, illustrated summaries of the psychology most useful to interface designers. The website is free.
Shape Up
Ryan Singer · 2019 · book
StartFree
Appetites, shaping, breadboards and fat-marker sketches, betting. Adapt it to one person by fixing your own cycles.
Getting Real
37signals · 2006 · book
StartFree
A short manifesto for building less, faster, with a small team. Dated in places, still sharp.
Inventing on Principle
Bret Victor · talk, 2012 · talk
StartFree
Creators need an immediate connection to what they create. Watch the demos, then ask where your product hides its state.
The Vignelli Canon
Massimo Vignelli · 2010 · book
StartFree
A short, opinionated PDF on grids, type and discipline from a modernist master.
10 Usability Heuristics for User Interface Design
Jakob Nielsen · NN/g article · essay
StartFree
The ten heuristics with explanations and examples. Use them for every review.
Badass: Making Users Awesome
Kathy Sierra · 2015 · book
Start
Design for the user's growing skill, not your feature list. Highly visual and quick.
Rocket Surgery Made Easy
Steve Krug · 2010 · book
Start
A do-it-yourself guide to monthly usability testing. Perfect for a solo maker.
Human Interface Guidelines
Apple · online · reference
StartFree
The platform's conventions and components for iOS, macOS and the rest. Read the foundations sections once, then look things up.
Material Design 3
Google · online · reference
StartFree
Android's design system: layout, type, colour, motion, components. Useful even if you build for the web.
WCAG 2.2 and the WAI tutorials
W3C · online · reference
StartFree
The accessibility standard, with the more readable "How to Meet WCAG" quick reference and tutorials.
Thinking with Type
Ellen Lupton · 2004, later editions · book
Start
Letter, text, grid: a clear visual introduction to typography.
Universal Principles of Design
Lidwell, Holden and Butler · 2003 · reference
Start
A hundred-plus principles, one per spread. A good bedside reference to browse.
Competing Against Luck
Clayton Christensen and colleagues · 2016 · book
Intermediate
Jobs to be done from the source: people hire products to make progress in a circumstance.
Obviously Awesome
April Dunford · 2019 · book
Intermediate
A practical method for positioning, so the right people instantly see why your product is for them.
Continuous Discovery Habits
Teresa Torres · 2021 · book
Intermediate
Weekly customer contact and opportunity solution trees. Scale it down to a monthly habit if you work alone.
Microinteractions
Dan Saffer · 2013 · book
Intermediate
Triggers, rules, feedback, loops and modes. Where products earn their feel.
About Face
Alan Cooper and others · 4th edition 2014 · book
Intermediate
The long manual of goal-directed interaction design. Read part one, then dip in.
The Elements of User Experience
Jesse James Garrett · 2002 · book
Intermediate
The five planes, from strategy to surface. Short; the diagram alone repays it.
Information Architecture
Rosenfeld, Morville and Arango · 4th edition 2015 · book
Intermediate
Organisation, labelling, navigation and search. Read when your product outgrows one screen.
Strategic Writing for UX
Torrey Podmajersky · 2019 · book
Intermediate
A practical method for interface text: voice charts, patterns for buttons, errors and notifications.
Inclusive Design Patterns
Heydon Pickering · 2016 · book
Intermediate
How to build common components so they work for everyone, from semantic HTML up.
Mismatch
Kat Holmes · 2018 · book
Intermediate
Disability as mismatch, and how designing for exclusion widens your product's reach.
Calm Technology
Amber Case · 2015 · book
Intermediate
Eight principles for technology that respects attention.
Designing Calm Technology
Mark Weiser and John Seely Brown · essay, 1995 · essay
IntermediateFree
The short original argument for center and periphery. Read before Case's book.
Articulating Design Decisions
Tom Greever · 2015, 2nd edition 2020 · book
Intermediate
Explaining design choices to others. For a soloist: explaining them to clients, users and your future self.
Sprint
Jake Knapp with Zeratsky and Kowitz · 2016 · book
Intermediate
A five-day team process from problem to tested prototype. Written for teams: borrow the map, sketch and test days, skip the rest.
Atomic Design
Brad Frost · 2016 · book
IntermediateFree
Building design systems from small parts. Free to read online.
Magic Ink
Bret Victor · essay, 2006 · essay
IntermediateFree
Most software is information software, and interaction is a cost. Changes how you see dashboards and settings.
Grid Systems in Graphic Design
Josef Müller-Brockmann · 1981 · book
Intermediate
The classic manual of the grid. Look at the examples more than you read the text.
Deceptive Patterns
Harry Brignull · 2023 · book
Intermediate
The taxonomy of tricks, the harm they do and the law catching up. Pair with the ethics checklist.
Ruined by Design
Mike Monteiro · 2019 · book
Intermediate
A polemic on designers' responsibility. Read it to test your own lines.
Hooked
Nir Eyal · 2014 · book
Intermediate
Read critically. The habit model is clear; ask of every step whose interest it serves, then read Honest and Calm.
Thinking, Fast and Slow
Daniel Kahneman · 2011 · book
Intermediate
The biases behind defaults, anchors, framing and peak-end. Read parts one and five.
Local-first software
Kleppmann, Wiggins, van Hardenberg and McGranaghan · essay, 2019 · essay
IntermediateFree
Seven ideals for software where users own their data. Essential if you make notes, writing or reading tools.
Fast Software, the Best Software
Craig Mod · essay, 2019 · essay
IntermediateFree
Speed as a form of respect and a source of joy.
The Shape of Design
Frank Chimero · 2012 · book
IntermediateFree
Why we design and how to think about craft. Free to read online.
Information Dashboard Design
Stephen Few · 2006, 2nd edition 2013 · book
Intermediate
Dashboards that inform at a glance. Useful for any stats or progress screen.
How Charts Lie
Alberto Cairo · 2019 · book
Intermediate
Reading and making charts honestly.
Design for How People Learn
Julie Dirksen · 2012 · book
Intermediate
How learning works, for anyone designing onboarding, tutorials or education products.
Learn Accessibility
web.dev (Google) · online course · course
IntermediateFree
A free, practical course on building accessible web interfaces.
The Elements of Typographic Style
Robert Bringhurst · 1992, later editions · book
Deep
The bible of typographic craft. Read chapters 1 and 2 first; keep the rest for reference.
The Visual Display of Quantitative Information
Edward Tufte · 1983 · book
Deep
Data-ink, chartjunk, small multiples, graphical integrity. Beautiful and demanding.
Envisioning Information
Edward Tufte · 1990 · book
Deep
Layering, separation, micro and macro readings. Lessons for any dense interface.
The Humane Interface
Jef Raskin · 2000 · book
Deep
Modes, habits, attention and quantified interface efficiency. Opinionated and still ahead of most software.
Designing Design
Kenya Hara · English edition 2007 · book
Deep
Emptiness, MUJI and the reawakening of the familiar. Slow reading, deep effect.
Super Normal: Sensations of the Ordinary
Naoto Fukasawa and Jasper Morrison · 2007 · book
Deep
Photographs of perfected ordinary objects with short texts. Trains the eye for quiet quality.
Less and More: The Design Ethos of Dieter Rams
Klaus Klemp and Keiko Ueki-Polet, eds. · 2009 · book
Deep
The catalogue of Rams' work. Study the products one by one with his ten principles beside you.
Human-Centered AI
Ben Shneiderman · 2022 · book
Deep
High automation and high human control together. A frame for AI features.
The Sciences of the Artificial
Herbert A. Simon · 1969 · book
Deep
Design as a science of the artificial; satisficing; bounded rationality. Chapter five on design.
Designing the User Interface
Ben Shneiderman and others · 6th edition 2016 · book
Deep
The HCI textbook: direct manipulation, golden rules, evaluation.
The Psychology of Human-Computer Interaction
Card, Moran and Newell · 1983 · book
Deep
The founding science of HCI. Read the keystroke-level model chapter.
As We May Think
Vannevar Bush · essay, 1945 · essay
DeepFree
The memex. Read it to see how old the dream of linked personal knowledge is.
The Mother of All Demos
Douglas Engelbart · video, 1968 · talk
DeepFree
Watch twenty minutes and list everything you still use.
Nothing matches these filters.
For the solo creator
Read with your product open. After each chapter, write one sentence: "This means I should change ___ in my product." If you cannot fill the blank, the chapter was not for you yet. Skip it without guilt and come back later.
Do
Read one book at a time, with the related guide's exercises.
Prefer the free originals (essays, talks) for the deep ideas.
Reread the Start books once a year; they read differently after shipping.
Don't
Buy ten books at once.
Read the deep books first to feel serious.
Read a summary instead of the book for anything in the Start tier.
Exercise 16.1 30 minutes, then one hour a week
Your next three months of reading
Use the filter to choose three items: one Start, one Intermediate, one free essay or talk.
Match each to a guide in this course and to a part of your product.
Put one reading hour a week in your calendar.
After each, write the one-sentence change and make it.
You're done when: after three months you have three one-page notes and three shipped changes traced to what you read.
Beginner
Competent
Strong
Reads the three items.
Writes notes and makes at least one change per item.
Connects ideas across the three and writes a short principle for your product from them.
Check yourself
You have shipped a small notes app and users say it "feels cluttered". Which reading order makes most sense right now?
Start with the practical book that addresses the symptom (hierarchy and spacing), then type (most of a notes app is text), then the deep tradition when you want to understand restraint, not just apply it.
17
Inspiration, tools and communities
Where to look, what to use, who to talk to
Look at real products more than at design galleries, and keep what you collect with a note on why it works. Inspiration without annotation is just scrolling.
Galleries show you surfaces, often polished concepts that never shipped. Products show you decisions under real constraints: real data, real edge cases, real users. Use galleries to widen your visual range; use products to learn design. For both, the habit that matters is the swipe file: save it, then write one line on the decision it shows and where it would apply in your work. See Practice: the swipe file.
Collecting is the easy quarter. A screenshot without a note teaches nothing a month later. Write the reason while you still see it.
Don't
inspo/ IMG_2041.png IMG_2042.png screenshot 2026-03-14.png cool dashboard.png … 812 more
A pile. Hundreds of unnamed screenshots you will never search or reread.
Do
Reeder · unread count Count sits quiet in grey, no badge. Respects attention: I see it when I look, it never calls me. Use in:my app's library list, replace red badge.
A lesson. One item, named by product and pattern, with the reason and where to use it.
Places to look
Where
What it is good for
Watch out
The products themselves
Real decisions under real constraints. Use the apps you admire for a week with a notebook.
You only see the surface; infer the reasons carefully.
Mobbin
A large library of screenshots and flows from real mobile and web apps, searchable by pattern.
Paid for full access; screens lack the context of why.
Apple Design Awards
Apple's yearly selection of apps, with categories such as interaction and inclusivity. A good shortlist to study.
Biased toward Apple platforms and Apple's taste.
Platform guidelines (Apple HIG, Material)
The conventions users already know, with rationale.
Platforms push their own style; separate conventions from fashion.
Dribbble, Behance
Visual range, illustration, colour ideas.
Many shots are concepts that never met real data or users.
Typewolf, Fonts In Use
Type in real use; pairings; what fonts look like at scale.
Mostly editorial and brand, less interface.
Are.na
Slow, thoughtful collections of references across art, design and ideas.
Easy to collect forever; remember to annotate.
NN/g articles, Laws of UX
Evidence-based explanations of patterns and problems.
Some advice is general; test it in your context.
deceptive.design
Examples of deceptive patterns to recognise and avoid.
A catalogue of what not to do; study it once a year.
MDN, web.dev, Inclusive Components
How to build accessible, robust web interfaces properly.
Check dates; the web moves.
Museums, shops, objects
MUJI stores, design museum collections, a well-made kettle. Lessons in restraint and material.
Translate the lesson, not the look. See atoms to bits.
Tools worth knowing
Paper and a fat marker
The fastest design tool for flows and layouts. Use it first.
Figma, Sketch, Penpot
Interface design tools. Figma is the common standard; Sketch is Mac-native; Penpot is open source.
Excalidraw, tldraw
Quick, hand-drawn style diagrams and breadboards in the browser.
Your own code
For a design engineer, the browser or simulator is often the best high-fidelity tool. See Practice: designing in code.
Lighthouse and axe DevTools
Automated accessibility and performance audits in the browser. They catch part of the problems, not all.
VoiceOver, TalkBack, NVDA
Screen readers on Apple platforms, Android and Windows. Learn five gestures or keys and test your core flow.
Xcode Accessibility Inspector
Inspect labels, traits and contrast in iOS and macOS apps.
Browser dev tools throttling
Simulate slow networks and CPUs; emulate reduced motion and dark mode.
WebAIM Contrast Checker
A simple contrast ratio calculator with WCAG pass and fail, like the lab in this guide.
Utopia
Generates fluid type and space scales for CSS.
Google Fonts, Inter
Free, well-made typefaces; Inter is designed for screens.
Colour-blindness simulators
Built into Chrome dev tools (rendering emulation) and many design tools. Check every chart and status colour.
Communities
Working alone, you need a few people who will tell you the truth. Look for small, specific groups over large general ones: a forum for your platform, a group of indie developers, a local design meetup, two or three peers you swap critiques with monthly. Large feeds are good for news and bad for feedback. When you post work, ask a specific question ("Is the primary action clear on this screen?") rather than "Thoughts?". See Practice: getting feedback as a soloist.
For the solo creator
Set a limit: twenty minutes of inspiration browsing, then twenty minutes applying one thing you found. Without the second half, browsing becomes procrastination that feels like work.
Do
Study shipped products more than galleries.
Annotate every saved item with the reason and a place to use it.
Find two peers for monthly critique swaps.
Don't
Copy a surface without understanding its constraints.
Collect without reviewing; prune your swipe file monthly.
Ask strangers "thoughts?" and expect useful feedback.
In the wild
Apple Design AwardsApple, yearly
A curated, annual shortlist of apps worth studying, many from small teams. A ready-made syllabus of real products.
Indie makers' blogsPanic, iA, Craig Mod and others
Several small studios write about their design decisions in detail. Reasons from the makers themselves beat any gallery.
Wrap-up
This library ends the course, but it is meant to be the guide you open most after finishing it. The other guides teach the reasons; this one keeps them within reach while you work.
Ten things to remember
The field is a few long threads. Study one hub per thread: Rams, Hara, Bringhurst, Engelbart, Tufte, Norman, Weiser.
Ten ideas recur everywhere: visible state, fit the person, less but better, respect attention, direct action, structure first, content first, problem first, test early, honesty.
A precise word lets you notice and fix a problem. Learn the glossary by teaching it back.
Laws are predictions with boundaries. Ask them as questions, never use them to overrule users.
A few numbers settle most arguments: 44 pt and 48 dp, 4.5:1, 45–75 characters, 16 px, 0.1/1/10 s, 150–300 ms, 3 flashes, 5 users.
Put the numbers into tokens and components so you decide them once.
Checklists stop experts forgetting what they know. Run do-confirm lists after designing, on the real product.
Most mistakes come from four defaults: your knowledge, your setup, your order of work, your incentives. Fix the source.
Read fewer books, apply each one, and prefer free originals for the deep ideas.
Collect inspiration with a note on why, or do not collect it.
Self-assessment: I can…
Practice assignment for the next two weeks
Days 1–2: numbers. Run the numbers and contrast labs on your three main screens. Fix every red; move the values into tokens.
Days 3–5: screen review. Run the 30-item review on five screens, one a day. Keep before and after screenshots.
Days 6–7: states and forms. Draw and build the five states for your most important list, and run the forms checklist on your sign-up or main input.
Days 8–9: access and words. Run the accessibility and copy passes on your core flow, with a screen reader for ten minutes.
Day 10: mistakes. Read all sixty mistakes, mark your top five, and add a specific item for each to your own checklists.
Days 11–13: ship. Run the ship checklist on your next release, four areas an evening, including a tested backup restore.
Day 14: plan. Pick one person from the directory and one book from the reading list for the next month. Put the hours in your calendar.
If you read only five things
The Design of Everyday Things
Don Norman · the vocabulary and the stance: errors are design problems.
Refactoring UI
Wathan and Schoger · the fastest practical improvement in how your screens look.
Butterick's Practical Typography (free)
Matthew Butterick · because most of every screen is text.
The Mom Test
Rob Fitzpatrick · so you build the right thing before you build it well.
Magic Ink and Inventing on Principle (free)
Bret Victor · to keep asking what software could be, not only what it usually is.