Design is how it works. Foundations for a one-person product studio.

Warm-up: how to use this course

You will learn more from ten minutes of practice on your own product than from an hour of reading, so this course is built around doing, with reading as the scaffolding.

The course has 21 guides. This one is the foundation. Guides 2 to 16 each go deep on one area: the mind, problems, interaction, visual design, typography, reading and writing, motion, words, accessibility, data, systems, AI, launch, testing, and ethics. Guide 17 turns it all into a working practice. Guides 18 to 20 are breakdowns of real objects and products, and guide 21 is the reference shelf. You can see the whole map on the course hub.

Every chapter follows the same shape, so you always know where you are. A one-sentence core idea. An explanation of the mechanism, the why. Pictures: diagrams and drawn do/don't pairs. Real products that get it right or wrong. Common mistakes, with their causes. A scenario question to check you can apply it. An exercise, usually on your own product, with a rubric so you can grade yourself honestly.

Four habits that make this work

1. Read with a product open. Keep your own app, or one you use daily, running beside the guide. Every principle should land on a real screen within minutes.
2. Close the page and write. At the end of a chapter, write the core idea and two examples from memory. Retrieval practice is one of the most reliable findings in learning research: testing yourself beats rereading.
3. Do one weekly redesign. Pick one screen of your product every week. Redesign it using whatever you learned that week. Keep the before and after side by side in a folder. In six months that folder is your proof of progress.
4. Space it out. Each part ends with a short recap that pulls ideas from earlier chapters and other guides. Do those a few days after reading, not straight away. Slight forgetting followed by effortful recall is what builds durable memory (see The Human Mind for why).

Diagnostic: what do you already believe?

Three quick questions. Do not look anything up. Getting them wrong is useful: it shows you which chapters to read slowly.

Product design is deciding what a product should do, for whom, and how it should behave and look, so that a person can reach their goal with as little friction and as much confidence as possible.

The word "design" gets used for very different jobs. A graphic designer arranges type and images to communicate. A UI designer draws the screens. An interaction designer decides what happens when you press, drag or wait. A UX designer looks at the whole experience across time. A product manager decides which problems to solve and in what order. An engineer makes it real and keeps it working.

A product designer works across all of those boundaries, with one question at the centre: what should this product be, so that it is worth using? In a large company those jobs belong to different people. In your company of one, they all belong to you. That is the most important fact about your situation, and it is good news. The most common failure in big teams is the hand-off: a decision made in one discipline gets lost or distorted in the next. You do not have hand-offs. You can let a database decision shape the interface, or let an interface sketch kill a feature before you build it.

The neighbours, defined precisely

Notice the last row's output: decisions. The screens are only the record of those decisions. A product designer who only produces beautiful screens has skipped the job. A product designer who produces the right decisions, written in plain code with system fonts, has done most of it.

Design is not just what it looks like and feels like. Design is how it works.Steve Jobs, interviewed by Rob Walker, The New York Times Magazine, 2003

That line gets quoted to justify everything, so read it carefully. Jobs was rejecting the idea that design is a coat of paint applied at the end. The look and feel matter, but they are the visible part of something larger: how the product behaves, what it lets you do, what it refuses to let you do. The iPod's scroll wheel was a visual decision, an interaction decision and an engineering decision at once. Separating them would have produced a worse product.

Three tests for "is this good design?"

You will meet many principles in this guide. Under all of them sit three plain tests that apply to every decision:

1. Does it help someone do something they actually want to do? (Usefulness. A beautiful, easy feature nobody needs is still waste.)
2. Can they do it without help, without fear, and without wasted effort? (Usability. Find it, understand it, do it, know it worked, recover if it did not.)
3. Does it feel right, so they want to come back? (Desirability. Calm, trustworthy, pleasant, even delightful.)

The order matters. Usefulness first, because nothing rescues a useless product. Usability second, because nothing rescues a product people cannot operate. Desirability third, not because it is unimportant, but because it grows best on the first two. You will meet the ancient version of this triad in chapter 10.

In the wild

• iPodApple, 2001
  The scroll wheel was one decision that solved a product problem (navigating a thousand songs on a tiny screen), an interaction problem (fast, physical, proportional scrolling) and a visual problem (a clean front with almost nothing on it) at once. The best design decisions dissolve the boundaries between disciplines.
• Dropbox2008
  Instead of designing a file-sync interface, Dropbox made the interface a normal folder on your computer. Most of the "design" is a decision about what not to build. Sometimes the best interface is one the user already knows.
• Gmail Undo SendGoogle, Labs feature 2009, default 2015
  Email cannot be unsent once delivered. Gmail holds the message for a few seconds before it really goes, which makes "undo" possible. This is an engineering decision made for a design reason. Behavior is design, even when it is invisible.
• iA WriterInformation Architects, 2010
  A writing app whose main design decisions are things it leaves out: few formatting options, few settings, one carefully chosen typeface per mode. For focused tools, the feature list is the design.

Every product is built from five layers, from abstract to concrete: strategy, scope, structure, skeleton and surface. Each layer constrains the one above it, so most "surface" problems are really problems on a lower plane.

Garrett drew the model to explain why web projects kept failing despite good visual design. His answer: the visible part sits on top of four invisible decisions. If those are wrong or missing, no amount of visual work can save the result. The model is now over twenty years old and it is still the clearest map of what you are actually deciding when you "design an app".

Each plane in detail

1. Strategy: why does this exist?

Two halves: the user's needs and your objectives. For a solo creator, your objectives are honest and simple: revenue, time, joy, learning. Write both down. A product whose strategy is only "I wanted to build it" can be fine, but then say so, and do not pretend that a missing market is a design problem.

2. Scope: what is in and out?

The list of features and content. The most valuable thing on this plane is the "out" list. Every feature you add raises the cost of every future change, and every item you leave out makes the remaining ones easier to find. Garrett splits scope into functional specifications (what it does) and content requirements (what it contains).

3. Structure: how does it fit together?

Two parts: interaction design (how the system behaves in response to the user) and information architecture (how content is organized so people can find it). This is where your conceptual model lives: what the objects are (articles, highlights, tags), how they relate, and what verbs act on them. See Structure & Interaction.

4. Skeleton: where do things go?

Interface design (arranging controls), navigation design (moving between places) and information design (presenting information so it is understood). The wireframe is the skeleton's natural form.

5. Surface: what do the senses meet?

Visual design: type, color, imagery, spacing, motion, sound. It is the most visible plane and the one people judge first. See Visual Design and Typography.

Two rules that make the model useful

Rule one: problems flow upward, so diagnose downward. When something feels wrong on the surface, step down one plane at a time and ask whether the problem started there. A cluttered toolbar (surface) is often a skeleton problem (too many controls on one screen), which is often a scope problem (too many features), which is often a strategy problem (no clear idea of who the product is for).

Rule two: work overlaps, but finishes in order. Garrett did not argue for a waterfall. You can sketch surfaces while you are still deciding scope; often you must, because a sketch reveals what a feature really costs. But you should not finish a plane before the plane beneath it is settled. Polishing the surface of an undecided structure is the most expensive way to waste a week.

Seeing the planes in a real screen

In the wild

• Basecamp37signals, 2004 onward
  Basecamp's founders wrote openly about saying no to most feature requests and keeping scope small (see their book Getting Real, 2006). A firm scope plane is what lets a small team ship a coherent surface.
• Things 3Cultured Code, 2017
  Its structure (areas contain projects, projects contain to-dos and headings; "Today" and "This Evening" are views, not containers) is so clear that the surface can be almost bare. Strong structure buys you a quiet surface.
