Taste Is Trainable

There is a sentence engineers say about design that they would never say about code. "I'm just not a design person — you either have an eye or you don't." Said with a shrug, as if reporting a fact about their height. The same person who spent four years learning to feel the difference between a clean abstraction and a leaky one, who can glance at a function and wince, who has opinions about naming — that person believes taste in visual design is a gift handed out at birth to art kids and withheld from everyone else.

It is the most disprovable claim in this book, and the person disproving it is you, retroactively. Because you already built an eye once. You just built it for code.

The trap: taste feels innate because you forgot learning it

Think back to your first month of programming. You could not tell good code from bad. A 300-line function and a tidy set of small ones looked equally valid — both ran, both passed, both shipped. The idea that one was ugly would have meant nothing to you. You had no eye.

Then you read code. A lot of it. Pull requests, open-source repos, the senior engineer's commits, your own work six months later (the most humbling read of all). Somewhere in those thousands of exposures, a faculty assembled itself without your permission. Now you open a file and feel something before you've consciously parsed it — a tightening when a function does three things, a small relief when a module has one clear job. That feeling is not innate. It is compiled. It is pattern recognition built from volume, and you can name the inputs that built it.

Visual taste works exactly the same way, and this is the whole argument of the chapter: the engineer who has studied a hundred interfaces will out-design the "natural" who has studied none. The natural is just someone who started the exposure earlier, usually as a teenager redesigning their MySpace page or obsessing over album art, and then mistook the head start for a gene.

The reason the gift story is so sticky is that the learning is invisible while the judgment is instant. When a designer glances at your dashboard and says "the spacing feels off," it looks like magic — a verdict from nowhere. It is not from nowhere. It is from the ten thousand spacing decisions they have absorbed, the same way your "this code smells" is not mysticism but a lifetime of diffs. Magic is just expertise you didn't watch get built.

Here is the part that should make you optimistic rather than daunted: you are better at this than the average person starting design, because you already know how to learn a perceptual skill from examples. You know that volume beats talk, that reading beats reading-about, that you have to look at real artifacts and not just theory. Most beginners waste a year on color-theory videos. You can skip that and do the thing that actually works, which is the rest of this chapter.

How to build a reference library

The single highest-return habit you can start today costs nothing and takes thirty seconds a day. You begin collecting interfaces you admire — deliberately, with structure — and you study them the way you study a great codebase. I call the collection itself a reference library, and it is the central tool of this chapter.

The word deliberately is load-bearing. Passively scrolling Dribbble for dopamine is not building a library any more than passively scrolling GitHub trending is reading code. A library is something you curate, organize, and return to. The act of choosing to save a thing — and being able to say why — is half the value.

What to collect. Save real, shipping interfaces over fantasy concept art. A Dribbble shot of a banking app that could never exist is design-as-poster; it ignores empty states, error states, dense data, and every constraint that makes design hard. Collect the screens you actually use and admire: the checkout that felt effortless, the settings page that was somehow not overwhelming, the onboarding that didn't make you think. Stripe, Linear, Vercel, Things, Notion, Apple's own apps, the good parts of your bank — these are reference-grade because they survived contact with reality. Screenshot the moment you notice a feeling, good or bad. "Bad" examples are worth collecting too; a confusing form teaches as much as a clean one.

How to categorize. A pile is not a library. Organize along three axes, and tag liberally:

• By component. Buttons, forms, tables, navigation, modals, empty states, pricing tables, settings panels. When you sit down to build a date picker, you want to summon ten great date pickers in one click. This is the axis you'll query most often.
• By flow. Onboarding, checkout, search-and-filter, the delete-confirmation dance, the upgrade path. Flows teach sequence — how good products break a hard task into a series of un-scary steps. A single screenshot can't teach this; capture the whole sequence.
• By feeling. "Calm." "Dense but legible." "Playful without being childish." "Trustworthy." This axis sounds the softest and is the most powerful, because clients and PMs brief you in feelings, not components. When someone says "make it feel more premium," you want a folder of premium to deconstruct, not a blank stare.

Tools for saving it. The tool barely matters; the habit is everything. The lowest-friction option is a screenshots folder synced to the cloud with descriptive filenames — searchable, portable, zero setup. Many designers use a dedicated bucket: a Notion database with tags, a private Pinterest board, an app like Mobbin (which catalogs real app flows for you) or Eagle (a desktop image manager built for exactly this). Pick the one with the least friction between noticing a thing and saving it, because friction is what kills the habit by week two. If saving takes more than ten seconds, you will stop, and a library you stopped feeding is just a folder of nostalgia.

How to study an interface so it changes your output

Collecting is necessary and not sufficient. A library you never read changes nothing — like a bookshelf bought by the foot. The skill that converts the library into taste is deconstruction, and almost everyone does it wrong on the first try. They copy the screenshot. They eyedrop the exact blue, match the exact font, clone the pixels — and end up with a hollow imitation that falls apart the moment their content differs from the original's. Copying the pixels is cargo-culting; you reproduced the artifact without the reasoning that produced it.

What you actually want to copy is the structure and the decisions. The right question is never "what does this look like" but "what decisions did they make, and why?" Every interface is a stack of choices, and your job as a student is to reverse-engineer the choices, not trace the output.

Stand in front of a screen you admire and interrogate it like a code reviewer reading an unfamiliar PR:

