UX and Product Design

The newcomer can begin with The Basics of User Experience Design (2018), nine short chapters that each introduce one area of the field,[10] or the briefer Crafting Seamless User Journeys (2025).[11] A manager who needs the argument for spending on design has Principles Strategies Tools for Design Thinking (2021).[2]

Designers who want practical rules can read The UI/UX Playbook: Tips & Tricks for Exceptional Design (2023), which teaches by paired right and wrong screens,[4] and The Designer's Guide to the Buttons (2026), which explains each component through its history.[1] On research there is A Beginner’s Guide to Finding User Needs (2022), a hands-on guide to qualitative work,[12] and on usability Usability: From Friction To Flow (2025).[13]

For accessibility the shelf has iOS Accessibility Handbook (2016), a reference for one mobile platform that is now dated in its versions,[3] and for engineers building a component library Web Components & Design Systems (2026) and Web Components with Lit (2026).[5][6] The most widely read book here is a collection of essays, Rethinking Systems Analysis and Design (2014).[15]

The graphical interface was devised in research laboratories in the 1960s and 1970s and reached ordinary users in the 1980s, when the study of how people use computers became a field with its own methods of testing. The phrase user experience dates from the 1990s, and the web, and from 2007 the touchscreen phone, made the design of interfaces a mass profession. Guidelines for accessible web content were first published in 1999. In the 2010s companies began to maintain design systems, shared libraries of components and rules, and the decade's change of fashion from the imitation of physical materials to flat surfaces was argued over in public.

The Designer's Guide to the Buttons starts the story earlier, with the electric push-button, which it dates to about 1880 and to doorbells and the summoning of hotel staff. Buttons were feared at first, as electricity was, and educated people worried that the young would forget how to do anything with their hands; they spread all the same through cameras, light switches, lifts, cars and radios, until by the 1960s they covered almost every consumer device. The hard part of a physical button, the book notes, was never the press but the return, for which inventors proposed everything from a spring or a rubber membrane to a patented doorbell of thirty-three parts; all of them merely closed a circuit. Then, on the book's account, the computer swallowed them: after a research centre showed the first graphical interface in 1973, buttons became pictures, which give no physical feedback and can be pressed only while looking at the screen.[1]

The book's key term is skeuomorphism, any imitation in which a new object mimics an older one to stay familiar. Its examples run from electric chandeliers shaped like candelabra and a patented motor car with a horse's head on the front, to the ornament of stone temples that copies the beam-ends of wooden ones, and it argues that almost every element of the graphical interface is or once was such an imitation, because the thing was too unlike anything before it to be understood otherwise. The first on-screen button was a label in a frame. Putting the label inside the button was new, since paint wears off a real one under the finger, and the rule that a button's label should be a verb, because a button performs an action, was followed from the beginning. The book divides this history into eras as a historian would, an ancient one opening in 1973 and later ones marked by a desktop system of 2001, a phone of 2007 and a headset of 2024.[1]

Principles Strategies Tools for Design Thinking is written for the heads of businesses and for product and programme managers as much as for designers, and argues from outcomes. Bad design, it says, is the more expensive kind: it baffles and frustrates, and a prospective customer whose first impression of a site or an app is poor is gone within seconds, probably for good. Its evidence is commercial, the recovery of a computer maker after 1997, which the book credits to industrial design, and a published index of design-led companies said to have outperformed the stock market. Good design is harder to notice than bad because it fits its purpose so well as to be invisible, and the book's examples are everyday ones, a railway platform too far from the carriage door on one side, a calorie counter that does its own arithmetic on the other. It notes that people tend to perceive attractive products as more usable, and proposes that the question to ask is what a company stands to lose in the absence of good design. The book separates interface design, the visual side, from the wider work of experience design, observing that some designers do both and others stop at research and wireframes, and it defines interaction design as the effort to improve people's understanding of what can be done, what is happening and what has just occurred.[2]

Two older books treat design as judgement under uncertainty. The sample of System Design Heuristics (2018), a collection drawn from its author's consulting notes, is a single checklist built on the idea that a design is a wager on the future. It lists the guesses a designer is making: that hardware will or will not change, that costs will move, that usage will grow and follow a pattern, that the builders and maintainers will understand the design, that users will or will not be trained, will make errors and may try to beat the system, and last whether the designer understands the users and the business at all. The list is to be used at the start of a design, and again to record assumptions so that customers and users know what its success depends on.[8] Rethinking Systems Analysis and Design collects short essays on the less structured side of the same work, observation, interviewing, trade-offs and the designer's mind, each part ending in a fable.[15]

The method that Principles Strategies Tools for Design Thinking recommends is user-centred design, which begins by identifying the primary users, meeting and observing them, and learning their stated and unstated requirements, and which the book distinguishes by that step from development in fixed phases. It is interdisciplinary, bringing together users, managers, developers, testers and the business, and iterative: design, test, fail and try again with prototypes and early feedback. A solution is sought that the business finds viable, the technology makes feasible and the users find desirable. Companies, the book observes, spend heavily on marketing and very little on understanding their users, and learn late that customers did not need some of what was built.[2]

