Structure & Interaction. How a product is arranged, and how it answers back.

Warm-up: what you already know

You have used thousands of apps. You already have strong instincts about structure and interaction; you just may not have names for them. Answer these four questions quickly, without scrolling ahead. Getting them wrong is fine and useful: it tells you which chapters to read slowly.

Hold one idea from The Human Mind in your head while you read: people act on a mental model, a small private story about how the thing works. Every chapter in this guide is a way of making the product's real structure match that story, and of making the product answer clearly when the story is wrong.

People think in things before they think in actions. Design the nouns of your product first, then attach the verbs to them, and the interface becomes a set of places people recognise instead of a list of functions they must remember.

Ask someone what a calendar app is for and they will talk about events, people and days. Ask what a notes app is for and they say notes, folders, tags. Those nouns are the person's mental model. The actions (create, share, move, archive) only make sense attached to one of them. When a product is organised around actions instead, you get screens like "Manage", "Tools" and "Actions", and people have to translate their goal ("I want to change Tuesday's meeting") into the product's vocabulary ("Event management, then Edit"). Every translation is a small tax on attention.

This idea is old. The Xerox Star (1981) let you select an object on screen, a document or a folder, and then apply a generic command to it: Move, Copy, Delete, Show Properties. Noun, then verb. Today the approach has a name and a method: object-oriented UX (OOUX), developed and taught by Sophia Prater. Her process, called ORCA, walks through four layers in order: Objects, Relationships, Calls to action, Attributes.

The ORCA pass, step by step

1. Objects. Read your notes, support emails and your own product description, and underline every noun people care about. Keep the ones that have their own identity, that a person would want to see, find or talk about. "Book", "highlight", "collection" pass. "Settings" and "dashboard" are not objects; they are containers.
2. Relationships. For each pair, ask how they connect and how many: a book has many highlights; a highlight belongs to one book; a collection contains many books, and a book can be in many collections. These lines become your navigation and your links.
3. Calls to action. List what people do to each object: create, edit, share, archive, export. Verbs live on objects, which tells you where every button goes.
4. Attributes. List what each object is made of: title, author, date added, progress. These become the fields in your forms, the columns in your lists and the options for sort and filter.

Nouns become screens, verbs become controls

Once the map exists, a predictable shape appears. Each important object usually gets two views: a collection view (a list or grid of many) and a detail view (one of them, with its attributes and actions). Relationships become links between detail views: a book's page lists its highlights, a highlight links back to its book. Actions appear where the object is, as buttons on the detail view or items in a context menu on the list row. This is why well-structured products feel "obvious": every screen answers "which thing am I looking at, and what can I do to it?"

Naming objects: one word, used everywhere

The object map also fixes your vocabulary. If the object is a "collection", it is a collection in the sidebar, the button ("New collection"), the empty state, the URL (/collections/42), the API and the support docs. Products drift when the code says "list", the UI says "shelf" and the help page says "folder". People assume different words mean different things. Keep a one-page glossary of your objects and treat it as part of the design (more on words in Words).

In the wild

• Xerox StarXerox, 1981
  Select an icon (document, folder, printer), then press a generic key such as Move, Copy or Delete. A handful of verbs worked on every noun. Few universal verbs plus many objects is easier to learn than many special commands.
• LinearLinear, 2019 onward
  The core objects are issues, projects, cycles and teams, and they show up consistently in the sidebar, the URL and the command menu. Actions such as assign or change status work on whichever issue is selected. A small, stable object model lets power features (shortcuts, bulk edits) stay simple.
• Things 3Cultured Code, 2017
  Areas contain projects, projects contain to-dos, to-dos contain checklists. That containment hierarchy is visible in the sidebar and in each project's page. When the relationships are simple and visible, people rarely need a manual.
• Apple PhotosApple, 2015 onward
  Photos, albums, people and places are all objects; a photo can be in many albums and contain many people. You can arrive at the same photo from any of these directions. Many-to-many relationships become multiple paths to the same thing.

Information architecture is deciding how things are grouped, what the groups are called, and how deep they go. Good IA matches the groupings already in your users' heads, so they guess right the first time.

Rosenfeld and Morville's book Information Architecture for the World Wide Web (first edition 1998, nicknamed "the polar bear book") split the field into a few systems: organisation (how you group), labelling (what you call groups), navigation (how people move), and search (how people look things up). Abby Covert's How to Make Sense of Any Mess (2014) made the same ideas approachable: every mess is made of information, and the work is to agree on what things mean before arranging them.

The mechanism behind all of it is information scent, a term from Peter Pirolli and Stuart Card's information foraging theory at Xerox PARC in the 1990s. People choose links the way animals follow a scent trail: they pick the label that seems most likely to lead to their goal. If the scent is strong at every step, they move fast and confidently. If it is weak (vague labels, unexpected groups), they hesitate, guess, backtrack, and eventually leave.

Ways to organise

There are only a few basic schemes, and mixing them in one list is the most common source of confusion.

Alphabetical, chronological and geographical are exact schemes: there is one right answer for where something goes. Topic, task and audience are ambiguous: reasonable people disagree. Ambiguous schemes are more useful for browsing but need testing, which is what card sorting and tree testing are for.

Depth versus breadth

Every hierarchy trades depth (how many levels) against breadth (how many items per level). Deep and narrow means few choices per screen but many clicks, and each click is another chance to take a wrong turn. Broad and shallow means more scanning per screen but fewer decisions. Studies of menu structures from the 1980s and 1990s (Kiger in 1984, Larson and Czerwinski in 1998) generally found that broader, shallower structures beat deep ones, as long as the broad lists are well grouped and labelled. The reason is compounding: if people choose correctly 90% of the time at each level, three levels give 0.9 × 0.9 × 0.9 ≈ 73% success, and five levels give about 59%.

Card sorting and tree testing, solo

Card sorting asks people to group your content. Write each item on a card (real or virtual), hand them to someone, and ask them to sort into piles that make sense and name each pile. In an open sort they invent groups; in a closed sort they use yours. Donna Spencer's Card Sorting (2009) is the standard short guide. Five to fifteen people usually show the main patterns. Watch for items everyone places the same way (safe) and items that wander between piles (they need a better label, or should live in two places).

Tree testing is the reverse check. Give people only the text hierarchy, no visual design, and a task ("Where would you change your billing email?"). Record the path they click. The classic tool is Optimal Workshop's Treejack, but a spreadsheet and a video call work. It isolates the IA from the visuals: if people fail on a plain text tree, colour and icons will not save it.

