Summary
Refactoring UI is a self-published book by Adam Wathan and Steve Schoger, both of whom built their audiences through Twitter by posting before-and-after UI redesigns. The book compresses those redesigns into a dense, visually driven manual for making interfaces look professional without a formal design background. It is aimed primarily at developers who build their own interfaces and want practical guidance on the decisions that separate polished from amateur.
The book is organized around decisions rather than principles. Rather than explaining design theory, it demonstrates specific choices: how much whitespace to add, when to use font weight versus font size to establish hierarchy, why bright colors work best as accents rather than backgrounds, how to test whether a shadow is doing any work. Each section shows a before version — something that looks like it came from a developer with no design training — and an after version that addresses one or two specific problems. The approach is deliberately practical; Wathan and Schoger have little interest in abstraction.
The most useful sections address visual hierarchy and typography. The authors argue that most interface problems are really hierarchy problems: the user can't tell what to look at first because everything has similar visual weight. The solution is almost always to reduce the prominence of secondary elements rather than to amplify the primary one — a counterintuitive move that produces cleaner, quieter interfaces. On typography, they give specific guidance that most tutorials don't: don't use pure black text on white, limit yourself to two typefaces, don't rely on font size alone to signal importance.
The book's limitation is its self-published format: there is no ISBN, it is sold only through the authors' website, and the content skews toward product interfaces (dashboards, forms, lists, cards) rather than editorial or marketing design. Developers building web products will find it directly applicable; designers working in other contexts will find it more selective. It is also not a comprehensive design education — it is closer to a collection of heuristics that address the most common mistakes specifically.
Key takeaways
- 1.
Most interface problems are hierarchy problems. When nothing has priority, nothing is readable. The fix is usually to reduce secondary elements rather than amplify the primary one.
- 2.
Start with too much whitespace and remove it. Interfaces that look cramped almost always have too little space; adding white space is cheaper and cleaner than any decorative fix.
- 3.
Don't rely on font size alone to create hierarchy. Varying font weight, color opacity, and letter spacing communicates importance more subtly and more flexibly.
- 4.
Saturated colors work best as accents on small areas. Desaturated or muted versions of the same hues are easier to use as backgrounds and large surfaces without feeling aggressive.
- 5.
Shadows should be small and mostly invisible — present enough to suggest elevation but absent from conscious notice. Big dramatic shadows are a sign the surface isn't working without them.
- 6.
Designing without color first forces hierarchy to come from form, size, and spacing rather than relying on color as a crutch. Add color last, as a refinement, not a foundation.
- 7.
Limit your font palette to two families: one for UI text (labels, data, controls) and one for display text (headers, marketing copy) if you use display text at all.
Discussion questions
Use these on your own, with a book club, or as chat starters in Superbook.
- 1.
Wathan and Schoger built their audience through Twitter before writing the book. Does that origin — solving problems publicly in before-and-after format — affect how you trust or use the content?
- 2.
They consistently argue for reducing rather than adding when interfaces feel wrong. Is that instinct natural to you, or do you default to adding more?
- 3.
The hierarchy argument — that most problems are really priority problems — applies beyond UI. Where else in communication or presentation do you see the same issue?
- 4.
The book is pitched at developers who design their own interfaces. Is it appropriate for trained designers? What would a designer find useful versus obvious?
- 5.
They recommend starting in grayscale to force hierarchy from form rather than color. Have you tried this? Does the constraint help?
- 6.
The book covers product UI almost exclusively — dashboards, forms, cards. How well do the principles transfer to editorial, brand, or marketing design?
- 7.
Most design books are heavy on theory; this one is deliberately light on it. Do you prefer to understand why rules exist, or is demonstrated practice enough?
- 8.
The self-published, web-only format means the book will eventually go out of print or behind a paywall. Does how a book is distributed affect how seriously you take its ideas?
- 9.
They give very specific numerical guidance in places — whitespace multiples, color opacity percentages. Do you find that level of specificity helpful or constraining?
- 10.
The book is essentially a collection of heuristics rather than a design system. What are the limits of heuristics as a design education?
- 11.
What is one thing you've tried to build or design recently where one of their principles would have directly helped?
Themes
Frequently asked questions
-
Is Refactoring UI worth buying for professional designers?
It depends on your background. If you trained in design school, most of it will cover ground you already know in less depth than your education. If you are self-taught or primarily a developer who designs, the specific, demonstrated guidance is genuinely useful and efficiently presented.
-
Where can you buy Refactoring UI?
The book is sold exclusively at refactoringui.com. It is not available on Amazon or in print bookstores. It comes as a PDF and includes supplementary component examples.
-
How long is Refactoring UI?
Around 220 pages, but it is densely illustrated — probably half the pages are images. The written content reads in two to three hours. Many readers return to specific sections as reference when working on a specific problem.
-
What kind of interfaces does the book cover?
Primarily web product interfaces: dashboards, forms, data tables, cards, navigation, modals, and empty states. It does not cover mobile-first design, editorial layout, or print. Developers building SaaS products or web applications will find it most directly useful.
-
Is this the same as a Tailwind CSS tutorial?
No. The book predates Tailwind's current popularity and makes no references to any specific technology. The guidance is about visual decisions — spacing, color, typography, hierarchy — and applies regardless of how you implement it.