• Google Search1998 onward
  The home page has remained mostly one field and a logo for decades, because the strategy (find anything, fast) and the scope (search, not a portal) never wavered. Stable lower planes produce a stable surface.
• Kindle e-readersAmazon, 2007 onward
  The strategy (read books comfortably for hours) set the scope (reading first, very little else), which set the hardware surface: E Ink, matte, few buttons. Strategy can reach all the way to materials.

A design is a set of choices between options, made against criteria, inside constraints. Getting good at design mostly means getting good at that sequence: seeing more options, naming the criteria, respecting the constraints, and knowing which decisions are cheap to change.

Herbert Simon, in The Sciences of the Artificial (1969), defined design broadly: everyone designs who devises courses of action aimed at changing existing situations into preferred ones. It is a useful definition because it strips away the visual mystique. You design when you choose a default, name a button, decide what happens offline, or decide not to build sync this year.

Charles Eames, in a well-known question-and-answer session linked to the 1969 Paris exhibition Qu'est-ce que le design? (later filmed as Design Q&A), was asked whether design admits constraint. He answered that design depends largely upon constraints, and went on to describe the designer's job as recognizing as many of them as possible and accepting them with enthusiasm. That is the attitude to take. Constraints are not what stops you designing; they are what turns an infinite space of possible apps into a finite space you can search.

Step 1: generate more than one option

The single most reliable habit of strong designers is refusing to evaluate the first idea alone. The first idea is usually the most obvious one, which means it is the one every competitor also had. Force yourself to produce at least three genuinely different options, and make them different in kind, not in color: a list, a calendar, a single "next thing" card. Three is the minimum because two options turn into a debate, while three turn into a comparison.

Step 2: name the constraints

Constraints are facts you cannot change in this decision. Platform conventions (an iOS app has a back gesture whether you like it or not). Technical limits (you cannot sync in real time without a server). Your own time and skill. Legal requirements. The user's context (one hand, on a train, poor network). Write them down; they will kill some options immediately, which is a gift.

Step 3: write the criteria, in order

Criteria are what "good" means for this decision. They must be ranked, because they will conflict. "Fast" and "can't lose data" may pull in opposite directions; the ranking says which wins. A ranked list of three or four criteria turns a taste argument with yourself into a quick, almost mechanical comparison.

Step 4: know what kind of decision it is

Jeff Bezos, in his 2015 letter to Amazon shareholders, split decisions into two types. Type 1 decisions are one-way doors: hard or impossible to reverse, so they deserve slow, careful thought. Type 2 decisions are two-way doors: if you are wrong, you walk back through. His warning was that organizations tend to treat every decision as Type 1, and so they slow down. A solo creator usually has the opposite problem: treating one-way doors (data formats, pricing model, URLs, public APIs, the core object model) as casually as button colors.

In the wild

• Twitter's 140 characters2006
  The limit came from SMS, which allowed 160 characters per message, leaving room for a username. A technical constraint became the defining feature of the product's writing style. A constraint accepted fully can become identity.
• Instagram at launch2010
  Square photos, a small set of filters, and only a phone app. Each was a constraint that kept the product focused and made weak phone photos look better. Fewer options for the user can be a design decision made for them.
• Apple WatchApple, 2015
  A tiny screen forced a new interaction vocabulary (the Digital Crown, glances later replaced, complications). Whatever you think of individual choices, every one is a response to a hard size constraint. The tighter the constraint, the more original the design has to be.

An affordance is what an object lets you do. A signifier is what tells you so. Users cannot see affordances directly; they act on signifiers. When the two disagree, people fail, and they blame themselves.

The psychologist James J. Gibson coined "affordance" in the late 1970s to describe the action possibilities the environment offers an animal: a flat, firm surface affords standing; a handle-sized branch affords grasping. Norman brought the word into design in 1988. It spread so fast that designers started saying things like "I added an affordance" when they meant "I added a visual hint". In the 2013 revision of his book, Norman introduced signifier to fix this. The affordance is the relationship (this glass panel can be pushed). The signifier is the perceivable cue (a flat metal plate at hand height that says push here).

On screens the distinction matters even more, because almost everything has the same physical affordance: you can tap, click or press any pixel. What differs is whether anything happens. So in software, design work around "affordance" is really work on signifiers: shape, position, color, text, cursor, motion and convention that tell people what will respond and how.

The Norman door

A "Norman door" is the nickname for any door whose design tells you the wrong thing: a pull handle on a door you must push, or identical handles on both sides so you cannot tell which way it opens. The tell-tale sign of a Norman door is a label. If a door needs a sign saying PUSH, the design has already failed, and the sign is a patch. Try it.

Signifiers on screens

Software has its own Norman doors, and you can find them in almost any app. Text that looks like a link but is not. A link that looks like body text. A card with a hover shadow where only the tiny title responds. An icon button that looks like a decorative glyph. A "flat design" period in the mid-2010s produced many of these: when buttons lost their borders, fills and shadows, people lost the signifiers that told them where to press. Research by the Nielsen Norman Group around 2017 found that people needed more time and attention to find clickable elements on weakly signified flat interfaces.

The signifier toolkit

In the wild

• iPhone slide to unlockApple, 2007
  A track, a knob with an arrow and the words "slide to unlock" with a moving shimmer across them. Three signifiers (shape, label, motion) for one gesture nobody had seen before. New interactions need stacked signifiers until they become convention.
• iOS 7 text buttonsApple, 2013
  The redesign turned many buttons into plain colored words with no border. Apple later added an accessibility setting, Button Shapes, that puts shapes back under those words. When you strip signifiers, some people need them restored.
• Google Docs, Notion2006, 2016 onward
  An empty document shows placeholder text in gray ("Type '/' for commands" in Notion). The placeholder is a signifier for an invisible feature. Empty states are prime real estate for signifiers.
• Most scroll viewseverywhere
  Cutting the last visible row in half signals "more below". A list that ends exactly at the screen edge looks finished, and people stop scrolling. Partial reveal is a signifier you get by layout alone.

Mapping is the relationship between controls and their effects. When the layout of the controls mirrors the layout of what they control, people need no labels and make fewer errors. Constraints narrow the possible actions so the right one is the obvious one.

Natural mapping: the stove

Norman's favourite example is the kitchen stove. Four burners sit in a rectangle. The four knobs often sit in a straight line. Which knob controls which burner? With a straight row, there are 24 possible arrangements, and the cook has to read tiny labels or remember. If the knobs are arranged in the same pattern as the burners, the mapping is obvious, and labels become unnecessary.

Now try it yourself. The lab below is a room with four lamps and a switch panel. You will be asked to turn on one named lamp at a time. Try a few rounds with each panel and compare your times and errors.

Mapping in software

Screens are full of mapping decisions, and most are invisible until they go wrong. A slider for text size should get bigger to the right and show a small "A" on the left and a large "A" on the right. A brightness control should increase upward or rightward. The order of items in a settings list should match the order of the things they affect on screen. A volume key on the side of a phone should raise the volume with the upper button.

Good mappings come from three sources. Spatial correspondence: the control's layout mirrors the effect's layout (the stove, or a window-snapping control drawn as a little screen diagram). Cultural metaphor: more is up, time flows left to right in left-to-right languages. Biological or perceptual: louder is "bigger", brighter is "more". A mapping that uses all three at once almost never needs explaining.

Constraints: four kinds

