All articles
A Design Principle Should End an Argument

A Design Principle Should End an Argument

How to write principles your team actually uses

Paul van Oijen
·5 min read·Design Leadership

Most design principles are bad.

Not wrong. Not actively harmful. Just bad. Too vague to decide anything. Too aspirational to argue with. Too safe to be wrong.

You've read them. "Be bold." "Design for humans." "Start with why." Put those three next to each other and tell me which one I'm supposed to use when my product manager and my engineering lead disagree about where the primary button should go.

That's the test. A good principle should end the argument. If you can't use it to make a decision when two smart, reasonable people disagree, you don't have a principle. You have a poster.

Principles are written backwards

Early in my career I wrote a beautiful set of design principles for a product I worked on. Six months later, when the team was arguing about a redesign, nobody cited them. Not once. They weren't being defied. They were just useless.

Here's how most teams end up there.

Someone schedules a workshop. The team brainstorms words. They pick five or six that feel true. They massage the words into sentences. They put the sentences on a Figma board. Someone offers to put them on the office wall.

The whole process starts with the wrong end of the question. It starts with "what words do we like?" It should start with "what argument keeps happening?"

Design principles are retrospective, not aspirational. They're the written form of patterns you've already decided on — patterns that should have been obvious, but somehow had to be relearned every time. The purpose of writing them down is to stop relearning.

The keyword rule

If I can swap your principle into any other product's design doc and nothing changes, your principle is too general to be useful.

"Be delightful" works for Slack, a burial plot marketplace, or a nuclear plant control room. That's not a strength. That's a tell.

Specific principles name something specific. Shopify has a principle along the lines of "Strong opinions, loosely held." That isn't decorative. It's a real guideline for how to run a critique and when to update your position. You can use it to close a debate: "We decided that last quarter and the arguments haven't changed, so we're moving forward." Or to reopen one: "New data came in. Old opinion should update."

Compare that to "Be bold." Bold how? Bold in color? Bold in scope? Bold enough to ship a controversial feature, or bold enough to kill one? "Be bold" is a vibe. It doesn't end arguments. It just makes people feel like they're winning them.

A better process

Here's the process I use with teams in the workshop.

Start from real decisions, not words. Take ten design decisions your team made in the last six months. Ship decisions, kill decisions, edge cases you had to argue about. Write each on its own card.

Find the pattern. Most teams will see two or three recurring themes across the cards. The recurring ones are candidates for principles. The one-offs aren't principles; they're just decisions.

Write the rule, not the vibe. For each pattern, try to write a sentence that would have ended the earlier debate. "When density and legibility conflict, legibility wins." "We don't ship a new flow without a way for a user to escape it." "An edge case above 0.5% of users gets treated as a case, not an outlier." These don't sound inspirational. That's correct. They're meant to be used, not quoted.

Test against live arguments. Take a debate that's open in your team right now — a real one, with both sides still believing they're right — and apply the candidate principle. Does it resolve the debate? If yes, keep it. If no, you either need to sharpen the principle or admit it isn't really what you believe.

Prune hard. Most teams end up with more principles than they need. Five is a lot. Three is better. A principle you can't remember when you're arguing at 5pm on a Thursday is a principle that doesn't exist.

What principles are not

A short list, because these get confused constantly.

Principles are not values. Values are what you care about. Principles are how you decide.

Principles are not brand voice. Brand voice tells you how to write marketing copy. Principles tell you what to ship.

Principles are not a manifesto. A manifesto is written to announce. A principle is written to adjudicate.

Principles are not aspirational. Aspirational principles describe the team you wish you were. Real principles describe the team you are on your sharpest days, so you can be that team more often.

The test, again

It's genuinely hard to do this on your own. It's easy to spot vague principles when they're somebody else's. It's very hard to spot them in your own draft, because they feel meaningful to the person who wrote them.

The test is brutal but clean: would this principle end an argument you're actually having, or would both sides claim it supports their position? If both sides would claim it, you don't have a principle. You have the absence of one, dressed up in nice words.

Good principles don't make your team sound better. They make your team decide faster. That's the whole point.


If the critiques on your team keep looping, or you're building a design system and need a conceptual foundation before you pour a year of engineering into it, that's the specific problem the Design Principles workshop is built to solve.

Related Articles