Labels carry the scent

Labels should be specific, familiar and parallel. Specific: "Invoices" beats "Documents". Familiar: use the words your users use in support emails, not your internal jargon. Parallel: items in one list should be the same kind of word (all nouns, or all verbs), so people can compare them. Clever labels ("The Vault", "Magic Box") feel like personality but have zero scent: nobody can predict what is inside.

Taxonomies: folders, tags and both

A folder (hierarchy) says "this thing is in exactly one place". A tag (facet) says "this thing has these properties". Folders are easy to understand and match physical habits; tags are flexible but need discipline and good tools. Most mature products offer one primary hierarchy plus a few facets: Gmail moved from folders to labels in 2004, which let one email live in many places. Things uses areas and projects as hierarchy, and tags as optional facets. For your own product, pick one primary structure and make the second optional; asking people to maintain both from day one is asking them to be librarians.

In the wild

• Gmail labelsGoogle, 2004
  Replaced the single-folder model with labels, so one conversation could be in "Travel" and "Receipts" at once, with search as the main way back. When items belong to several groups, facets beat folders.
• macOS System SettingsApple, 2022 (Ventura)
  Moved from a grid of icons to an iOS-style sidebar list. Many long-time Mac users reported trouble finding familiar panes in the new grouping. Reorganising changes what people already know; even a "better" structure has a relearning cost.
• GOV.UKGovernment Digital Service, 2012
  Merged hundreds of department websites into one site organised around what citizens need to do, not which department does it. Organise by the user's task, not by your org chart.

Navigation is a map you can touch. Choose a pattern by counting your destinations and how often people switch between them; the best navigation is the one that keeps the most-used places visible and the rest one predictable step away.

There are only about eight navigation patterns in common use, and each one fits a particular shape of product. The questions that pick between them are simple: How many top-level destinations are there? Are they peers (people switch between them often) or a hierarchy (people go in, then come back)? Is the product used on a phone, a desktop, or both? Do people know the name of what they want (search) or do they browse?

The cost of the hamburger

The hamburger icon (three lines) was drawn by Norm Cox for the Xerox Star around 1981 and became the default mobile menu in the early 2010s. It is tidy. The trouble is psychological, not visual: what people cannot see, they forget exists. Nielsen Norman Group's 2016 testing found that hidden navigation was used less often than visible navigation and made content harder to discover, on both desktop and mobile. Several large apps moved their main sections out of drawers and into bottom tab bars in the mid-2010s for the same reason. The rule of thumb: if a destination matters to most people every week, it must be visible. Put the rest (settings, help, account, legal) in a drawer or a "You" tab.

Command palettes and search as accelerators

A command palette (press a shortcut, type a few letters, pick a result) gives fast access to every place and action without crowding the screen. Sublime Text popularised it for editors, VS Code made Ctrl/⌘ Shift P famous, and web apps such as Superhuman, Linear and GitHub brought ⌘ K to everyday software. Chapter 12 builds one. The rule: a palette is an accelerator layered over visible navigation, never a replacement for it. Newcomers learn by seeing; experts speed up by typing.

In the wild

• SlackSlack, 2013 onward
  A sidebar of user-created channels and DMs on desktop, plus a quick switcher (⌘ K) to jump by typing. Sidebars scale to places that users create; a switcher makes hundreds of them fast to reach.
• Apple Settings (iOS)Apple, 2007 onward
  A drill-down stack: a long grouped list, tap into a section, tap again, back button shows the previous screen's name. Search was added at the top later. Drill-down suits hierarchies people enter and leave; search rescues depth.
• Google MapsGoogle
  Search-first: the search box is the main control, and browsing is secondary. When people almost always know the name of what they want, start with search.
• InstagramMeta
  A bottom tab bar for the main places, with a profile tab that holds settings and less-used destinations. The "You" tab is a good home for everything that is not daily.

At every moment a person should be able to answer three questions without thinking: where am I, where can I go from here, and how do I get back. Navigation is the system; wayfinding is the experience of never feeling lost in it.

The urban planner Kevin Lynch's The Image of the City (1960) described how people find their way through cities using paths, edges, districts, nodes and landmarks. Software has the same needs. The page title is your street sign. The highlighted nav item is the district. Breadcrumbs are the path you could retrace. A consistent header is the landmark you can always see.

Steve Krug's Don't Make Me Think (2000) turned this into a quick test he called the trunk test: imagine you were blindfolded, driven around, and dropped on a random page of the site. Can you immediately say what site this is, what page you are on, what the major sections are, what your options at this level are, where you are in the scheme of things, and how you can search? Try it on your own product with a screenshot of a deep page.

Breadcrumbs

Breadcrumbs show the location of the current page in a hierarchy, with every ancestor as a link. They are cheap and help most when people land deep in a site from search or a shared link. Show the hierarchy, not the browsing history (that is what the back button is for). Keep them small and above the title. On phones, show only the parent as a single "‹ Philosophy" link, because a full trail wraps and crowds the screen.

Back must mean back

The back button is the most used navigation control on the web, and people build a strong expectation around it: back returns me to exactly where I was, scroll position included. Single-page web apps often break this by changing the content without changing the URL, so back leaves the app entirely; or by pushing every filter tweak into history, so back has to be pressed ten times. On iOS, the back button in a navigation stack names the previous screen, and the edge swipe pops the stack. On Android, the system back gesture is global. Your job is to make your app's internal history match what people expect from those gestures.

URLs are part of the interface

Tim Berners-Lee's 1998 note "Cool URIs don't change" argued that addresses should be stable for years. A good URL is readable, hackable (you can delete the end and land somewhere sensible), shareable and permanent. It is also your deep-link system: if every meaningful state of the app has a URL, people can bookmark it, share it, open it in a new tab, and come back to it from a notification. Apps without addresses for their states force people to describe how to get somewhere ("click Projects, then the second one, then the Files tab").

In the wild

• GitHubGitHub
  URLs read like sentences: owner, repository, then "pull" or "issues" and a number. People type and edit them by hand. Predictable URLs become a power-user navigation system for free.
• iOS navigation barApple, 2007 onward
  The back button shows the title of the previous screen, and the large title shrinks as you scroll so the place name stays visible. "Back" is vague; "‹ Library" is wayfinding.
• FigmaFigma
  Copying a link to a selected frame produces a URL that opens the file zoomed to that frame. Deep links to the exact state make collaboration and support much easier.

