Every now and then, someone brings up the idea of design principles.

The team wants alignment. They want to move faster. They want clarity when everything’s blurry. And so we create principles—clean phrases meant to guide how we work and what we value.

But most of the time, they don’t land.
They get written, maybe even celebrated with high-fives all around, and then quietly ignored.
No one brings them up in critiques. They don’t inform tradeoffs. They don’t show up in design reviews or roadmap decisions.

They live in Notion. Or on a slide in a Q2 offsite from 2 years ago.

And then leadership somehow remembers about them and tries to “enforce” them.
Which is usually a sign the whole exercise already failed. It was a line item in an agenda that someone got to check a box on.

Why Most Principles Fall Flat

Principles tend to fall into a few traps:

• They’re too vague to be useful. (“Delight the user” doesn’t help me choose between clarity and cleverness—and duh!)

• There are too many. People remember three things, not nine.

• They’re aspirational, not operational. (“Craft over speed” sounds good until you’re racing to hit a deadline.)

• They don’t reflect the actual tensions teams navigate day to day.

They end up being brand slogans. Not decision-making tools.

Good Principles Help You Choose

If a principle isn’t helping you make a tough call, it’s not doing its job.

A good principle is a knife.
It cuts through indecision. It sharpens your thinking.

Some patterns that work:

• Tradeoff framing. “Clarity over cleverness.” “Bias to ship, commit to learn.” These force a choice.

• Grounded in context. A design system team shouldn’t have the same principles as a growth team.

• Short and sayable. If you wouldn’t say it out loud during critique, it’s not sticky enough.

You know you’re onto something when a junior designer can use a principle to defend their decision—and you agree.

You Don’t Enforce Principles. You Normalize Them.

If your team needs a cop to uphold your principles, they’re not principles. They’re rules in a shiny Figjam wrapper.

Principles should show up without prompting.

How that happens:

• They get baked into critique. Not as a checklist, but as a lens.

• They get used in tradeoffs. You hear, “We went with option B because it leans into X principle.”

• They’re modeled. Senior folks walk the talk, even when it’s inconvenient.

• They get tested. And sometimes revised. Because teams grow. Products change. Context shifts.

It’s not about control. It’s about fluency.

The goal is not that everyone memorizes your principles.
The goal is that they act on them without needing to.

How You Know They’re Working

Here’s what I look for:

• People reference them without being asked.

• Engineers use them to argue for design decisions.

• They get invoked when things are messy—not just when they’re clean.

• They evolve naturally as the team matures.

Good principles aren’t static. They grow with the product. They reflect what the team’s learned. They help shape how the team learns next.

And when they’re real, they don’t need enforcing.

They enforce themselves.