Design Principles: Creation & Governance

The full lesson

Most design teams have principles. Very few have principles that change how anyone actually works on a Tuesday afternoon when no senior designer is in the room. The gap between a wall poster and a working decision-making tool comes down to two things: how you write the principles, and how you maintain them. That is what this lesson covers.

Good design principles sit at the crossroads of product strategy, brand identity, and day-to-day craft. Written well and maintained deliberately, they compress complex trade-off discussions into shared vocabulary. They help new designers get up to speed faster. They also give cross-functional partners — engineers, PMs — a way to evaluate work even when the original designer is not in the room.

What Makes a Principle Actually Work

A design principle is a short, opinionated statement that helps a team choose between two reasonable options. That definition contains everything important. It must be short so it is memorable. It must be opinionated so it rules things out. And it must be actionable so it resolves real choices — not just sounds good.

The classic test is the tension test: can your principle be violated by a plausible, well-intentioned decision? If not, it is a value statement, not a principle. “We care about users” fails this test. “Reduce cognitive load before adding features” passes — a PM can legitimately disagree with it, which means it does real work.

The three failure modes

Failure mode	What it looks like	Why it happens
Motherhood statements	”Be simple, clear, and delightful”	Written in a workshop to please everyone
Laundry lists	12 principles covering everything	No prioritization; every trade-off is unresolved
Vague imperatives	”Focus on the user”	No specificity about which users, what situations, or at what cost

A Creation Process That Generates Real Principles

Step 1 — Mine real decisions, not aspirations

The best source material is past decisions your team already made well under pressure. Run a decision archaeology session. Ask each designer to bring two or three product decisions they are proud of, plus two they disagreed with at the time but now respect. Then extract the implicit reasoning — “we chose X over Y because…” — and look for recurring themes. Those patterns are your raw principles.

Other good sources:

• Recurring points of tension in critique sessions
• Onboarding moments where new hires got confused about “how we do things here”
• Cases where engineering or PM partners pushed back on a design call and you could not clearly explain why you were right

Step 2 — Draft with a specific structure

A principle with only a label (“Clarity over cleverness”) is better than nothing. But a three-part structure makes it much more useful in practice:

1. Label — short and memorable, often a contrast or verb phrase
2. One-sentence elaboration — what the label means in your specific context
3. This means / this does not mean — concrete examples that clarify the edges

Here is an example using this structure:

Earn every interaction Every tap, scroll, or input we ask of users must return more value than the effort it costs. This means: default to showing information rather than hiding it behind an action; surface the answer before asking for a query. This does not mean: never use progressive disclosure — depth is fine when the primary need is already met on the surface.

Step 3 — Validate with counter-examples

Before finalizing a principle, think of three real product decisions that would have gone differently if the principle had been in force. If you cannot find any, the principle is either too weak or already built into everything you ship.

If all three counter-examples feel like obvious mistakes in hindsight, the principle captures wisdom the team has already internalized. Writing it down still adds value — it makes that wisdom explicit.

If a principle would have reversed a decision you are proud of, either the principle needs refining, or it reflects genuine disagreement in the team. That discovery is actually the most productive outcome a creation workshop can produce.

Step 4 — Stress-test for scope and stack rank

Three to seven principles is the practical range for a product team. Fewer than three and you have slogans. More than seven and no one can hold them in working memory during a critique.

When two principles conflict — and good ones will — make the hierarchy explicit. Google’s original Android design principles had an ordering: “Enchant me” ranked above “Simplify my life,” which ranked above “Make me amazing.” That ordering resolved a whole class of trade-offs without needing a meeting.

Integrating Principles into Daily Work

Written principles become living ones only when they show up at the moments decisions actually happen — not in a one-time all-hands presentation.

Critique integration

Make principles the explicit evaluation rubric in design critique. Instead of “does this feel right?”, open with “which principle is most at stake in this design?” This forces specificity and prevents the usual dynamic where the loudest opinion wins.

A lightweight format that works well: after presenting the brief and the work, the presenter names the one or two principles most tested by the design. Reviewers anchor their feedback to those principles before introducing new angles. This dramatically reduces scope creep in critique and gives junior designers a structured path into the feedback conversation.

Hiring and onboarding

Include one or two principle violations in design portfolio reviews or take-home exercises — deliberately. You are not looking for the “correct” answer. You are looking for whether candidates notice the trade-off and can articulate their reasoning. This tests both craft judgment and culture fit at the same time.

During onboarding, have new designers find the principle that would have changed an existing shipped feature, then present their analysis. The goal is not to relitigate past work. The goal is to build the habit of applying principles under time pressure.

