The small decisions

Most of my work in an ordinary week isn't a big redesign. It happens in the details. Deciding whether a margin should be 16 or 24 pixels. Choosing whether a notice should be blue or grey. Defining whether a progress line advances smoothly or step by step.

None of these decisions seems particularly interesting on its own. But together, they decide whether a product reads as considered or careless.

I tend to log these small calls. Not the big presentations or the projects that become case studies. The small ones. Recently, three of them ended up pointing to the same principle, and that's what made me write this down.

Don't invent a value the system already names

A set of drawers had lost their consistency. The header sat 16px from the edge, the form fields used 4px, and the footer followed yet another measure. The result was a subtle but constant misalignment.

The fix wasn't to pick a new number. It was to notice the answer already existed. The header had set the anchor: 16px. All that was left was to pull everything else to that same point of reference.

Often the value isn't missing. It just stopped being respected.

The same thing happened with color. A support notice in one flow used a mix of neutral tones with a pale blue icon. But the product already had a visual language for informational messages. Instead of creating an exception, the better decision was to reinforce the existing pattern.

The whole notice came to belong to the same visual family: background, text, and icon sharing one meaning.

When the system already has an answer, inventing another one usually adds noise, not clarity.

Make the indicator honest

At another point, I needed to revisit a stepper. The numbered circles already existed, as did a separate progress bar. I added a visual connection between the steps to reinforce the sense of continuity.

The most obvious solution was to fill that line gradually, tracking a percentage. But it suggested something the user hadn't finished yet.

I chose to fill one step at a time.

Because a step is either complete or it isn't. The indicator has to reflect the current state exactly, without exaggerating progress or creating a more optimistic perception than reality.

The inactive line took the most discreet tone available in the system, using the same token applied to dividers. The goal was simple: keep the track quiet until progress actually happened.

Fix it where the change propagates

The three situations had something in common: all of them were tied to shared components.

So the fixes also had to happen at that level.

Adjusting the component means the next screen is already born right. Fixing only the specific interface solves a one-off problem but preserves the cause.

There's an important difference between a patch and a fix.

A patch leaves one screen right.

A fix leaves the next ones right before they're even built.

The reason matters more than the decision

None of these changes was revolutionary. And that's exactly the point.

The decision itself is usually cheap. What's expensive is the reasoning that led to it. And that's almost always the first thing to disappear.

A few months from now, those 16 pixels will be just a number inside a file. Someone, maybe me, will consider dropping it to 12 because they need to win space somewhere.

When we log the small decisions, we preserve the context that holds them up.

The note stops saying just "use 16px" and starts explaining why: because the header defines the alignment anchor. Remove that reference, and the inconsistency comes back.

In the end, most of design doesn't happen in grand gestures. It happens in the disciplined repetition of small choices.