A screen is a frame; a flow is the film. Draw the path a person takes to finish a task, decision by decision, and you will find the missing screens, the dead ends and the edge cases before you write code.

Designers often start with the beautiful screen in the middle of a task. People do not experience screens; they experience sequences: they arrive from somewhere, with some expectation, make a few decisions, hit a snag, and either finish or give up. A user flow (sometimes called a task flow) is a diagram of that sequence. It is the cheapest design artefact there is, and it catches more problems per minute than any mockup.

A tiny notation

You do not need a formal standard. Four shapes are enough, and keeping them consistent makes flows readable months later.

Happy path, then edge cases

Draw the happy path first: the shortest route when everything goes right. Then walk it again and at every step ask a fixed set of questions. This list catches most edge cases:

• Nothing: what if there is no data yet, or the search returns nothing?
• Too much: what if there are 10,000 items, or the name is 200 characters long?
• Wrong: what if the input is invalid, or the file is the wrong type?
• Slow or gone: what if the network is slow, offline, or the server errors?
• Denied: what if a permission is refused or the plan does not include this?
• Interrupted: what if they leave halfway, get a call, or close the tab?
• Duplicate or conflict: what if it already exists, or changed on another device?

Each answer is either a screen state (chapter 6), a message (see Words), or a design decision to remove the edge case entirely. The best edge-case handling is the edge case that cannot happen: if duplicates are a problem, detect them and offer to open the existing one rather than showing an error.

The golden path

Among all flows, one matters most: the sequence from first launch to the first moment the product delivers its core value. Call it the golden path. Kathy Sierra, in Badass: Making Users Awesome (2015), argued that people stay with products that make them feel capable quickly. For a note app, the golden path ends at the first note saved. For a reading app, at the first highlight. Count the steps and seconds on that path, and treat every step as a cost to justify. Sign-up, onboarding tours and permission requests that sit in front of value are the usual offenders. Can someone try the core action before creating an account?

Screen inventory

Once flows exist, list every screen they touch in a table, with a column per state (chapter 6). This screen inventory is your real scope. It turns "build sign-up" into "build 4 screens × 5 states, 14 of which are not designed yet". For a solo creator, it is the most honest estimate you will ever make.

In the wild

• DuolingoDuolingo
  New users can start a first lesson before creating an account; sign-up is offered after some progress exists. Let people feel the value, then ask them to save it.
• ExcalidrawExcalidraw, 2020
  Opening the site drops you straight onto a canvas; there is nothing to set up before drawing. The shortest golden path is zero steps.
• Stripe CheckoutStripe
  The payment flow handles many edge cases (card declined, 3-D Secure verification, wallets) inside one consistent flow, so the merchant's happy path stays simple. Edge cases are where trust is won, especially around money.

Recap and connect: Part one

Structure flows from objects (chapter 1) to groups and labels (2), to navigation patterns (3), to the experience of moving through them (4), to the paths people take for a task (5). Each layer constrains the next. Before moving on, connect these ideas with earlier guides.

Every screen that shows data has at least five states: blank, loading, partial, error and ideal. Most products design only the ideal one, so people meet the other four as raw, confusing defaults.

In a 2015 essay, designer Scott Hurff named this the UI stack: for any screen, stack up its blank state (nothing here yet), loading state (waiting for data), partial state (some data, not enough to feel complete), error state (something went wrong), and ideal state (the screenshot on your marketing page). The insight is that people spend a surprising share of their time in the non-ideal states, especially new users (blank and partial) and mobile users (loading and offline). Those states are where trust is built or lost.

Blank states are onboarding

An empty screen is the most valuable real estate a new user sees, because it is the first place they will act. A good blank state does three things: says what this place is for, shows what it will look like when full (a faint preview or sample), and offers the one action that fills it. Distinguish three kinds of empty: first use (nothing created yet: invite and teach), user cleared (inbox zero: reward, do not nag), and no results (search or filter found nothing: show what was searched and how to widen it).

Loading: show shape, not just motion

Robert Miller's 1968 research, later popularised by Jakob Nielsen, gave three useful limits: about 0.1 second feels instant, about 1 second keeps the flow of thought, and about 10 seconds is the limit of attention. Under roughly a second, show nothing (a flashing spinner is worse than a short pause). Between one and ten seconds, show a skeleton: grey blocks in the shape of the coming content, an approach Luke Wroblewski wrote about in 2013 under the advice "avoid the spinner". Skeletons tell people what is coming and make the page feel as if it is arriving piece by piece. Beyond ten seconds, show real progress (a determinate bar, steps, a count) and let people do something else.

Errors: say what happened, what is safe, what to do

A useful error state answers three questions in plain words: what happened, is my work safe, and what can I do now. "Something went wrong" answers none. "Couldn't sync. Your notes are saved on this device. Retry" answers all three. Keep the rest of the screen usable: show cached content with a small banner instead of replacing the whole screen with an error. For writing the words, see Words.

Offline is a state, not a crash

Phones lose signal in lifts, trains and basements every day. Decide for each screen what works offline: read cached data, create items that sync later, or nothing. Show a quiet, persistent indicator ("Offline. Changes will sync."), keep the UI usable, and mark unsynced items subtly. Apps built "local-first" store data on the device and treat the server as a sync partner, which makes offline the normal case instead of an error.

In the wild

• Things 3Cultured Code, 2017
  Empty lists show a quiet illustration and short text rather than a blank page; completing everything in Today feels like a small reward. "User cleared" empty is a moment to celebrate quietly, not to upsell.
• Facebook and LinkedIn feeds2010s onward
  Grey placeholder blocks in the shape of posts appear while content loads, a technique widely copied. Skeletons set expectations about layout before data arrives.
• Figma, Linear, Notion2020s
  Edits appear instantly and sync in the background, with an indicator only when something fails. Optimistic UI makes networked software feel local, as long as failure is handled clearly.

Each control is a promise about how a choice works: how many options, how many can be picked, and when the choice takes effect. Choose the control whose promise matches the choice, and people will use it correctly without reading anything.

Controls are a vocabulary that everyone already learned from thousands of other apps. A round radio button says "pick exactly one of these". A square checkbox says "pick any". A switch says "this takes effect now, like a light". A dropdown says "there are more options than I want to show". Using the wrong one is like using the wrong word in a sentence: people understand the literal meaning and make the wrong move.

Toggles mean now

