A short list of statements that determine how your team resolves disagreements — if they're written well.

Design principles are a set of concise guiding statements that articulate how a product should feel, behave, and make trade-offs. They exist to help teams resolve design disagreements consistently — and to align people who are building the same product but making different micro-decisions about it every day.

The best design principles are specific enough to rule things out. A principle that says "be simple" doesn't help anyone make a decision. A principle that says "one primary action per screen — if you're tempted to add a second, reconsider the task structure" is actionable. The first tells the team how they feel about the product; the second tells them how to build it.

These three things exist at different levels of abstraction:

• Design principles articulate intent and values: why the product behaves a certain way and what trade-offs it makes.
• Design guidelines specify how to implement those principles: always show a confirmation before a destructive action, use 44px minimum touch targets.
• Design patterns (in a Design System) are the reusable components and interactions that implement the guidelines.

All three are useful. Conflating them produces documents that try to do too much at once and end up guiding nothing. Principles that read like guidelines, or guidelines that are really just patterns with a values wrapper, don't function as either.

Good design principles share a few properties:

They're opinionated. A principle everyone agrees with hasn't resolved any tension. The best principles encode a genuine trade-off: "speed over comprehensiveness" is useful because it tells teams to cut features when in doubt. "Be fast and comprehensive" is a wish list.

They're specific to the product. Generic principles — "intuitive," "consistent," "delightful" — could apply to any product. Principles worth writing are specific to the context, the user, and the tensions the team actually faces.

They're memorable. If your team can't recall a principle without looking it up, it's not influencing decisions.

When they work, design principles function as shared decision-making infrastructure. In a design review, a principle can cut through subjective debate: "this adds three steps, which works against our principle of reducing friction at the point of action — so we need a strong reason to include it."

When they don't work, they're a document that got approved in a workshop and never referenced again. The failure mode is treating principles as a brand exercise rather than an operational tool. Principles need to live inside the team's actual working rituals — referenced in Design Sprint planning, in handoff reviews, in retrospectives. A principle that only exists in a Figma file nobody opens isn't a principle; it's a placeholder.

A few practical checks for any principle you're considering:

• Does it help resolve a real disagreement the team has had in the last six months?
• Can you describe a specific design decision you'd make differently with this principle than without it?
• Does it conflict with anything? If it doesn't, it's probably not opinionated enough.
• Could someone outside the team read it and understand what you're willing to trade off?

Start with the tensions the team actually argues about, not with abstract values. Principles written to resolve real conflicts outlast principles written to articulate ideals — because they stay connected to the work rather than drifting into aspiration.