A Beginner’s Guide to Finding User Needs follows one qualitative research project in order, from preparation and the recruiting of participants through sessions, analysis and the report, and includes the documenting of activities together with participants and the prevention of harm to them and to researchers.[12] Usability: From Friction To Flow organises its subject around friction, which it divides into the cognitive and the mechanical, and goes on to prototyping, testing and measurement,[13] and Crafting Seamless User Journeys maps the user's journey from first contact through onboarding to changes made after launch.[11]

The older tradition called this requirements. Exploring Requirements One (2014) is about finding out what people want before a product is designed, with chapters on ambiguity, on questions that can be asked of any project, on getting the right users involved and on handling conflict,[16] and Exploring Requirements Two (2014) continues through functions, attributes, constraints and expectations to tests of user satisfaction.[17] Lean Experimentation In Action (2017) gives the newer form of the same caution. It defines its subject as any quick and cheap way of predicting whether a product will deliver the value expected of it, explains lean as learning more with less effort so that investment is better informed, and takes from science its concepts without the laboratory. Of its three repeated steps the first is to uncover the assumptions that could kill a product and to decide which to learn about first.[9]

The Designer's Guide to the Buttons takes one component in each chapter, the button, the checkbox, the dropdown list, the text field, the tab, and follows it from its origin to its present anatomy, states and variations, closing with a matrix of them. It does this three times over, for desktop interfaces, for mobile ones, where a chapter is given to the zone a thumb can reach, and for mixed reality, and its intermission warns of the trap in adapting a design from one of these to another.[1]

The UI/UX Playbook: Tips & Tricks for Exceptional Design gives rules of the same kind in short tips for people without a training in design. A phone is often worked with one hand, so the controls used most should lie within the thumb's reach, and a principal action placed outside it makes users stretch or change their grip. Things to be tapped should be at least forty-eight pixels square, a size the book derives from the pad of a finger, with space between them to prevent a wrong tap. An empty screen, after a list is cleared or a search finds nothing, should not merely report the absence but say what to do next. And a form can arrange its fields as the finished result will appear, so that someone listing an item for sale sees the shape of the listing while filling it in.[4] Web Forms (2026) gives a whole book to forms, and to how usability, accessibility and performance shape the experience of completing one.[14]

iOS Accessibility Handbook was written because the web had an industry-standard reference for accessibility, produced over years by more than a hundred specialists and adopted into law by many governments, and one widely used mobile platform had none: its maker's documentation, the book says, was either purely technical, in long videos, or addressed to consumers. The book keeps the web guidelines' four principles, that content be perceivable, operable, understandable and robust, and their three levels of conformance, and replaces the web's technologies and input devices with the platform's own. Meeting the first level is required before an app may be called accessible; the higher ones cannot always be met, since a drawing app cannot be worked wholly from a keyboard and a live broadcast cannot be captioned exactly.[3]

Its argument is that accessibility is no checkbox and no limit on design. An app must be described to the assistive technologies through semantics, a label, traits, a hint and a value, and once it is, those technologies let a user skim a screen without seeing it, steer by tilting the head or read and write in Braille, with no further work from the developer. The same semantics are the basis of automated testing, so that conformance becomes a by-product of a robust application. The book's example is a video shown as a button, which should announce what it is, how long it lasts and what activating it will do. Users choose which aids are switched on, such as inverted colours for those sensitive to brightness or single-channel sound for those who hear with one ear, but the makers of an app decide how it behaves when they are, and the book recommends toning down animation and transparency for a user who has asked for less of them.[3]

Visual and Accessibility Testing: Pixels and People (2026) treats the checking as engineering. It compares screenshots of each build with a known good one, and describes a hybrid in which a fast comparison of pixels flags differences, small ones are approved automatically, larger ones go to an AI vision model for classification, and only meaningful changes reach a person; the book claims a large reduction in human review by this means. Its instructions to the model sort differences into four classes, from rendering noise to be approved automatically, through minor and significant changes, to breaking ones such as overlapping elements or missing content, which stop the build. Such a model, it adds, can remark that a new combination of colours may fail the contrast requirement, and the book goes on to automated checks against the guidelines in a single pipeline.[7]

Web Components & Design Systems is for front-end developers and design-system teams who want reusable interface parts built on the browser's own component standard and not on one framework's schedule of releases. It builds a single design system chapter by chapter, with design tokens, themed components, a manifest, a documentation pipeline and finally a server through which an AI agent can use the system correctly. Its discipline is that everything in it was run in a real browser, because much of what is commonly said about these components describes, on its account, a browser that ceased to exist around 2020; where a first attempt was wrong, the correction is shown. Its conventions serve the same end: a rule is stated once in a box, code that is deliberately broken is always marked as such before it appears, and screenshots are captioned with the markup that produced them, as proof that what the prose claims was rendered. The later parts argue that a design system's precision is what makes it legible to an agent, for the reason it makes a good interface for a human developer.[5]

Web Components with Lit teaches the same standard without a framework and then with one small library, while building a design system that is published as a package. It keeps its corrections visible in the same way, and offers an index of symptoms, a property set and nothing redrawn, a checkbox that lands on the wrong row after sorting, a component that ignores the page's theme, each mapped to the chapter that answers it; every entry, the book says, was a real bug during the writing.[6]