A switch borrows from physical light switches: flip it and the light changes. Nielsen Norman Group's guidance on toggle switches makes the same point: use them for settings that take effect immediately. If the setting only applies after a Save button, use a checkbox, because a switch that does nothing until Save makes people wonder whether it worked. Label switches with the thing being controlled ("Sync over cellular"), not a question, and never with a label that changes when flipped ("Turn on" / "Turn off"), which makes the state ambiguous.

Button hierarchy

Most screens have one action that matters most. Give it the strongest visual weight (the primary button: filled, high contrast). Give alternatives a quieter style (secondary: outlined or tinted). Give low-stakes or escape actions the quietest (tertiary: text only). One primary per view is a good rule; two primaries mean you have not decided what the screen is for. Destructive actions get a warning colour (red), but not the primary weight, unless the whole purpose of the dialog is to destroy (then the red button is the primary).

Placement conventions per platform

Where the primary button goes is a convention, and conventions differ. Follow the platform, because people's hands move before their eyes read.

Links versus buttons

A link goes somewhere; a button does something. Links change the URL, can open in a new tab and are announced as links by screen readers. Buttons submit, toggle, open menus or change data. Styling a link to look like a button is fine for a navigation call to action ("Start free trial" going to a sign-up page); making a <div> behave like either is not, because it loses keyboard and assistive-technology behaviour (see Accessible & Inclusive).

Pickers and dates

Match the date control to how people think about the date. For a known date far away (a birth date, a passport expiry), let people type it: the GOV.UK Design System uses three separate text boxes for day, month and year, because scrolling a calendar back 35 years is tedious. For a near date relative to today (a booking, a due date), a calendar helps because people think in weekdays ("next Friday"). For natural language, apps such as Fantastical and Things parse "tomorrow 3pm" or "next week". For sliders, add a number field next to them when exact values matter, because sliders are imprecise for fingers.

In the wild

• iOS SettingsApple
  Switches change things immediately (Wi-Fi, Bluetooth), with no Save button anywhere in Settings. A whole app can use the immediate-effect model consistently.
• GOV.UK Design SystemGovernment Digital Service
  Publishes researched patterns for date input, radios, checkboxes and more, with notes on when not to use each. A free, evidence-based reference for form controls.
• FantasticalFlexibits, 2011 onward
  Creating an event by typing a sentence such as "Lunch with Asha Friday 1pm" fills in all the fields. The best picker can be no picker, when language is faster.

A form is a conversation in which you ask for something. Ask for less, ask clearly, accept answers in the form people give them, and tell them about problems at the right moment and in the right place.

Forms are where products make money and lose people: sign-up, checkout, onboarding, settings. Luke Wroblewski's Web Form Design: Filling in the Blanks (2008) and Caroline Jarrett and Gerry Gaffney's Forms that Work (2008) are still the best short books on the subject. Their shared message: most form problems are not visual. They come from asking unnecessary questions, in an order that makes no sense, with rules the person cannot see until they break them.

Layout: one column, labels on top

A single column gives the eye one straight path: top to bottom, no zig-zag, no wondering whether the field on the right comes before or after the one below. Multi-column forms cause people to skip fields. Labels above fields are fastest to scan, work at any screen width, and handle long translations. Matteo Penzo's 2006 eye-tracking study, reported on UXmatters, found top-aligned labels needed the fewest fixations. Placeholder text as the only label is the worst option: it disappears as soon as someone types, so they cannot check what the field was for, and its pale grey usually fails contrast.

Validation timing: the most common form bug

When should a form tell someone they made a mistake? Too late (only after Submit, with all errors at the top) and people must hunt for the problem. Too early (on every keystroke from the first letter) and the form scolds people for being in the middle of typing: "Invalid email" appears while they are still typing "rohit@". The pattern that works best for most fields:

1. Stay quiet while the person types a field for the first time.
2. Validate when they leave the field (on blur). Show the message right under the field.
3. Once an error is showing, re-check on every keystroke, so the error disappears the instant it is fixed. Reward is fast; punishment is patient.
4. On submit, validate everything, move focus to the first error, and (for long forms) show a summary at the top that links to each error.

A 2009 study by Luke Wroblewski with the usability firm Etre compared inline validation to submit-only validation and found higher success rates and much faster completion with inline validation, especially when messages appeared after people finished a field rather than while they were typing. Exceptions where live feedback while typing is right: password strength meters, character counters and username availability, because there the feedback helps people compose the answer.

Where error messages go

Put the message directly below the field it is about, start it with what to do ("Enter an email like name@example.com"), and mark the field with more than colour (an icon or thicker border) so it is visible to colour-blind people. Keep the person's input; never clear a field because it was wrong. For a form longer than one screen, add an error summary at the top after submit, with links that jump to each field: that is the GOV.UK pattern and it works well with screen readers.

Required, optional, and asking less

If most fields are required, mark the few optional ones with "(optional)" in the label, as GOV.UK recommends; a sea of red asterisks is noise. Better still, question every optional field: why ask at all? Each field has a cost in time and in trust. A phone number "for account security" on a reading app makes people wonder what you will do with it.

Accept input the way people give it

Input masks that force a format while typing (brackets and dashes appearing in a phone field) often fight paste, autofill and international numbers. A gentler approach: let people type freely, strip spaces and punctuation, and display a tidy format after they leave the field. Exception: card numbers, where grouping digits in fours while typing helps people check them. Smart defaults remove work: preselect the country from the device locale, the currency from the country, today for a date. Autofill is the cheapest speed-up there is: use the correct autocomplete values (email, name, street-address, one-time-code) and the right input types, so phones show the right keyboard and offer saved details.

Passwords

The US National Institute of Standards and Technology's digital identity guidelines (SP 800-63B, 2017) recommend against composition rules (one uppercase, one symbol) and forced periodic changes, and in favour of a minimum length, checking against lists of breached passwords, allowing paste (so password managers work), and offering a way to show the password. Those recommendations are good design too: show the length rule before people type, let them see what they typed, and never block paste. Better still, consider passkeys or email sign-in links.

Multi-step and long forms

Split a long form into steps when the steps match a natural grouping (shipping, then payment, then review) or when later questions depend on earlier answers. Show progress honestly ("Step 2 of 3", not a bar that jumps), let people go back without losing data, save progress automatically, and end with a review step for anything costly. GOV.UK's "one thing per page" pattern goes further: each page asks one question, which works very well on phones and for complex, branching forms.

In the wild

• Stripe ElementsStripe
  The card field detects the card brand from the first digits, groups numbers, and moves to the expiry field automatically when the number is complete. Small anticipations add up to a form that feels like it is helping.