Token and component decisions

Design system decisions are where principles do some of their most leveraged work. When a component team debates whether to expose a prop for custom typography overrides, the answer should flow from a principle (“Opinionated defaults, obvious escape hatches”) rather than a gut call. Document the principle that drove each significant system decision in the component’s history log. This pays dividends when the decision gets revisited a year later with a new team.

Governance: Keeping Principles Alive at Scale

Creation is a one-time sprint. Governance is the ongoing work that determines whether principles still matter at year three.

Ownership and amendment process

Every principle needs a clear steward — typically the design system team or a design leadership group, not a single individual. The steward monitors for principle drift, collects case studies of principle application, and runs the annual review cycle.

Amendment should require evidence, not just opinion. A principle is ready for revision when:

• It has been cited as justification for opposing decisions in the same quarter
• It was written before a significant product pivot and no longer fits the current context
• It is consistently overridden in practice — meaning teams are already operating on a different, unarticulated principle

An amendment proposal should include: the original principle, at least two real cases where it fell short, the proposed revision, and the decision cases that would resolve differently under the new version.

Documentation and discoverability

Principles must live where designers work, not in a separate tool that requires a context switch. Modern practice embeds them in:

• Design system documentation platforms (zeroheight, Supernova, or Storybook with MDX) co-located with component guidelines
• Figma file descriptions and cover frames so they are visible during the design phase itself
• Living decision logs — a lightweight record of significant product decisions annotated with which principle drove the call

The outdated approach — a static PDF style guide or an isolated Figma page titled “Brand Principles” — decouples principles from the work and guarantees they go stale. When documentation drifts from practice, teams stop trusting either.

Scaling across disciplines

As organizations grow, design principles interact with — and sometimes conflict with — engineering principles, product principles, and brand guidelines. Governance at scale requires an explicit interface between these bodies of work.

A practical structure:

Level	Owner	Scope	Review cadence
Product principles	CPO + design leadership	Strategic trade-offs at the product level	Annually, aligned with strategy cycle
Design principles	Design system / Head of Design	Craft and interaction decisions	Semi-annually
Component conventions	Design system team	Specific UI patterns and token choices	Quarterly or on-demand

Principles at higher levels should inform — but not duplicate — those below. A product-level “User trust above growth metrics” should be visible in the design principle “Never obscure costs or defaults,” which in turn should be visible in the component convention “Opt-in checkboxes unchecked by default.”

Measuring principle health

You cannot improve what you do not measure. Leading indicators that governance is working:

• Citation rate — principles are invoked by name in critique notes and Jira/Linear tickets
• Dispute resolution time — design disagreements that invoke a principle resolve faster than those that do not
• Onboarding velocity — new designers apply principles accurately within the first month (measurable with a lightweight rubric-based portfolio review)

Lagging indicators of governance failure: principles are absent from critique notes; new hires describe the team’s approach in ways that contradict the stated principles; the system team introduces components that violate a principle without noticing.

Principles vs. Guidelines vs. Standards

These three terms are often conflated, and that confusion has real operational cost.

Term	Character	Violation consequence	Example
Principle	Opinionated heuristic, requires judgment	Requires justification, not an immediate fix	”Earn every interaction”
Guideline	Best-practice recommendation	Deviation is acceptable with rationale	”Use sentence case for button labels”
Standard	Non-negotiable requirement	Flagged as a defect	”All interactive elements meet WCAG 2.2 AA contrast”

Treating standards as principles (“we value accessibility”) creates compliance risk. WCAG 2.2 AA contrast is not a heuristic — it is a legal baseline in many jurisdictions. Treating principles as standards (“you cannot add a feature that adds one step to this flow”) destroys the creative latitude that principles are supposed to protect. Keep the vocabulary precise in documentation and in critique.

Antipatterns to Retire

Several governance antipatterns are common enough to name explicitly.

The workshop artifact that never ships. Principles written at an offsite and never integrated into critique, hiring, or documentation. They exist in a Miro board and nowhere else.

Principles as culture values. Conflating behavioral values (“we are honest,” “we take ownership”) with design craft principles. These answer different questions and belong in different documents.

Rewriting at every leadership change. Principles that survive one head of design but get rewritten wholesale when a new one joins. This signals the principles were personal taste, not organizational learning. Governance should make principles resilient to personnel change.

Retroactive justification. Using principles after the fact to explain decisions already made on other grounds. Reviewers notice this quickly, and it destroys the credibility of both the principles and the person invoking them.