Thoughts, Stories & Experiments

Every beautiful interface contains something you cannot see. It's not the color choice, not the typeface, not even the layout — it's the space that holds these elements apart. Designers call it negative space, but that label makes it sound like an absence. It isn't.

Negative space is the most active force in visual design. It creates hierarchy without explanation. It guides the eye without instruction. It communicates tone before a single word is read. When you encounter an interface that feels expensive, that feeling is almost entirely constructed from what isn't there.

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away." — Antoine de Saint-Exupéry

Rhythm as Architecture

Consider how music works. The notes themselves carry information, but it's the intervals — the rests — that create rhythm. Remove the rests and you have noise. Remove too many notes and you have silence. The art is in the proportion.

Typography operates the same way. A body copy set at 16px with 28px line height doesn't just become readable — it becomes comfortable. The reader settles into a cadence. The eye knows where to go next without being told. This is the invisible architecture working as intended.

The Restraint Principle

The hardest skill to teach junior designers isn't color theory or layout fundamentals — it's restraint. Every designer, early in their career, faces the same temptation: to add. Another shadow. Another gradient. Another animation. Each addition seems to improve the work, until suddenly it doesn't, and the interface has become busy without you noticing exactly when.

The senior designer's superpower is the ability to remove. To see the thing in the corner that isn't earning its space. To recognize that the card hover state has three effects when it needs one. To understand that the best microinteraction is often the one that was decided against.

/* Space that communicates intent */
.card {
  padding: clamp(1.5rem, 4vw, 3rem);
  gap: var(--space-md);
  /* Not 24px. Not 32px. A relationship. */
}

The interfaces we remember — Apple's product pages, Stripe's documentation, Linear's onboarding — share this quality. They feel inevitable. Not designed, but discovered. That feeling is crafted through thousands of decisions to not add the thing you were about to add.

Software that lasts doesn't win because it's clever. It wins because it refuses to be clever when clarity is available. The most elegant codebases I've encountered share a quality that's almost impossible to articulate until you've seen enough of both kinds: they read like they were written to be read.

This sounds obvious. Of course code should be readable. But there's a version of "readable" that means "I can follow what this does" and a much rarer version that means "I can understand why this exists, and why it is the way it is, and what would happen if it weren't." The second kind is what makes a system last.

"Simplicity is the ultimate sophistication. The complexity is still there — it's just invisible to anyone who doesn't need to see it." — From a team retrospective, 2019

The Cost of Clever

Every clever solution carries a hidden tax. The initial author pays nothing — they understand the context completely, the trade-offs are fresh in their mind, the cleverness feels earned. The next person to touch that code pays the full price, with compounding interest for every month that passes between writing and reading.

I've spent entire afternoons unwinding a single "clever" optimization that saved forty milliseconds and cost the next engineer four hours of confusion. The arithmetic never works out. Clarity is almost always the better investment.

// Clever: saved 40ms, costs hours to understand
const result = arr.reduce((acc, x) =>
  ({...acc, [x.id]: (acc[x.id] ?? 0) + x.value}), {});

// Clear: costs 40ms, saves hours to understand
const totals: Record<string, number> = {};
for (const item of arr) {
  totals[item.id] = (totals[item.id] ?? 0) + item.value;
}

The systems I've watched outlast their original teams — the ones still running years after everyone who built them has moved on — all share this quality of considered plainness. They're not simple because they solved simple problems. They're simple because the people who built them made hundreds of small decisions to resist complexity even when it would have been easier to embrace it.

A poet laureate once told me that the sonnet form — fourteen lines, strict meter, mandatory rhyme scheme — was the most liberating constraint she'd ever worked within. I was twenty-two and working in a startup and I wrote the comment off as romantic nonsense. She was right.

The blank canvas is a lie. Infinite possibility is not the natural habitat of creativity — it's the enemy of it. When everything is possible, nothing is chosen. The creative act requires resistance to push against. Constraints are not the opposite of creativity; they are its precondition.

"The enemy of art is the absence of limitations." — Orson Welles

Designed Friction

The most sophisticated teams I've worked with deliberately introduce constraints into their process. Not budgetary constraints — those are accidents of circumstance. Deliberate creative constraints: you have one week; the interface can have three screens maximum; write the copy in under a hundred words. These teams consistently produce better work than teams with more time, more screens, more words.

The constraint focuses attention in a way that abundance cannot. When you can have anything, every choice is tentative, reversible, second-guessable. When you can only have one thing, the choice becomes serious. You commit. And commitment is where craft begins.

I've been working alongside language models for a year now, integrating them into a design and writing practice that previously had no room for them. The results are not what I expected — not better, not worse, just different in ways that require a different frame to evaluate.

The discourse around AI creative tools tends to collapse into two camps: the evangelists who see artificial general creativity on the horizon, and the skeptics who see a sophisticated autocomplete. Both camps, I've found, are arguing about a tool they've mostly never actually used to make something real, under deadline, for a real purpose.

"The question is never whether the tool is good. The question is whether you are becoming better at using it — and whether using it is making you better at the thing itself." — Field notes, November 2023

What Changed

The first thing that changed was my relationship to the blank page. Not in the way the evangelists would have you believe — I didn't suddenly produce twice as much — but my relationship to starting changed. The dread of the blank page, which every writer knows, softened somewhat. There was a collaborator present at the beginning of things, even if that collaborator was just a mirror showing me early, rough versions of what I was trying to think.

The second thing that changed was my editing. I became a sharper editor because I needed to be. AI output requires evaluation. Not hostile evaluation — it's not adversarial — but the kind of active reading you do when you're reading your own draft after a night away from it. That habit of evaluation bled into my editing of my own work.

There is a texture to work done slowly. You can feel it when you encounter it — in a piece of furniture, in a paragraph, in a user interface. The fingerprints of attention are everywhere. Corners that didn't need to be considered were considered anyway. Every decision made with the confidence that came from not having decided yet.

Speed in creative work is a seduction. The first draft feels like progress. The MVP ships and becomes the product. The rough sketch hardens into the final illustration before it was ready to. Speed mistakes motion for direction. And the cost of that mistake is usually invisible until much later, when the thing must be rebuilt from scratch because the foundation was laid in haste.

"I have only made this letter longer because I have not had the time to make it shorter." — Blaise Pascal, 1657

The Practice of Returning

The single best thing I've ever done for my work is to build in returns. A design reviewed the next morning after being called done the night before. An essay left alone for a week and reread with cold eyes. A system's architecture interrogated again a month after the initial choices calcified.

Returning is not the same as iterating. Iteration is continuous improvement within the same perspective. Returning requires the perspective to change. The distance — time, a night's sleep, a different project in between — creates the critical gap between you-who-made-it and you-who-encounters-it. You need both. The maker builds; the reader reveals what the maker couldn't see.

The work that lasts is the work that was allowed to be slow. Not lazy — slow. Unhurried. Allowed to breathe between revisions. Allowed to be wrong for a while before being corrected. Given the space to become something better than what it was initially intended to be.