• iOS one-time codesApple, iOS 12 (2018)
  Fields marked as one-time-code offer the code from an incoming SMS above the keyboard. One attribute in your markup can remove a whole app switch.
• GOV.UKGovernment Digital Service
  "One thing per page" forms and the error summary pattern, both documented with research notes. Simple, plain forms serve everyone, including people under stress.

People will make mistakes; that is not a user problem but a design input. Prevent the errors you can, make the rest cheap to reverse, and save warnings for the few actions that truly cannot be undone.

Don Norman distinguishes slips (you meant to do the right thing but your hand did something else: clicked the wrong row) from mistakes (you formed the wrong goal: you thought "Archive" meant delete). Slips happen most to experts working fast; mistakes happen to people whose mental model is wrong (see The Human Mind). The defences differ. Slips are stopped by constraints, spacing and undo. Mistakes are stopped by clear labels, previews and visible consequences.

Prevention: constraints and poka-yoke

The Japanese engineer Shigeo Shingo popularised poka-yoke ("mistake-proofing") at Toyota: design the part so it can only fit one way. In software: a date picker cannot produce February 30; a "Send" button is disabled until there is a recipient (with a hint that says why); a file type filter only shows files you can open; dangerous actions are placed away from frequent ones. When you disable something, explain why near it, otherwise people think the product is broken.

Undo beats "Are you sure?"

Confirmation dialogs fail for a simple reason: habituation. After the third "Are you sure?" that did not matter, people click "Yes" before reading, so the dialog protects nothing on the one day it matters. Aza Raskin made this case in his 2007 A List Apart essay "Never Use a Warning When You Mean Undo". Undo works with habits instead of against them: people act at full speed, and the rare slip costs one click. Gmail's "Undo send" (a short delay before the message really goes) is the famous example. Feel the difference yourself below.

Layers of reversibility

Undo is not one feature but a set of safety nets at different time scales. Immediate undo (a toast with Undo, or ⌘ Z) covers seconds. A trash or archive covers days: Google Drive and many other services keep deleted files in trash for 30 days. Version history covers weeks or forever: Google Docs keeps a full revision history, and macOS added Auto Save and Versions in OS X Lion (2011). Autosave removes the oldest disaster in computing, losing work you forgot to save. Together they let people experiment, which Shneiderman lists among his "eight golden rules" as "permit easy reversal of actions".

When you must warn: make it specific and effortful

Some actions really are irreversible: deleting an account, permanently emptying trash, deleting a repository, sending money. For these, a generic "Are you sure?" is too easy to dismiss. Name the consequence precisely ("This permanently deletes 'Thesis' and its 214 notes. This cannot be undone."), make the button label the action ("Delete 214 notes", not "OK"), and for catastrophic cases ask for deliberate effort. GitHub asks you to type the repository's name before deleting it. The typing is not a password; it is a speed bump that forces you to read.

In the wild

• Gmail Undo SendGoogle, Labs 2009, standard 2015
  After sending, a toast offers Undo for a few seconds (adjustable in settings) while the message is held back. A small delay turns an irreversible act into a reversible one.
• GitHub repository deletionGitHub
  Deleting a repository requires typing its name. Effort proportional to consequence.
• Google DocsGoogle
  No Save button; changes save continuously and Version history lets you restore any earlier state. When everything is saved and versioned, "Save changes?" disappears from the product.
• macOS TrashApple
  Deleting a file moves it to Trash, and Put Back restores it to its original folder. The best delete is a move.

A mode is any state in which the same action does something different. Modes cause errors because people forget which one they are in. Avoid them where you can, make them loud where you cannot, and choose the lightest overlay that does the job.

Larry Tesler spent much of his career at Xerox PARC and Apple campaigning against modes; his car's licence plate famously read NOMODES. In the 1970s he and Tim Mott built Gypsy, an early modeless text editor at PARC, where you could simply click and type rather than first entering an "insert mode". Jef Raskin, who started the Macintosh project, wrote in The Humane Interface (2000) that modes are a major source of errors, because a habit formed in one mode fires in the other. Caps Lock is the everyday example: you type a password with Caps Lock on and it fails, because the keyboard was in a mode you did not notice.

Raskin's alternative is the quasimode: a mode that lasts only while you physically hold it, like the Shift key. Your body keeps track of the mode, so you cannot forget it. Holding Space to pan in Figma or Photoshop is a quasimode; pressing a tool key that stays on until you change it is a full mode.

When modes are worth it

Some modes earn their place: an editor's "focus mode", a drawing app's pen tool, a camera's video mode. Make them safe with three rules. Make the mode visible where the person is looking (a coloured border, a changed cursor, a persistent label). Make it easy to exit with the same control that entered it, plus Esc. Keep it short-lived where possible, or revert automatically when the task ends.

Modals: the interruptions

A modal dialog is a mode: while it is open, the rest of the app does not respond. That is its power (it forces a decision) and its cost (it blocks everything, including copying information from the page behind it). Overlays come in a range from heavy to light. Choose the lightest one that does the job.

Dialog (alert)

Small, centred, blocks everything. For decisions that cannot wait and are costly to get wrong. Two or three buttons with verb labels.

Sheet / modal page

A larger surface for a contained task (compose a message, create an event). Has its own Cancel and Done. Should autosave drafts if dismissed.

Popover / menu

Anchored to the element that opened it. Dismissed by clicking outside or pressing Esc. Does not block the page.

Toast / snackbar

Brief message near the bottom confirming an action, often with Undo. Does not block. Never use for errors that need action, since it disappears.

Banner

A persistent strip at the top of a screen or section for ongoing conditions. Stays until the condition ends or is dismissed.

Inline

The message lives in the content itself: an empty state, a field error, a hint under a setting. The calmest option.

In the wild

• GypsyXerox PARC, mid-1970s
  Larry Tesler and Tim Mott's editor let people select text by dragging and insert by typing, without modes, and introduced cut and paste in a form close to what we use today. Modeless editing became the default because it removed a whole class of errors.
• vimBram Moolenaar, 1991
  A deliberately modal editor: normal mode for commands, insert mode for typing. Experts love its speed; newcomers famously cannot find how to quit. Modes can pay off for experts who invest in them, and they cost newcomers dearly.
• FigmaFigma
  Holding Space turns the cursor into a hand for panning; releasing returns to the previous tool. A quasimode gives a temporary tool with no state to forget.

Recap and connect: Part two

States (6), controls (7), forms (8), forgiveness (9) and overlays (10) share one theme: respect for the person's attention and effort. Every chapter asked you to pick the lightest, most predictable option that still does the job.