Norman describes four kinds of constraint that guide people toward correct actions. His illustration is a small Lego motorcycle kit: even without instructions, most people assemble it correctly, because the pieces only fit some ways (physical), the rider faces forward (cultural and semantic), and the last piece must go in the last remaining spot (logical). Every kind has a software equivalent.

In the wild

• macOS display arrangementApple, long-standing
  You arrange multiple monitors by dragging rectangles that mirror their physical positions. Moving the mouse off the right edge then lands where the picture says. The control is a miniature of the world.
• Natural scrollingmacOS Lion, 2011
  Apple reversed trackpad scrolling so content moves with your fingers, as on a touch screen. Many people found it wrong at first because their old mapping (move the scroll bar) was in their heads. Mappings that conflict with learned ones carry a switching cost, even if they are more "natural".
• Car seat controlsMercedes-Benz and others
  Some cars put the seat adjustment controls on the door in the shape of a seat: push the "back" part to tilt the back. The most famous physical example of spatial mapping, and a good model for settings panels.
• UPI PIN entryIndia, 2016 onward
  Payment apps show a fixed number of PIN boxes (four or six) that fill as you type. The structure physically constrains length and shows progress. A constraint can also be feedback.

Every action needs an immediate, informative response, and the product as a whole must give people an accurate story of how it works. Feedback answers "did that work?"; a conceptual model answers "how does this thing work at all?"

Feedback: closing the loop

When you press a light switch, the light comes on. That is feedback: the world tells you the result of your action. Software breaks this loop all the time, because the result happens somewhere invisible (a server, a file, a background queue). Good feedback has four properties:

1. Immediate. Classic response-time research, from Robert Miller (1968) and later summarized by Card, Moran and Newell and by Jakob Nielsen, gives three thresholds: about 0.1 second feels instantaneous; about 1 second keeps the flow of thought but the delay is noticed; about 10 seconds is the limit for keeping attention on the task. Above 0.1 s, show that something is happening. Above about 1 s, show progress. Above about 10 s, let people do something else and notify them later.
2. Informative. "Error" is feedback, but useless. "Couldn't save: you're offline. Your changes are kept on this device and will sync when you reconnect" is feedback that lets people act.
3. Proportional. Small actions get small feedback (a checkbox ticks). Big or risky actions get bigger feedback (a toast with Undo). Too much feedback is noise: a modal for every success trains people to dismiss modals.
4. Located. Feedback should appear where attention already is. A "Saved" message in a status bar the user is not looking at barely exists.

Try the most common feedback failure in software: a save action that tells you nothing.

Conceptual models: the story in the user's head

A conceptual model is a simplified explanation of how something works. It does not need to be technically accurate; it needs to be accurate enough to predict what will happen. "Files live in folders" is a conceptual model. So is "the trash keeps deleted things until I empty it", and "a draft is private until I publish it".

Norman's key insight is that there are three models, not one, and the designer only controls one of them directly.

Norman's classic example is the home thermostat. Many people believe that turning it far higher makes the room heat faster, like opening a valve wider. In most homes it does not: the heater runs at one speed until the target is reached, like a timer switch. The wrong model leads to wasted energy and overheated rooms, and nothing on the thermostat corrects it. In software, the same thing happens with sync ("is my phone copy the real one?"), with deletion ("does removing it from this list delete the file?"), and with sharing ("can people with the link edit, or only view?").

In the wild

• WhatsApp ticksMeta, read receipts from 2014
  One gray tick: sent. Two gray ticks: delivered. Two blue ticks: read. A tiny, consistent feedback system that hundreds of millions of people learned without instructions. Feedback can be compact if it is consistent.
• Google Docs statusGoogle
  A small status near the title tells you when changes are saved, and switches to an offline state when you lose connection. Persistent, located status beats one-off messages.
• macOS document dotApple
  On a Mac, an unsaved document shows a dot in the window's close button. Unsaved state can be signalled with almost no pixels.
• Dropbox sync iconsDropbox, 2008 onward
  Small badges on files (synced, syncing, online-only) make the hidden sync model visible in the file browser itself. Bring invisible system state to the object it concerns.

Between a person and their goal lie two gulfs: the gulf of execution (how do I do it?) and the gulf of evaluation (did it work?). Design bridges both. The seven stages of action tell you exactly where on the bridge someone fell.

The gulfs were described by Hutchins, Hollan and Norman in the mid-1980s, and Norman made them central to his book. The idea is simple. When you want something, you have to translate your goal into actions the system accepts. That distance is the gulf of execution. Then the system changes, and you have to interpret what you see and compare it with what you wanted. That distance is the gulf of evaluation. Signifiers, mapping and constraints bridge execution. Feedback and a good conceptual model bridge evaluation.

The seven stages of action

Norman breaks every interaction into seven stages: one for the goal, three for execution, and three for evaluation. Most of the time they happen in a fraction of a second and nobody notices. They become visible when something goes wrong, which is exactly why they are useful for diagnosis.

Norman also points out that goals come in levels. "Send Asha the photos" sits under "keep the friendship warm", which sits under "be a good friend". Most products serve the lowest level, but the best ones understand the levels above. A photo app that suggests "Share this album with the people in it" has understood the higher goal. This links directly to Cooper's goal-directed design in chapter 11 and to jobs to be done in Problems Worth Solving.

In the wild

• Command palettesSublime Text (2008), VS Code, Linear, Raycast
  Typing what you want ("rename", "dark theme") narrows the gulf of execution: you specify your intent in words, and the palette shows the action. Let people state goals in their own language.
• Swiggy and Zomato order trackingIndia, 2010s
  After paying, you see the order move through clear states (confirmed, being prepared, picked up, arriving) with a map. Long processes need a visible path for evaluation, or anxiety fills the gap.
• SpreadsheetsVisiCalc 1979 onward
  Change a number and every dependent cell updates at once. The gulf of evaluation almost disappears, which is a big part of why spreadsheets became so widely used. Instant visible consequences make complex systems learnable.

People do not carry precise knowledge in their heads; they rely on what the world shows them. When they err, it is usually a slip (right goal, wrong action) or a mistake (wrong goal or plan). Design for both, and design with people, not just for them.

Knowledge in the head and knowledge in the world

Norman's demonstration is the coin test: most people cannot draw the front of a coin they have handled thousands of times, yet they never fail to recognize it. We store just enough to tell things apart and rely on the world for the rest. Precise behavior does not require precise knowledge, because the world fills in the gaps through signifiers, constraints and visible options.

This has a direct design consequence. Anything you put in the world (a visible menu, a recent-files list, a label, an autocomplete suggestion) can be recognized. Anything you leave in the head (a keyboard shortcut, a command syntax, a code from an email) must be recalled. Recognition is far easier than recall, which is why Nielsen made "recognition rather than recall" one of his ten heuristics.

Slips and mistakes

Norman builds on the psychologist James Reason's work on human error. The core split is between slips, where the intention was right but the action went wrong, and mistakes, where the intention itself was wrong. They need different fixes, so telling them apart is a practical skill.

Designing for error

Norman's advice is to assume every error that can be made will be made, and to design accordingly. In order of strength:

1. Prevent: use constraints so the error cannot happen (chapter 5).
2. Make reversible: undo, trash with a grace period, version history. Reversibility turns errors into exploration.
3. Detect early: warn at the moment of risk, specifically, not in general ("You mentioned an attachment but none is attached").
4. Explain and help recover: when an error does happen, say what happened, why, and what to do next, in plain words.
5. Confirm, rarely: confirmation dialogs are the weakest tool, because people learn to press OK without reading. Save them for irreversible, high-cost actions, and make them specific ("Delete 'Thesis draft' and its 14 versions? This can't be undone").