• Hierarchy. What does your eye hit first, second, third? Run The Squint Test — blur your eyes (or actually squint) and see what still reads. The thing that survives the blur is what they decided was most important. Was that the right call? Why is it winning — size, weight, color, isolation, position?
• Type. How many distinct text sizes are on this screen? Almost always fewer than you'd guess — three or four. Is there a consistent ratio between them? That's The Type Scale at work, and once you start counting sizes you cannot stop seeing it. What's the line-height on the body text? The contrast between heading weight and body weight?
• Space. Pull out a ruler (your browser's dev tools are a literal pixel ruler — Cmd-Shift-C and hover). Measure the gaps. You will find them suspiciously round: 8, 16, 24, 32. That's not luck; it's a spacing system. Notice how the amount of space around an element signals its importance, and how generous whitespace reads as confidence.
• Color. How many colors are actually here? Strip it to grayscale in your head. Most great interfaces are 90% neutral with one accent doing all the work. Where does the one saturated color appear? On the single most important action, almost certainly.
• Restraint. This is the decision beginners can't see because it's invisible: what did they leave out? No border here. No drop shadow there. No third button. The discipline of subtraction is most of what separates professional work from amateur work, and you can only learn to see it by studying things that have it.

Then comes the move that actually rewires you: reconstruct it. Open a blank file and rebuild the screen from scratch — in HTML and CSS, in Figma, on paper, the medium doesn't matter. You are not allowed to copy-paste or eyedrop. You have to decide every value yourself, then compare to the original and measure the gap.

This is identical to the way you truly learned a framework. You didn't learn React by reading the docs; you learned it by rebuilding a tutorial app and feeling exactly where your mental model diverged from reality. Reconstruction surfaces your blind spots with brutal precision. You'll set a heading and realize the original's was tighter against its body text. You'll pick a gray and find theirs was warmer. Each gap is a lesson your eye couldn't have received any other way, because you didn't know the question existed until your version answered it wrong.

Make the questions concrete. Here is the kind of artifact a deconstruction produces — not a screenshot, but a written record of decisions you can read back later, the way you'd leave notes on a PR:

Stripe pricing card — decisions
- Hierarchy: price wins the squint test (largest type, heaviest weight,
  most space around it). Plan name is secondary. Feature list is tertiary,
  smaller and lower-contrast on purpose.
- Type: 3 sizes only. Price ~36px, plan name ~18px, features ~14px.
  Roughly a 1.333 ratio between steps (The Type Scale).
- Space: vertical gaps are 8 / 16 / 24 — all multiples of 8. The card
  padding is generous (32), which reads as "premium, not crowded."
- Color: ~90% neutral. One accent (their indigo) appears exactly once,
  on the primary CTA. Nothing else competes for it.
- Restraint: no border on the card — separation comes from a soft shadow.
  Secondary plans use a ghost button so only the recommended plan shouts.

That note is worth more than the screenshot, because it's the reasoning extracted from the pixels. When you rebuild it, those lines become your spec, and the gaps between your spec and theirs become your lessons. A first stab at the spacing in code makes the system explicit:

.pricing-card {
  --space-1: 8px;
  --space-2: 16px;
  --space-3: 24px;
  --space-4: 32px;

  padding: var(--space-4);
  border-radius: 12px;
  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.08),
              0 8px 24px rgba(0, 0, 0, 0.06);
}

.pricing-card .price { font-size: 36px; font-weight: 700; }
.pricing-card .plan  { font-size: 18px; font-weight: 600; }
.pricing-card .feature { font-size: 14px; color: #6b7280; }

Notice what writing it down forces: you can no longer fudge a value. "About this much space" becomes 24px or it becomes nothing. That precision is exactly the muscle a vague eye lacks, and the only way to build it is to keep committing to specific numbers and checking them against work that got the numbers right.

A useful side effect: deconstruction kills the intimidation. A screen you've taken apart and rebuilt is no longer magic — it's a finite set of decisions, most of which you can now name. The Figma file stops being a blank-canvas panic and becomes a checklist. That shift, from "I have no idea where to start" to "okay, hierarchy first, then type, then space," is the entire difference the library buys you.

The practice loop: how taste compounds

None of this is a one-time exercise. Taste is not a destination you arrive at; it's a flywheel you keep spinning, and like any flywheel it's brutal to start and then increasingly hard to stop. The loop has five moves, and the same shape threads through the whole book as The Taste Flywheel:

The reason this compounds rather than merely accumulates is that each pass through the loop raises the ceiling of what you can even perceive. Early on you'll deconstruct a screen and catch maybe three decisions. Six months in, the same screen reveals fifteen — the kerning, the optical alignment, the way the shadow is tinted with the background hue rather than pure black, the deliberate inconsistency that's actually a considered exception. You didn't get smarter; your library got bigger, so your pattern-matcher has more to match against. The feeling of "I just see more now" is the cache filling up.

There's a quiet trap on the far side of this worth naming before you start: do not let collecting become a substitute for shipping. It is genuinely fun to fill a beautiful library and feel like you're improving while producing nothing — the design equivalent of buying programming books you never open. The library only pays off when it flows through your hands into work that real people see. Collect → deconstruct → imitate → ship → critique. The verbs that matter most are the last three, because they're the ones with friction, and friction is where the learning lives.

What to do Monday morning