When people can see the objects and act on them directly, with immediate, visible and reversible results, they learn by doing instead of by reading. Drag and drop, selection and bulk actions are where this works or fails.

Ben Shneiderman coined "direct manipulation" in a 1983 paper in IEEE Computer. He described three properties: a continuous representation of the objects of interest; physical actions (pointing, dragging) instead of typed commands; and rapid, incremental, reversible operations whose effect is immediately visible. Spreadsheets, the desktop, and today's design tools and kanban boards all follow this model. You met Bret Victor's version of the idea in the starter guide: creators need an immediate connection to what they make. The interaction-design job is to make that connection reliable.

Drag and drop: four moments to design

A drag has a beginning, a middle and an end, and each needs feedback. Most broken drag interactions skip one of them.

Selection models

Desktop operating systems settled on a selection grammar decades ago, and people's hands know it: click selects one and deselects others; Shift-click extends a range; Cmd-click (Ctrl on Windows) toggles one item; ⌘ A selects all; Esc clears. On touch, there is no hover or modifier key, so apps add an explicit selection mode ("Select" button, then tap to toggle, with a count in the title) or long-press to start selecting. Follow these conventions exactly; a list where Shift-click does something different is a list people distrust.

Bulk actions

When items are selected, the actions that apply to all of them should appear where the selection is (a toolbar that replaces the normal header, with a count: "12 selected"). Gmail solved a subtle problem well: "select all" selects only the visible page, and a banner then offers "Select all 1,240 conversations that match this search". That keeps the common case safe and the powerful case one click away. After a bulk action, report the result with a count and an Undo.

In the wild

• TrelloFog Creek, 2011
  Cards tilt slightly when lifted, the target list shows a gap where the card will land, and every card also has a "Move" action in its menu. The tilt is not decoration; it says "this is in your hand now".
• Things 3 Magic PlusCultured Code, 2017
  The "+" button can be dragged into a list to insert a new to-do exactly where you drop it, or tapped to add at a default position. Drag as an accelerator layered on a simple tap.
• Gmail select allGoogle
  Selecting all selects the page, then offers a banner to extend to every match. Safe default, explicit escalation.

The keyboard is the fastest input device most people own. Products that respect it let beginners use menus and buttons while showing them, every time, the shortcut that will make them faster.

Mouse and touch are great for discovery and spatial work; the keyboard is great for repetition. A person who archives 100 emails a day saves real time with a single-key shortcut. But shortcuts are invisible, so they must be discoverable: shown next to the menu item or in the tooltip of the button, so people learn them by using the product normally. macOS has done this since 1984: every menu item lists its shortcut on the right. That is the model: the slow path teaches the fast path.

Command palettes

A command palette is a search box for actions and places. Press a shortcut (often ⌘ K), type a few letters, use arrow keys to pick, press Enter. It turns a product with hundreds of commands into one with a single, learnable entry point. Sublime Text and VS Code (⌘ Shift P) made the pattern familiar to developers; Superhuman and Linear made ⌘ K central to their products; Raycast and Alfred apply it to the whole Mac, following Spotlight (2005). A good palette has: forgiving matching (typing "arc" finds "Archive"), results grouped by type, the shortcut shown next to each command, recent commands first, and context awareness (actions for the selected item appear at the top).

Designing shortcuts