Human-centered design

Norman's book ends with a process: human-centered design, an approach formalized in the international standard ISO 9241-210. Its loop is observation, idea generation, prototyping and testing, repeated. The point is not the steps but the attitude: assume your first understanding of the problem is wrong, and use contact with real people to correct it, early and often. He also warns that the right problem is rarely the one first stated. "Solve the correct problem" is the first job (more in Problems Worth Solving).

In the wild

• Gmail attachment reminderGoogle
  If your message mentions an attachment but none is attached, Gmail asks before sending. Detect the memory-lapse slip at the exact moment of risk.
• macOS menusApple
  Every menu item shows its keyboard shortcut on the right. Novices click; over time they learn the shortcut by seeing it. Knowledge in the world gradually becomes knowledge in the head.
• Figma version historyFigma, 2016 onward
  Files keep a browsable history, so you can return to earlier states without having saved copies yourself. Reversibility at the document level encourages bold exploration.
• Caps Lockkeyboards everywhere
  The classic mode error: the key changes what every other key does, and its indicator light is small or missing. Password fields on macOS show a Caps Lock symbol inside the field. If you must have a mode, signal it where attention is.

Dieter Rams' ten principles describe good design as innovative, useful, aesthetic, understandable, unobtrusive, honest, long-lasting, thorough, environmentally friendly and as little design as possible. Each one translates directly into concrete software decisions.

Rams was head of design at Braun from 1961 to 1995 and designed furniture for Vitsœ, including the 606 Universal Shelving System (1960), which is still made today. Around the late 1970s, worried that the world was filling up with a confusing clutter of forms, colors and noises, he asked himself whether his own design was good design, and wrote his answer as ten principles. His summary of them is three words, in German Weniger, aber besser.

Less, but better.Dieter Rams, his motto, and the title of his 1995 book

The principles are often reduced to "minimalism". That misses most of them. Only the tenth is about reduction. The others are about purpose (useful), clarity (understandable), restraint (unobtrusive), ethics (honest), time (long-lasting), care (thorough) and responsibility (environmentally friendly). Read them as a checklist of the qualities a product earns, not a style.

Click through the ten. Each has Rams' principle, its meaning in software, a drawn don't and do, and a one-line test you can run on any screen.

In the wild

• Braun SK 4Rams and Hans Gugelot, 1956
  A radio-record player with a clear plexiglass lid instead of a wooden cabinet top, nicknamed "Snow White's coffin". It showed the product's workings and controls instead of disguising them as furniture. Honesty and understandability as a visual choice.
• Braun ET66 calculatorDietrich Lubs, 1987
  Round, slightly convex buttons, a strict grid, and color used only to group functions (a yellow-orange equals key). Its resemblance to the early iPhone calculator app is often pointed out. Color as hierarchy; a design language that lasted decades.
• Vitsœ 606 shelvingRams, 1960, still produced
  A modular system you can extend and rearrange for decades, with parts that stay compatible. Long-lasting includes compatibility. In software: stable formats and APIs.
• iA Writer2010
  Plain text files in a folder you choose, a single focus on writing, almost no chrome. Unobtrusive, long-lasting and as little design as possible, in one product.
• Linear2019
  An issue tracker known for speed, keyboard-first operation and attention to small details such as consistent states and fast transitions. Thoroughness can be a product's main selling point.

A handful of tested checklists let you evaluate any interface quickly. Vitruvius gives the top-level triad (firm, useful, delightful); Nielsen, Shneiderman and Tognazzini give you detailed rules. Use them as lenses for finding problems, not as recipes for creating solutions.

Firmness, commodity and delight

The Roman architect Vitruvius, writing De architectura in the first century BC, said a building should have firmitas, utilitas and venustas. The English diplomat Henry Wotton's 1624 rendering, "commodity, firmness, and delight", is the version designers still quote. Two thousand years later it still works as the shortest possible definition of good design, and it maps neatly onto software.

Aarron Walter's Designing for Emotion (2011) turned the same idea into a pyramid adapted from Maslow: a product must first be functional, then reliable, then usable, and only then can it be pleasurable. Each layer depends on the ones below it.

Nielsen's ten usability heuristics

Jakob Nielsen developed his heuristics with Rolf Molich around 1990 and published the refined list of ten in 1994. They are "heuristics" because they are rules of thumb, not precise guidelines: they help you spot problems, and they are the basis of the heuristic evaluation method covered in Testing & Iteration. Here is the short version, each with one software example.

Shneiderman's eight golden rules

Ben Shneiderman, a computer scientist at the University of Maryland, published his eight golden rules of interface design in Designing the User Interface (first edition 1986), and has refined them through later editions. They overlap with Nielsen's but emphasize two things Nielsen does not name directly: closure and the user's sense of control.

1. Strive for consistency. Same situations, same actions, same words.
2. Seek universal usability. Design for novices and experts, different ages, abilities and devices. (Earlier editions: "enable frequent users to use shortcuts".)
3. Offer informative feedback. Modest for frequent actions, substantial for rare and major ones.
4. Design dialogs to yield closure. Sequences have a beginning, middle and end, and the end is clearly signalled ("Order placed. Arrives Thursday").
5. Prevent errors. And when they happen, offer simple, specific recovery.
6. Permit easy reversal of actions. It relieves anxiety and encourages exploration.
7. Keep users in control. Experienced users want to feel they are in charge, and that the system responds to them, not the other way round.
8. Reduce short-term memory load. People hold only a few items in mind; don't make them carry information between screens.

Tognazzini's first principles

Bruce "Tog" Tognazzini founded Apple's Human Interface Group and wrote early editions of Apple's Human Interface Guidelines. His essay "First Principles of Interaction Design", maintained on his site asktog.com and revised in 2014, lists principles that are more concrete than Nielsen's. A selection worth knowing:

Anticipation

Bring people the information and tools they will need for the next step, before they ask.

Autonomy

Keep users in control, but within boundaries, and keep them informed of status so they can make their own decisions.

Defaults

Defaults should be easy to replace (selected so typing overwrites them), and should reflect what most people want.

Efficiency of the user

Optimize the user's time, not the computer's. The user's time is the expensive resource.

Explorable interfaces

Make actions reversible and offer stable perceptual landmarks, so people can explore without fear of getting lost or breaking things.

Fitts's law

The time to acquire a target depends on its distance and size. Big, close targets are fast; screen edges and corners are effectively infinitely large for a mouse. (More in The Human Mind.)

Latency reduction

Make the interface respond instantly, even if the work takes time; acknowledge every click immediately.

Protect users' work

Never let users lose their work through system failure or their own error.

State tracking

Remember where people were and what they were doing, and bring them back there.

Which framework, when?

In the wild

• Mailchimp2000s and 2010s
  Aarron Walter worked on Mailchimp's user experience, and the product became known for a friendly voice and small moments of humor placed on top of a dependable tool. Personality layered on reliability, not instead of it.
• macOS Finder corners and menu barApple
  The menu bar sits at the top edge of the screen, so you can throw the pointer upward and it stops on the menu. Tognazzini often used this as a Fitts's law example. Edges are big targets for free.
• Stripe CheckoutStripe
  Card fields format as you type, catch common errors inline, and show a clear success state. Error prevention, recovery and closure in one small flow.

Cooper argued that you design for people's goals, not tasks or features. Raskin argued that interfaces should never waste human attention or harm human work. Victor argued that most software exists to show information, so interaction should be a last resort. Together they push you toward software that does more and asks less.

