A small set of design principles I keep coming back to

A design principle is only useful if it changes a decision. If it sounds good in a slide deck but disappears under product pressure, it is decoration.

I prefer a small set of principles that can be used in critique, planning, and implementation. They should be plain enough for the whole team to remember and sharp enough to create tradeoffs. "Make it simple" is too broad. "Make state legible" is something we can inspect on a screen.

These are the principles I keep coming back to.

Make state legible

Most product confusion is state confusion. Is this saved? Is this draft public? Is the payment processing? Did the filter apply? Can I leave this page?

I want interfaces to show state before they ask for trust. Loading, saving, disabled, selected, empty, error, warning, and success states should be designed as first-class material, not patched in after the happy path.

In design reviews, this principle turns into direct questions. What happens while the API is slow? What does the user see after the destructive action? Can two states appear at the same time? Does the disabled button explain itself nearby?

The screen gets better because the principle forces us to draw the product's actual behavior.

Keep consequence close to action

The more consequential an action is, the closer its explanation should be. If a button charges a customer, deletes data, publishes a page, emails a list, or changes permissions, the interface should not make the user hunt for the meaning.

This does not always mean adding a modal. Sometimes it means better button copy, a summary row, a reversible action, or a confirmation that includes the object name.

The principle prevents a common mistake: making dangerous actions visually loud but informationally vague. Red is not enough. The user needs to know what will happen.

Prefer reversible paths

Reversibility is one of the cheapest ways to make a product feel humane. Undo, drafts, previews, soft deletes, version history, and cancelable operations reduce the need for heavy confirmations.

When a team asks for another warning modal, I ask whether the action can be made reversible instead. Sometimes it cannot. Payments, legal submissions, and external messages may need explicit confirmation. But many internal product actions can recover.

Reversible paths also help teams ship. A feature that lets users safely correct mistakes can often launch with less defensive UI than a feature that treats every click as permanent.

Match control size to decision size

Small controls are fine for small decisions. They are not fine for decisions that need comparison, context, or confidence.

A tiny dropdown is a poor home for a plan change that affects billing. A hidden kebab menu is a poor home for the primary workflow. A full-page wizard is too much for a preference that can be changed anytime.

This principle helps calibrate UI weight. It asks whether the control's visual and interaction weight matches the decision it carries.

Ship the boring path first

Novel interactions are expensive. Sometimes they are worth it. Usually the product needs the boring path first: clear navigation, obvious forms, reliable feedback, accessible controls, and a layout that survives real content.

This principle is not anti-craft. It protects craft from being spent in the wrong place. A beautiful drag interaction cannot compensate for unclear permissions. A clever onboarding animation cannot compensate for missing empty states.

When the boring path works, expressive details have somewhere solid to land.

Show the material

Digital products are made of constraints: data shape, permissions, latency, content, device size, compliance, and business rules. I like designs that reveal enough of that material to help the user make decisions.

For example, a scheduling product should show timezone boundaries. A checkout should show cost changes. An analytics product should show freshness and sample size. A file tool should show sync state.

Hiding the material can make a screen look cleaner while making the product harder to trust.

Keep principles few

The longer the list, the less likely the team will use it. I would rather have five principles that appear in every review than twenty that live in a Notion page.

Good principles should create productive tension. "Keep consequence close to action" can conflict with "ship the boring path first" if the boring path is a standard confirm modal. That tension is useful. It starts a real design conversation.

The goal is not to create rules that solve every case. The goal is to give a team shared language for better arguments.