• Respect platform standards first. ⌘ Z, ⌘ C, ⌘ F, Esc, Tab, Enter must do what they do everywhere.
• Single keys for frequent actions in list-based apps (Gmail's E archive, J/K next/previous, inherited from vi). Only when focus is not in a text field.
• Mnemonics: C for compose, A for assign. Sequences such as G then I ("go to inbox") give a whole namespace of navigation.
• Never override browser or system shortcuts people rely on, such as ⌘ W or ⌘ L.

Focus management

Keyboard use depends on focus: which element receives keys. Focus must always be visible (a clear ring), move in a logical order with Tab, go into a dialog when it opens, stay trapped inside while it is open, and return to the button that opened it when it closes. After deleting an item from a list, move focus to the next item, not to the top of the page. These rules are also accessibility rules (see Accessible & Inclusive), and they make the product faster for everyone who prefers keys.

In the wild

• SuperhumanSuperhuman, 2017 onward
  Built around the keyboard and ⌘ K; the palette shows each command's shortcut so people graduate to it. Teach the fast path through the slow path.
• VS CodeMicrosoft, 2015
  The Command Palette exposes nearly every command, with fuzzy matching and recently used commands at the top. One entry point can make a huge feature set approachable.
• RaycastRaycast, 2020
  A launcher where extensions add commands to the same search-and-run interface. A palette scales as a platform when every command shares one grammar.
• GmailGoogle
  Optional single-key shortcuts (J, K, E, R) and a ? overlay. Power features can sit quietly behind a simple default.

A fingertip is large, imprecise and covers what it touches. Make targets big enough, put frequent actions where thumbs reach, and treat gestures as shortcuts layered on visible controls, never as the only way.

Fitts's law (from The Human Mind) says the time to hit a target depends on its distance and size. On touch screens there is a second problem: the finger pad is roughly a centimetre across, and it hides the target as you press. That is why both major platforms set minimum target sizes: Apple's Human Interface Guidelines recommend at least 44 × 44 points, and Material Design recommends at least 48 × 48 dp (about 9 mm). WCAG 2.2 added a minimum of 24 × 24 CSS pixels (success criterion 2.5.8, level AA), with spacing exceptions, and keeps 44 × 44 as the stricter AAA level (2.5.5). The visible icon can be smaller; the tappable area should not be.

Thumb zones

Steven Hoober's observational research (published from 2013 onward) watched how people actually hold phones in the street and found many grips: one-handed with the thumb, cradled in two hands, and two thumbs. He found people shift grip often, and that the centre of the screen is easiest to reach and to tap accurately. On today's tall phones, the top corners are the hardest to reach one-handed. That is why primary actions have migrated to the bottom: tab bars, bottom sheets, floating action buttons and the search bar at the bottom of Safari on iOS 15 (2021).

Gestures are accelerators

Gestures (swipe to archive, pinch to zoom, pull to refresh, long-press for a menu) are fast once known and invisible until then. Josh Clark's writing on touch design (including Designing for Touch, 2015) makes the case for gestures as the "keyboard shortcuts of touch": treat them like shortcuts. Every gesture should have a visible equivalent: a swipe-to-delete row also has Delete in its menu; long-press menus repeat actions available elsewhere. Pinch to zoom, scroll, tap and swipe-between-pages are close to universal; anything else must be taught or discovered, and some people never will.

Edge swipes and conflicts

The screen edges belong to the system. iOS uses a swipe from the left edge for back (since iOS 7) and from the bottom for home; Android 10 and later use swipes from either side edge for back. An app that puts its own horizontal swipe gestures near an edge (a drawer, a carousel, a drawing canvas) fights the system, and the system usually wins. Keep custom swipes away from the edges, or respect the platform's gesture exclusion rules where you truly need them, such as in a drawing app.

Long-press and hover

Long-press is the touch equivalent of right-click: useful for context menus and previews, but hidden. Keep it for secondary actions. Hover does not exist on touch, so anything shown only on hover (tooltips, row actions, previews) must also be reachable another way. On iPad with a trackpad and on laptops with touch screens, design for both at once: hover reveals, tap and click both work.

In the wild

• Safari on iOS 15Apple, 2021
  Moved the address bar to the bottom by default, within thumb reach, with swipes on the bar to switch tabs. After feedback, Apple made the top position an option again. Ergonomics can justify breaking a habit, but give people a way back.
• Apple Mail, Gmail swipes2010s
  Swipe a message to archive or delete, with the same actions available in the message's toolbar. The gesture is a shortcut; the button is the guarantee.
• Material Floating Action ButtonGoogle, 2014
  A large primary action placed at the bottom right, in thumb reach. The main action belongs where the hand already is.

A microinteraction is a single, contained moment that does one thing: toggling a setting, liking a post, refreshing a list. Products are judged by these moments, because people repeat them thousands of times.

Dan Saffer's book Microinteractions: Designing with Details (2013) gave a simple structure for dissecting any of them. Four parts: a trigger starts it (a tap, a gesture, or a system condition such as a new message); rules decide what happens; feedback shows what is happening, in light, motion, sound or haptics; and loops and modes govern what happens over time and in special cases (does it repeat, does it change after the tenth use, is there a mode for power users).

Three dissected

Feedback: proportional and immediate

Feedback should arrive within about 100 milliseconds, so the action and the response feel like cause and effect, and it should be proportional to the importance of the action: a toggle deserves a slide, a payment deserves a clear confirmation, a keystroke deserves nothing but the character. Motion details (durations, easing, springs) are covered in Motion & Feel; this chapter is about the structure.

Loops: microinteractions that learn

The most overlooked part is the loop: how the moment changes over time. A first-run hint shows the first time, then never again. A notification groups after the third similar one. Autocomplete puts your most-used choice first. A "Snooze" offers the time you usually pick. These quiet adaptations make a product feel attentive without adding a single setting (see chapter 17).

In the wild

• Tweetie 2Loren Brichter, 2009
  Introduced pull-to-refresh: a trigger built from a gesture people already made. The best triggers extend existing habits.
• Instagram double-tapInstagram
  Double-tapping a photo likes it, with a large heart flash on the photo itself as feedback. Feedback where the eye is, not in a corner.
• Slack "mark as read"Slack
  Pressing Esc marks the current channel as read. A tiny keyboard trigger for a very frequent moment.

Recap and connect: Part three

Direct manipulation (11), keyboard (12), touch (13) and microinteractions (14) are four views of the same principle: input and response should feel like one continuous act, and every fast path should sit on top of a visible, reliable one.

Once a collection outgrows a screen, people need three tools: search when they know what they want, filters when they know what kind, and sort when they know what order. Paging decides how the rest arrives.

Marti Hearst's Search User Interfaces (2009, free online) and Peter Morville and Jeffery Callender's Search Patterns (2010) catalogue the patterns. The key distinction: search narrows by words (best when people can name the thing), filters narrow by attributes (best when people know properties but not names: unread, from this month, tagged "work"), and sort reorders without removing anything. Your object map's attributes (chapter 1) tell you exactly which filters and sorts make sense.

Search that forgives

People misspell, use synonyms, and type partial words. Good search is forgiving: it matches prefixes and typos, searches the fields people expect (title and body, not just title), ranks recent and frequently opened items higher, and shows results as you type when the data is local and fast. Keep the query visible in the field after searching, so people can refine it. Show recent searches when the field is focused and empty.

Filters and sort

Show active filters as visible, removable chips; hidden filters are the main cause of "where did my items go?" support requests. Show the result count, and update it as filters change. For each filter value, consider showing how many items it would leave (faceted search), so people never filter themselves into an empty page. Default sort should match the most common task: newest first for feeds, alphabetical for reference lists, relevance for search. Remember the person's chosen sort per view.

Pagination, load more, infinite scroll

Aza Raskin designed an early version of infinite scroll in 2006 and has since said publicly that he regrets how it has been used to keep people scrolling. Google switched its search results to continuous scrolling (mobile in 2021, desktop in 2022) and went back to page-based results in 2024. Infinite scroll also makes footers unreachable and makes it hard to return to a position. For calm products, prefer pagination or "load more", and if you use continuous loading, keep scroll position on back and show where the content ends.

In the wild

• Amazon facetsAmazon
  The sidebar filters by brand, price, rating and more, narrowing a huge catalogue without typing. Facets let people find what they cannot name.
• Linear filtersLinear
  Filters appear as chips in the view header and can be saved as custom views. Visible filters prevent "where did my issues go?"
• Google SearchGoogle, 2021 to 2024
  Tried continuous scrolling of results, then returned to pages. Even the biggest teams revisit paging; there is no universal answer.

A notification is the product reaching into someone's life uninvited. Send one only when it is timely, personal and actionable, at the lightest level that works, and give people control before they ask for it.

Gloria Mark's research at UC Irvine on workplace attention has shown how interruptions fragment work and raise stress, and how long it can take to return to an interrupted task. Amber Case's Calm Technology (2015), building on Mark Weiser and John Seely Brown's 1990s writing, argues that technology should require the smallest possible amount of attention and inform without demanding. For a calm product, notifications are the place where those ideas are tested every day. The ethics of engagement-driven notifications are covered in Honest & Calm; here we focus on the structure.

A ladder of loudness

Choose the quietest channel that delivers the message in time: inline (visible when they next look), badge or dot (a count, no sound), in-app inbox (collected, read on their schedule), digest email (batched), push notification (interrupts now), and at the top, time-sensitive or critical alerts. iOS 15 (2021) formalised this with interruption levels (passive, active, time-sensitive and critical), a scheduled notification summary, and Focus modes that let people decide who can break through. Android has notification channels (since Android 8, 2017) that let people turn off categories individually. Use these system tools honestly: marking marketing as "time-sensitive" will get your app's notifications turned off.

Permission in context

On iOS, an app gets one chance to show the system's notification permission prompt; if people decline, they must go to Settings to change it. Asking on first launch, before people know what the notifications would be, wastes that chance. Ask at the moment the value is obvious: after someone follows a thread ("Get notified when someone replies?"), or sets a reminder. Explain what you will send, and how often.

In the wild

• iOS notification summaryApple, iOS 15 (2021)
  People can batch non-urgent notifications into scheduled summaries, and Focus modes filter who can interrupt. The platform is moving toward calm; design with it, not around it.
• Slack notification settingsSlack
  Per-channel choices (all messages, mentions only, nothing) and scheduled "do not disturb". Granular control is a sign of respect in a product that can be very noisy.
• Android notification channelsGoogle, Android 8 (2017)
  Apps declare categories that people can mute independently. If you do not split your categories, people will mute all of them.

Every setting is a decision you handed to the user. Most people never change defaults, so the default is the design. Add a setting only when reasonable people genuinely need different behaviour, and organise the few you keep around the person's goals.

Jared Spool's 2011 article "Do users change their settings?" reported that the vast majority of people never change the defaults in the software they use. Alan Cooper's About Face (first edition 1995) makes the design consequence clear: the default is not a starting point, it is what most people will experience forever. When a designer cannot decide between two behaviours, adding a setting feels like a kind compromise. It is really a way of postponing the decision and charging every user a small tax to make it themselves. 37signals' Getting Real (2006) put it bluntly as "make opinionated software". iA Writer, from the starter guide, is the extreme example: very few preferences, because the defaults were designed with care.

Adapt before you ask

Many settings exist because the product could not tell what the person needed. Often it can: follow the system's appearance, language, text size and reduced-motion preference; remember the last-used view, sort and export format; infer time zone. A remembered choice is a setting the person made without visiting Settings. That is the "loop" from chapter 14, applied to configuration.

Organising the settings you keep

Group settings by the person's goals and the object map, not by your code modules: "Reading", "Highlights and notes", "Sync and backup", "Notifications", "Account". Put the most-changed settings first. Use one scrollable page with section headings for up to roughly 20 to 30 settings; beyond that, split into sections and add search. Settings should take effect immediately with switches and live previews (chapter 7). Every setting needs a short description of its effect in plain words, and destructive account actions (delete account, sign out everywhere) belong at the bottom, separated.

In the wild

• iA WriterInformation Architects, 2010 onward
  Deliberately few preferences; the typography and layout are designed as the default rather than left to the user. Strong defaults are a statement of care, not a lack of features.
• System appearancemacOS Mojave (2018), iOS 13 (2019)
  Apps that follow the system's light and dark setting need no theme setting of their own for most people. Let the platform hold preferences people set once for everything.
• VS Code settingsMicrosoft
  Thousands of settings, made usable by search, grouping, descriptions and a "modified" indicator. If a product truly needs many settings, search and descriptions are not optional.

Wrap-up

Structure and interaction are where a product's honesty shows. A calm, minimal product is not one with fewer pixels; it is one where every object has a home, every place says where you are, every state has a purpose, every input is forgiving, and every fast path rests on a visible one.

Run this on your product

Practice assignment for the next two weeks

About 45 minutes a day. Use your own product throughout; if it is early, use the product you plan to build, on paper.

1. Days 1–2: the skeleton. Object map (Exercise 1.1), then a card sort with three friends (2.1).
2. Days 3–4: the map. Navigation audit and redraw (3.1); trunk test and URL map (4.1).
3. Days 5–6: the paths. Golden path and one core flow with edge cases (5.1); state grid for three screens (6.1).
4. Day 7: rest and review. Re-read your notes. Run the audit checklist above and record your score.
5. Days 8–9: inputs. Control audit (7.1); rebuild your most important form (8.1).
6. Day 10: safety. Climb the ladder for every destructive action (9.1); overlay inventory (10.1).
7. Days 11–12: hands. Command registry and palette (12.1); one-thumb audit (13.1).
8. Day 13: details. Dissect and improve five microinteractions (14.1).
9. Day 14: restraint. Notification inventory (16.1) and settings diet (17.1). Run the audit checklist again and compare with day 7.

Reading list

• Information Architecture: For the Web and Beyond
  Louis Rosenfeld, Peter Morville, Jorge Arango (4th ed., 2015) · the standard reference on organisation, labelling, navigation and search systems.
• How to Make Sense of Any Mess
  Abby Covert (2014) · a short, friendly guide to IA thinking; read it in an evening.
• Card Sorting: Designing Usable Categories
  Donna Spencer (2009) · everything you need to run sorts yourself and analyse them.
• Don't Make Me Think, Revisited
  Steve Krug (2000; 3rd ed., 2014) · the trunk test, navigation and cheap usability testing; the most readable usability book.
• Object-oriented UX (OOUX) and the ORCA process
  Sophia Prater · articles and talks on mapping objects before screens; search for her "OOUX" writing.
• Designing Interfaces
  Jenifer Tidwell, Charles Brewer, Aynne Valencia (3rd ed., 2020) · a pattern library for navigation, lists, forms and more.
• Web Form Design: Filling in the Blanks
  Luke Wroblewski (2008) · labels, validation, layout and the evidence behind them.
• Forms that Work
  Caroline Jarrett and Gerry Gaffney (2008) · forms as conversations; excellent on question wording.
• The Humane Interface
  Jef Raskin (2000) · modes, quasimodes, habituation; opinionated and still provocative.
• Microinteractions: Designing with Details
  Dan Saffer (2013) · the trigger, rules, feedback and loops model, with many examples.
• About Face
  Alan Cooper and colleagues (4th ed., 2014) · goal-directed design, defaults, and why software should not ask what it can know.
• Designing for Touch
  Josh Clark (2015) · thumbs, gestures and touch ergonomics in one short book.
• "Never Use a Warning When You Mean Undo"
  Aza Raskin, A List Apart (2007) · the five-minute case for undo over confirmation.
• "Cool URIs don't change"
  Tim Berners-Lee, W3C (1998) · why addresses are a promise.
• Search User Interfaces
  Marti Hearst (2009, free online) · research-based patterns for search, results and facets.

Next: Visual Design builds on this structure with hierarchy, layout and colour. For the timing and feel of the transitions mentioned here, see Motion & Feel.