Refactoring UI

A self-published book aimed squarely at developers who can build an interface but cannot make it look finished. It is deliberately tactical: short chapters, each one a specific move with a before-and-after.

Its premise is that a great deal of the gap between amateur and professional interface work is a set of learnable defaults rather than taste, and that premise turns out to be largely correct.

The gap is mostly learnable defaults, not taste. That premise is the book's whole justification.

Devmark’s reading — not a quotation from the book

Their opening advice: design a specific piece of functionality before designing the shell around it, because a navigation bar designed before there is anything to navigate is designed against nothing.

Their related advice to work in greyscale first, adding colour only once hierarchy works, is the single most effective exercise in the book.

Their central insight about emphasis: size is the crudest tool and most beginners reach for it first. Weight, colour and contrast usually do the job better and leave the layout intact.

Their specific advice — de-emphasise rather than emphasise, use a lighter grey rather than a bigger heading, and avoid competing emphasis — is directly applicable and produces visible improvement immediately.

Their argument for a constrained spacing scale with non-linear steps, so that adjacent values are distinguishable and choosing between them is quick.

Their rules — start with too much white space and remove it, give elements only the space they need rather than distributing evenly, and make related elements closer than unrelated ones — cover most spacing failures.

Their practical guidance: build a type scale rather than choosing sizes ad hoc, restrict line length, adjust line height inversely to font size, and avoid centring long text.

Their treatment is less rigorous than Bringhurst's and far more immediately usable, which is the trade the whole book makes.

Their approach to building a palette: several greys at defined steps, one or two primaries, a few accents, and every colour available in a range of shades rather than as a single value.

Their advice to avoid relying on hue for meaning, and to check that everything works when lightness alone distinguishes it, is the accessibility-adjacent guidance the book handles well.

Their treatment of shadows as a consistent elevation system with a shared light source, of borders as one of several available separation techniques rather than the default, and of the specific small touches that make interfaces feel finished.

The shadow-as-elevation-scale idea is the one most worth extracting, because it converts a per-component decision into a system-level one.

Shadows as a scale with one light source turns a per-component decision into a system-level one.

Devmark’s reading — not a quotation from the book

Their insistence that empty states, loading states and error states be designed rather than left to fall out of the implementation.

Their point that a design looking good only with idealised content is an incomplete design is straightforward and routinely ignored in practice. They extend it to content extremes as well — the very long name, the missing image, the list with one item — which is where most portfolio-ready layouts come apart on contact with production data.

It is tactical by design, which means it does not address research, user needs, interaction patterns, information architecture, or why an interface should exist in the shape it does.

It also encodes a particular aesthetic — the clean, spacious, softly shadowed style of its period — and a reader applying it uniformly will produce work that looks of that moment. The tactics are more durable than the look they produce.

As a reference to consult while building rather than a book to read through, and paired with something that covers the questions it does not: what to build and for whom.

The greyscale-first exercise and the spacing scale are the two things worth adopting immediately regardless of what else a team does.