Alan Cooper: design for goals

Alan Cooper, often called the "father of Visual Basic" for the visual programming tool he sold to Microsoft, became one of the first prominent voices for interaction design as a profession. In About Face (1995) and The Inmates Are Running the Asylum (1999) he argued that software was hard to use because programmers designed it around how computers work, and he proposed goal-directed design.

The core distinction is between goals and tasks. Goals are end states people want and are fairly stable ("never miss a client payment"). Tasks are the steps a particular technology makes them do ("export CSV, open spreadsheet, filter by date"). Tasks change when technology changes; goals do not. Design for the goal, and you are free to eliminate tasks. Cooper also distinguished personal goals (not feeling stupid, not making mistakes) from practical ones, and pointed out that software that makes people feel stupid fails a goal they never state.

Personas, and their limits

To keep goals concrete, Cooper introduced personas in Inmates: precise descriptions of hypothetical archetypal users, built from research, each with a name, context and goals. His argument was that designing for "the user" lets every feature in, because some imagined user always wants it (he called this the "elastic user"), whereas designing for one specific person forces choices.

Personas became hugely popular, and widely misused. Common failures: personas invented without research, full of demographic trivia (age, favourite coffee) that changes no decision; personas used to stereotype; and personas that sit in a slide deck and never affect a design. Many teams now prefer jobs-to-be-done statements and real interview notes. For a solo creator, the useful core of Cooper's idea is simple: design for one specific, real person's goals at a time, ideally a person you have actually talked to.

Perpetual intermediates

Cooper also observed in About Face that most users are neither beginners nor experts. People pass through the beginner stage quickly (or quit), and few ever invest enough to become experts. The majority settle as perpetual intermediates: they know the core features well and the rest vaguely.

Jef Raskin: the humane interface

Jef Raskin started the Macintosh project at Apple in 1979 and later designed the Canon Cat. His book The Humane Interface (2000) defines an interface as humane if it is responsive to human needs and considerate of human frailties. Several of his ideas sharpen what you learned from Norman:

Locus of attention

People have only one locus of attention at a time. Anything outside it (a status bar message, a corner badge) may as well not exist. Put feedback where attention is.

Habituation

Any often-repeated action becomes automatic. People will habituate to pressing "OK" on a confirmation dialog, which is why confirmations fail. Design so habits are safe.

Modes

A mode is when the same action produces different results depending on a state that is not your locus of attention. Raskin considered modes a major source of errors. His alternative: quasimodes, states held only while you physically hold them (like holding Shift), which cannot be forgotten.

Monotony

Raskin used "monotony" for interfaces that offer one obvious way to do each thing, so habits form fast and reliably. Many redundant ways to do the same thing slow habit formation.

Protect the user's work

He framed this as a parody of Asimov's laws of robotics: a computer should never harm your work, or through inaction allow it to come to harm; and it should never waste your time or make you do more work than necessary.

Bret Victor: information software

In his 2006 essay Magic Ink: Information Software and the Graphical Interface, Bret Victor divided software into three kinds: information software (helping you learn something: what's on my calendar, when is the next train), manipulation software (helping you create: an editor, a design tool) and communication software. His claim was that most software people use is information software, yet it is designed like manipulation software, full of controls, forms and navigation.

Information software, he argued, is closer to graphic design than to machine design. Its job is to show the right data, arranged to answer the user's questions, using context (time, location, history) to infer what they want. Interaction is a cost the user pays when the software failed to infer; he titled one section "Interaction considered harmful". Victor illustrated this with a redesign of a San Francisco BART train-schedule widget that showed upcoming trains at a glance instead of asking for a query.

Raskin's "don't waste the user's time" and Victor's "interaction is a last resort" meet in the same place: every tap, field and menu must earn its existence. Try the difference below.

In the wild

• Weather appsApple Weather, Dark Sky (2012, acquired by Apple 2020)
  Open the app and your local forecast is already there; Dark Sky became known for hyperlocal "rain starting in 12 minutes" notices. Information software at its best: no query needed.
• Google Maps commute cardsGoogle
  Maps can learn your home and work and show travel time to the likely destination before you search. Context replaces a form.
• VimBram Moolenaar, 1991
  Built around modes (normal, insert, visual). Loved by experts who habituate to it, notoriously hard for newcomers. Modes trade learnability for power. Raskin's warning in action.
• Things 3 "Today"Cultured Code, 2017
  Opens to what is due today, including calendar events, rather than to an empty list of projects. Show the answer to "what now?" by default.

Good design alternates between opening up (exploring many possibilities) and narrowing down (choosing one), twice: first to find the right problem, then to find the right solution. A solo creator can run both diamonds in a week.

The UK Design Council published the Double Diamond in 2005 after studying how design teams at large companies actually worked. It has four phases: Discover (explore the problem widely), Define (narrow to a clear problem statement), Develop (explore many solutions) and Deliver (narrow to one, test, ship). The shape matters more than the labels. It says that you should diverge before you converge, and that you should do it for the problem before you do it for the solution.

Divergence and convergence

The two motions need different mindsets, and mixing them is the most common way to stall. When you diverge, you defer judgment: quantity, variety, wild options, no "but that won't work". When you converge, you judge hard: criteria, constraints, kill your darlings. Trying to do both at once produces one cautious idea, judged before it was ever fully imagined.

A one-person week

Here is the double diamond scaled to a solo creator with a product already in use. It assumes about one focused design hour a day alongside building; adjust to your rhythm.

1. Monday, discover (60 min). Read the last week's support emails, reviews and analytics. Talk to or message one user. Use your own product for a real task. Write every observation as a fact, not a solution.
2. Tuesday, define (45 min). Cluster the observations. Pick one problem. Write a problem statement: "[Person] trying to [goal] struggles with [obstacle], which causes [consequence]."
3. Wednesday, develop (60 min). Sketch at least five solutions on paper, of different kinds (chapter 3). Pick two. Make each just real enough to judge (chapter 13).
4. Thursday, deliver (build time). Build the stronger one, in code, at the lowest fidelity that can ship.
5. Friday, check and ship (45 min). Use it yourself on a real task. If possible, watch one person use it. Ship it, note it in your changelog, and write what you will look for next week.

Fixed time, variable scope

Ryan Singer's Shape Up (Basecamp, 2019) adds a useful twist for small teams: decide the appetite first (how much time is this problem worth: two days? two weeks?) and then shape a solution that fits it, instead of estimating how long a fixed solution will take. For a solo creator this is a lifesaver. It turns "how long will this take?" (unknowable) into "what is the best solution I can build in three days?" (a design question).

In the wild

• Basecamp's Shape UpRyan Singer, 2019
  Six-week cycles, work shaped at the right level of abstraction (rough but solved), and a cool-down between cycles. Published free online. Process designed for small teams that build what they design.
• Superhuman onboardingSuperhuman, late 2010s
  The email app became known for one-on-one onboarding calls with new users in its early years. Each call doubled as discovery research. Discovery can be built into the way you serve customers.
• Indie Mac and iOS appsmany
  Solo developers often run public changelogs and feedback boards, and some develop in public on social media, collecting reactions to rough ideas before building them. Cheap, continuous divergence with real people.

Every representation of a design (sketch, wireframe, mockup, prototype, code) answers different questions at a different cost. Choose the lowest fidelity that can answer the question you have right now, and climb only when you need to.

Bill Buxton's Sketching User Experiences (2007) makes a distinction every designer should carry: a sketch and a prototype are not just rough and polished versions of the same thing. A sketch is for exploring: it is quick, cheap, disposable, plentiful and deliberately ambiguous, and it invites questions. A prototype is for testing: it is more refined, more expensive, more specific, and it seeks answers. You make many sketches to find a direction, and a few prototypes to check it.

Fidelity has costs in both directions. Too low, and you cannot judge what matters (a paper sketch cannot tell you whether an animation feels fast). Too high, and you have spent time on details that will be thrown away, and you become attached to them. Worse, high fidelity invites the wrong feedback: show someone a polished mockup and they will comment on colors, not on whether the flow makes sense.

What each rung is for

When to skip rungs, and designing in code

The ladder is not a staircase you must climb step by step. Skip rungs when the question you have can only be answered higher up, or when a higher rung is cheap for you. Three common cases:

• Skip to code for feel. Scrolling, gestures, animation timing and performance cannot be judged in static images. If the core question is "does it feel fast?", build a thin slice in code.
• Skip mockups when you have a system. Once you have type, color and spacing tokens and a set of components, a wireframe plus your system is effectively a mockup. Many solo creators go sketch → code.
• Never skip the sketch. It costs minutes and it is the only rung where you can afford ten directions. Skipping it means your first idea becomes your only idea.

Designing in code is a real advantage for a developer-designer: real data, real content lengths, real speed, and no translation step. The risk is that code makes changes feel expensive, so you stop exploring, and that you design what is easy to build instead of what is right. The fix is discipline: sketch at least three options on paper first, then build the one you choose, and use throwaway branches for experiments so nothing feels precious.

In the wild

• Paper prototypinglong-standing practice; see Carolyn Snyder, 2003
  Teams test whole flows with paper screens a person "operates" by swapping sheets. Snyder's book Paper Prototyping documented the method. You can test navigation before writing any code.
• Figma prototypesFigma
  Linking frames with transitions turns static mockups into clickable prototypes in minutes, good for testing navigation and order. The prototype rung has become cheap; use it for flow questions.
• SwiftUI previews and hot reloadApple, 2019; Flutter, React tooling
  Live previews make code feel closer to a sketching medium for many developers. Fast feedback tools move code down the cost curve, which makes designing in code more viable.

Design thinking for a soloist comes down to four habits: frame the problem before solving it, use constraints as tools, make trade-offs explicitly, and spend craft where it compounds. Every decision has a cost that keeps growing after you make it.

Framing: the problem behind the request

Norman argues that designers should never start by solving the problem they were given, because the stated problem is usually a symptom. A simple tool for getting underneath it is the "five whys" associated with Taiichi Ohno and the Toyota Production System: ask why a problem happens, then why that happens, a few times over, until you reach a cause you can design for. Five is a rule of thumb; stop when the answer becomes something you can act on.

Another framing tool is the "How might we…" question, popularized by design consultancies such as IDEO. "How might we help freelancers get invoices approved faster?" is open enough to allow many answers and narrow enough to act on. Compare it with "How might we add export?" (too narrow, a solution in disguise) and "How might we help freelancers?" (too broad to start).

Constraints as tools

Chapter 3 treated constraints as facts you must accept. You can also choose them on purpose, as creative tools. A self-imposed constraint shrinks the search space and forces originality. Some that work well for software:

• One screen. What if the whole product had to fit on one screen? You will discover what is essential.
• No settings. Every setting you want to add must become a good default instead.
• One typeface, two sizes, one accent. Hierarchy must come from position, weight and space.
• Works offline first. Forces a clear data model and honest sync states.
• Three-day appetite. The best version you can build in three days, not the ideal version.

Trade-offs: every design is a compromise

No design maximizes everything. Simplicity trades against power. Speed of building trades against polish. Flexibility trades against learnability. The designer's job is not to avoid trade-offs but to make them on purpose and say which way they went.

Larry Tesler, the computer scientist known for cut, copy and paste and for his work at Xerox PARC and Apple, gave this a sharper form, often called Tesler's law or the law of conservation of complexity: every application has an inherent amount of complexity that cannot be removed, only moved. The question is whether the user deals with it or the system (and its designer) does. A timezone-aware calendar is complex; you can either make each user think about timezones, or absorb that complexity in the code so they never have to.

Good enough versus craft

You cannot polish everything. A solo creator who tries will never ship. But a product with no polish anywhere feels careless. The answer is to concentrate craft where it compounds: on the hot path, the few screens and actions people use every single session. A rough edge in the export dialog, seen twice a year, costs little. A rough edge in the main list, seen fifty times a day, costs a lot.

"Good enough" still has a floor. Every screen must be correct, clear and consistent with your system. It is the extra layer (custom motion, perfect empty-state illustrations, bespoke micro-interactions) that you ration.

The cost of a decision over time

An old observation in software engineering, associated with Barry Boehm's work in the 1970s and 1980s, is that the later a problem is found, the more it costs to fix. Design decisions follow the same curve. Changing your mind on a sketch costs seconds. Changing it after launch costs code, migration, documentation, user re-learning, and sometimes trust. And every feature carries an ongoing cost after it ships: maintenance, support, testing, and the attention it takes from everything else on screen.

In the wild

• Apple Photos "Memories"Apple, 2016
  Grouping photos into events and stories is complex (faces, places, dates), but the app absorbs it so the user just scrolls. Tesler's law: complexity moved from user to system.
• Notion2016 onward
  Chose power and flexibility (blocks, databases, relations), accepting a steeper learning curve and offering templates to soften it. A deliberate point on the triangle, with compensation for what it gave up.
• Craigslist1995 onward
  Very little visual craft, but fast, predictable and focused on its core path for decades. "Good enough" surface on a firm, useful core can last a very long time.

Precise words let you see precise problems. "It feels off" cannot be fixed; "the primary action has weaker contrast than the secondary one" can. Learn these terms and use them in your notes, your critiques and your decisions file.

The glossary below has about fifty terms, grouped so that related ideas sit together. Each links to the guide where it is taught in depth. You do not need to memorize it in one sitting. Read it once now, then use the flashcard exercise at the end of the chapter to make it stick. The full course glossary lives in the Reference Library.

Mind and perception

Mental model

A person's internal explanation of how something works. Formed from experience and the system image (chapter 6).

Conceptual model

The simplified explanation the designer intends people to form; ideally the mental model matches it.

Cognitive load

The mental effort a task demands. Extraneous load (caused by poor design) is the kind you can remove. See The Human Mind.

Recognition versus recall

Recognizing an option you can see is far easier than recalling it from memory (chapter 8).

Locus of attention

Raskin's term for the single thing a person is attending to right now (chapter 11).

Habituation

Repeated actions become automatic, including dismissing warnings.

Preattentive attributes

Visual properties (color, size, orientation, motion) noticed in a fraction of a second, before focused attention.

Gestalt principles

Perceptual grouping rules (proximity, similarity, closure, continuity, common region) that explain why some layouts read as groups. See Visual Design.

Fitts's law

Time to hit a target grows with distance and shrinks with size (chapter 10).

Hick's law

Decision time grows with the number and complexity of choices (roughly logarithmically for equally likely choices).

Jakob's law

Nielsen's observation that users spend most of their time on other products, so they expect yours to work the same way.

Interaction

Affordance

The relationship between an object and a person that makes an action possible (chapter 4).

Signifier

A perceivable cue that tells people what action is possible and where.

Mapping

The relationship between controls and their effects; natural when the layout matches (chapter 5).

Constraint

A limit that guides people toward correct actions: physical, cultural, semantic or logical.

Feedback

Communication of the result of an action, ideally within 0.1 s.

Feedforward

Information before an action about what will happen if you take it (a button label that says "Delete 3 files", a preview while dragging).

State

The condition of an element or the system at a moment: default, hover, focus, pressed, disabled, loading, error, empty, success.

Mode / quasimode

A mode changes how the same input is interpreted; a quasimode does so only while held (chapter 11).

Direct manipulation

Acting on visible objects with immediate, reversible results (dragging a file, resizing a window), described by Shneiderman in the early 1980s.

Microinteraction

A small, contained moment built around a single task (a toggle, a like, a pull-to-refresh). Named and described by Dan Saffer in his 2013 book.

Progressive disclosure

Showing only what is needed now and revealing advanced options on request.

Hit target

The area that responds to a tap or click, which can be larger than the visible element.

Structure

Information architecture (IA)

How content and functions are organized, labelled and connected so people can find them. See Structure & Interaction.

Navigation

The means of moving between places: tabs, sidebars, stacks, search, links.

Flow

A sequence of screens and actions that completes a task (also, separately, Csikszentmihalyi's state of absorbed focus).

Happy path

The flow when everything goes right. Designing only this is a classic mistake.

Edge case

An unusual but possible situation: empty data, huge data, very long text, no network.

Empty state

What a screen shows when there is nothing to show yet. Prime space for signifiers and teaching.

Primary action

The one most important action on a screen, given the strongest visual weight.

Object model

The nouns of your product and their relationships (a project contains tasks), on Garrett's structure plane.

Visual

Visual hierarchy

The order in which the eye perceives elements, set by size, weight, contrast, color and position.

Grid

An underlying structure of columns and rows that aligns elements.

Whitespace (negative space)

Empty space that separates, groups and gives rest. It is a material, not leftover.

Alignment

Placing elements along shared edges or axes; the cheapest way to look ordered.

Contrast

Difference between elements (in size, weight, color, luminance) that creates emphasis. Also, specifically, the luminance contrast ratio used for legibility (WCAG). See Accessible & Inclusive.

Rhythm

Repetition of spacing and sizes that makes a layout feel coherent.

Density

How much information fits in a given space; a deliberate choice, not a fixed virtue.

Type scale

A set of related font sizes used consistently. See Typography.

Measure

Line length in characters; comfortable body text is often cited around 45 to 75 characters.

Leading (line height)

Vertical distance between lines of text.

Skeuomorphism

Imitating physical materials and objects in UI (stitched leather, paper textures), dominant in early iOS until 2013.

Flat design

A style that removes simulated depth and texture; risks losing signifiers if taken too far.

Process and system

Fidelity

How closely a representation resembles the final product (chapter 13).

Wireframe, mockup, prototype

Structural layout; static visual design; interactive simulation.

Problem statement

A sentence naming who, which goal, which obstacle and what consequence, with no solution inside.

Jobs to be done (JTBD)

A framing in which people "hire" a product to make progress in a situation. See Problems Worth Solving.

Persona

A research-based archetype of a user, with goals (chapter 11).

Appetite

The amount of time a problem is worth, set before shaping a solution (Shape Up).

Design system

A set of reusable decisions (tokens, components, patterns, guidelines). See Systems & Platforms.

Design token

A named design value (color, spacing, radius) stored as data so it can be used consistently in code.

Component

A reusable interface building block with defined states and variants.

Quality and ethics

Heuristic evaluation

Reviewing an interface against a set of rules of thumb, such as Nielsen's ten (chapter 10).

Usability

How effectively, efficiently and satisfyingly people can use something to reach a goal (the ISO 9241-11 definition).

Perceived performance

How fast something feels, which can differ from how fast it is. See Motion & Feel.

Dark pattern (deceptive pattern)

A design that tricks people into actions against their interests; term coined by Harry Brignull in 2010. See Honest & Calm.

Accessibility

Designing so people with disabilities can perceive, operate and understand the product; guided by WCAG.

Calm technology

Technology that informs without demanding attention, from Mark Weiser and John Seely Brown's work at Xerox PARC in the 1990s.

In the wild

• Apple Human Interface GuidelinesApple, since the 1980s
  A long-running public vocabulary for platform behavior (sheets, popovers, modality, hierarchy). Platform guidelines are a free, shared vocabulary; read them.
• Material DesignGoogle, 2014
  Introduced a named, documented system of components, elevation and motion that many teams adopted as shared language. Named components make design discussable.
• Laws of UXJon Yablonski, website and later a book
  Collects psychology principles (Fitts, Hick, Jakob, Miller and more) with short explanations. A handy reference for the "mind" family of terms.

Designers see more than other people because they look in a fixed order, with named questions, and write down what they see. Use a ten-point observation sequence on any screen, keep a swipe file of what works, and critique against objectives rather than taste.

Most people look at an app the way they look at a face: all at once, with an overall impression ("nice", "messy"). That impression is real data, but it is not usable. A designer slows the looking down into separate passes, each asking one question. After a few weeks of practice, the passes run in parallel in a few seconds, and you start noticing things you have walked past for years.

The ten-point observation sequence

1. Purpose. What is this screen for, in one sentence? Whose goal? If you cannot tell, that is the first finding.
2. First glance. Look for two seconds, look away. What did you see first, second, third? Is that the order the purpose needs?
3. Hierarchy. How many levels of importance are there? How is each level marked (size, weight, color, position)?
4. Grid and alignment. Trace the shared edges. Count how many different left edges there are. Fewer is calmer.
5. Spacing and grouping. Which things look related? Is it because they are near each other, or boxed together, or similar? Are spacing values repeated?
6. Type. How many families, sizes and weights? What does each one mean?
7. Color and contrast. What does each color mean? Is the accent reserved for one meaning? Is text contrast sufficient?
8. Actions and signifiers. What can you do here? What is the primary action? Can you tell what is clickable without hovering?
9. Words. Read every label. Are they verbs for actions, nouns for things? Do they use the user's language?
10. States and edges. Imagine it empty, loading, offline, with 10,000 items, with a 120-character title. Which states have been designed?

Self-critique tricks that create distance

You cannot see your own work fresh, because you know what it is supposed to be. Painters have long used tricks to break that familiarity, such as looking at a canvas in a mirror. Screen equivalents:

Keeping a swipe file

A swipe file is a collection of examples you have found good (or instructively bad), with notes on why. Copywriters have kept them for a century; designers keep them as screenshots. The collection is not the point; the notes are. A screenshot without a note is a souvenir. A screenshot with "empty state teaches the main gesture in one line, uses the same illustration style as onboarding" is a lesson.

A simple system: one folder (or a tool such as Eagle, Are.na or a notes app), file names in the form pattern--product--detail, and a one-sentence note per item naming the mechanism. Patterns to collect first: empty states, onboarding, settings, errors, confirmations and undo, search, lists, paywalls, and any screen that made you feel calm. Reference libraries of app screens, such as Mobbin, are useful for breadth, but your own annotated file is what trains your eye.

The language of critique

Critique is analysis against objectives. In Discussing Design (2015), Adam Connor and Aaron Irizarry distinguish critique from both praise and judgment, and propose a simple structure of questions:

1. What is the objective of this design (for this screen, for this user, right now)?
2. Which elements of the design relate to that objective?
3. Are those elements effective at achieving it?
4. Why, or why not?

This structure works for self-critique too, and it changes the tone of the conversation you have with yourself. "This is ugly" becomes "The objective is to start reading quickly; the large header pushes the first article below the fold; that delays the main job". The second version contains its own fix.

In the wild

• Mobbinscreen reference library
  A large, searchable library of screenshots and flows from real apps, organized by pattern. Good for breadth when you face a pattern you have not designed before.
• Pixar's Braintrustdescribed in Ed Catmull's Creativity, Inc., 2014
  A group of experienced filmmakers who give candid notes on films in progress, with the director free to accept or reject them. Critique focused on the work's goals, not on the person, makes it better.
• Design teardownsmany writers and newsletters
  Long-form breakdowns of a single product's onboarding or pricing page. Guides 18 to 20 of this course are teardowns. Reading others' structured looking teaches you to do it.

Taste is trained judgment: the ability to tell whether a design fits its purpose, and why. It is built by looking closely at a lot of good work, making a lot of your own, and comparing the two honestly. For years your taste will run ahead of your skill. That gap is normal, and the only way through it is volume.

What taste is, and what it is not

Taste is often treated as a mysterious gift or as mere preference. It is neither. Paul Graham's essay "Taste for Makers" (2002) argues that there really is good and bad taste in making things, and lists qualities that good designs tend to share: they are simple, timeless, solve the right problem, look easy, and are often redesigns of something earlier. You can disagree with his list and still accept the main point: taste can be wrong, which means it can improve.

The practical distinction is between preference (what you like) and judgment (what works for this purpose and these people). Good designers hold both and know which they are using. You may personally love dense, dark, information-heavy interfaces, and still recognize that a meditation app should not look like that.

The gap

In a widely shared 2009 video interview about storytelling, the radio host Ira Glass described something every creative beginner meets. Paraphrased: people get into creative work because they have good taste. For the first few years, what they make is not as good as their taste tells them it should be, and they can see it. Many quit at this point. His advice was to do a large volume of work, on deadlines, because only volume closes the gap between your taste and your ability.

Copying as learning

Copying is how most crafts have always been taught. Art students copy paintings in museums. Musicians transcribe solos. Benjamin Franklin, in his Autobiography, describes teaching himself to write by taking notes on essays from The Spectator, setting them aside for a few days, rewriting the essays from his notes, and then comparing his version with the original to find his faults. That is a precise method, and it transfers directly to interface design:

1. Choose a master screen. A screen from a product widely respected for craft, in a domain close to yours.
2. Study it with the ten-point sequence (chapter 16) and write notes on every decision you can see.
3. Wait a day, then rebuild it from your notes, in code or your design tool, without looking at the original.
4. Compare, side by side or overlaid. Every difference is a lesson: spacing you guessed wrong, a weight you missed, a state you did not notice.
5. Apply one lesson to your own product. Copy the reasoning, not the pixels.

This is a private exercise for learning, not a way to ship someone else's design. The point is to feel the decisions from the inside. Copy to learn; never ship a copy as your own work.

Studying masters

Choose a small "faculty" of masters and study them over months, not a huge list skimmed once. A balanced faculty for a calm, reader-first software creator might be: one industrial designer (Rams, Fukasawa), one typographer or graphic designer (Vignelli, or the designers behind a well-made typeface), two or three software products known for craft in your domain, and one writer on design (Norman, Victor). Guides 18, 19 and 20 are structured studies of exactly these.

For each master, ask the same three questions: What problem were they solving? What did they refuse to do? What would they remove from my product? The third question is the useful one.

In the wild

• Daily UI challengesvarious, 2010s onward
  Many designers built their early skill with daily design exercises (one screen a day for 100 days). Volume, on a deadline, as Glass recommends. Best when each piece gets a written self-critique.
• Apple and Braun2000s onward
  Jony Ive has spoken publicly of his admiration for Rams' work, and the influence is often discussed. Masters study masters. The lineage is the curriculum.
• Your own product's historyyou, starting now
  The weekly redesign folder from the warm-up becomes a record of your taste and skill converging. Seeing your own progress is the best antidote to the gap.

Wrap-up

You now have the foundation: a definition of the job, a model of the layers, Norman's vocabulary for why people struggle, Rams' qualities to aim for, a shelf of frameworks, a process small enough for one person, and a way of seeing. The other twenty guides build on all of it.

Practice assignment for the next two weeks

About 30 to 60 minutes a day. Keep everything in one folder called foundations.

1. Days 1 to 2: Exercise 2.1 (your product on five planes) and start decisions.md.
2. Days 3 to 4: Exercises 4.1 and 5.1: hunt Norman doors, run a constraint pass. Ship two fixes.
3. Day 5: Exercise 6.1: four states for your key action, five-sentence model, word list.
4. Day 6: Exercise 8.1: error audit. Replace one confirmation with undo.
5. Day 7: Rest from making. Do the part recap quizzes again from memory and run the Foundations audit checklist (chapter 16).
6. Days 8 to 12: Exercise 12.1: one full solo week on one real problem, using the fidelity ladder (13.1) inside it.
7. Day 13: Exercise 9.1: the ten-principle audit, and Exercise 14.1: trade-off and craft map.
8. Day 14: Exercise 17.1 on one master screen. Then write a one-page reflection: what changed in your product, what changed in how you see, and the three habits you will keep.
9. Every day: one swipe-file item with a note and one ten-point pass (Exercise 16.1), and ten vocabulary flashcards (15.1).

Reading list

• The Design of Everyday Things (revised and expanded edition)
  Don Norman, 2013 · The source for Part two. Read the chapters on the psychology of everyday actions and on human error twice.
• The Elements of User Experience (2nd edition)
  Jesse James Garrett, 2010 · Short, and the clearest map of the five planes, with the full diagram.
• Less but Better
  Dieter Rams, 1995 · Rams in his own words, with his principles and many Braun products. Pair with Gary Hustwit's documentary Rams (2018).
• The Humane Interface
  Jef Raskin, 2000 · Modes, attention and habituation, argued with rigor. Some technical sections can be skimmed.
• Magic Ink: Information Software and the Graphical Interface
  Bret Victor, 2006 (free essay on worrydream.com) · The case that most software should show, not ask. Will change how you design forms.
• About Face: The Essentials of Interaction Design
  Alan Cooper and co-authors, 4th edition 2014 · Goal-directed design, personas done properly, and a huge catalogue of interaction patterns.
• Sketching User Experiences
  Bill Buxton, 2007 · Why sketching is different from prototyping, and why designers need many cheap options.
• Shape Up
  Ryan Singer, 2019 (free online at basecamp.com/shapeup) · Appetites, shaping and fixed-time cycles. Written for small teams; ideal for one person.
• Discussing Design
  Adam Connor and Aaron Irizarry, 2015 · The critique structure from chapter 16, and how to make feedback useful.
• Designing for Emotion
  Aarron Walter, 2011 (2nd ed. 2020) · The hierarchy of user needs and how personality grows on reliability.
• Don't Make Me Think, Revisited
  Steve Krug, 2014 · Short, funny and practical usability; a good companion to Nielsen's heuristics.
• "10 Usability Heuristics for User Interface Design" and "First Principles of Interaction Design"
  Jakob Nielsen (Nielsen Norman Group) and Bruce Tognazzini (asktog.com) · The two checklists from chapter 10 in their authors' own words, free online.
• "Taste for Makers"
  Paul Graham, 2002 (paulgraham.com) · A short essay arguing that taste is real and can be good or bad, with a list of qualities of good design.
• The Sciences of the Artificial
  Herbert Simon, 1969 · Dense, but the origin of the broad definition of design as changing existing situations into preferred ones. Read the chapter on design.

Next: The Human Mind, where you will learn why the ideas in this guide work, from perception and attention to memory and motivation.