What Physics Taught Me About Design Systems

I didn't start in design. I started in physics — the kind of physics that spends weeks on a single problem set just to find the one variable that doesn't change no matter what you do to the system around it.

That habit never left. When I sit down with a new product, the first question isn't "what should this screen look like?" It's "what's the invariant here?" What's the one thing — a user goal, a data shape, a constraint — that has to hold true across every screen, every edge case, every future feature nobody's asked for yet?

Design systems are just invariants made visible. A spacing scale is an invariant. A color token is an invariant. A component's states — default, hover, disabled, error — are a tiny closed system, and if you get the rules right once, you stop re-deriving them for every new screen.

The mistake I see most often (and have made plenty of times myself) is treating a design system as a style guide — a list of approved colors and fonts — instead of as a model of the product's actual behavior. A style guide tells you what things look like. A system tells you what things do, and why, under pressure: what happens when the label is too long, when the API call fails, when a healthcare provider is trying to find one patient record out of eleven thousand at 2am.

The rest of this post is about the specific habits from physics that I think make design systems better.

Find the invariants first#

In physics, the most powerful results are conservation laws — statements about what stays the same while everything else changes. Energy is conserved. Momentum is conserved. Once you know what's conserved, a messy problem often becomes simple.

Products have conservation laws too, even if nobody writes them down:

• User goals. A patient wants to see their results. A driver wants to know when their parking expires. Those goals stay constant across platforms, redesigns, and feature launches.
• Data shapes. An appointment always has a time, a person, and a status. A transaction always has an amount, a direction, and a state.
• Constraints. Regulations, accessibility requirements, and platform conventions don't change because a screen is new.

When you identify these early, design decisions get easier. A new feature isn't a blank canvas; it's another expression of invariants you already understand. And the design system becomes the place where those invariants are encoded once — as tokens, patterns, and components — rather than re-argued for every screen.

Model the system, not the snapshot#

A physics problem is rarely about one moment. It's about how a system evolves: what happens as time passes, as forces change, as conditions move from one extreme to another.

A mockup, by contrast, is a snapshot — one perfect moment with ideal data. The trouble is that real products spend most of their time outside that moment. So I try to model components the way I'd model a physical system: by asking how they behave across their full range.

• What happens at zero items, one item, and ten thousand?
• What happens with the shortest and the longest possible text?
• What happens when data is loading, missing, stale, or wrong?
• What happens on the smallest screen and the largest?

A component that only works at its ideal state isn't a system component. It's a picture of one.

Look for boundary conditions#

In physics, many of the most interesting behaviors happen at the boundaries: the edge of a material, the moment a fluid transitions from smooth to turbulent, the limit as something approaches zero. Boundary conditions often determine the whole solution.

Interfaces break at their boundaries too. Text overflows. Lists become empty. Numbers get too large for their containers. Permissions remove actions a layout assumed would be there. Network connections drop mid-flow.

A good design system defines behavior at those boundaries explicitly:

• Truncation and wrapping rules for every text element.
• Empty, loading, error, and partial states for every data-driven component.
• Minimum and maximum sizes for flexible layouts.
• Fallbacks for missing images, names, and values.

When the boundaries are defined in the system, product teams stop discovering them in production.

Prefer a few general rules over many special cases#

Good physical theories are economical. A small number of principles explains a huge range of phenomena. When a theory needs a new special case for every observation, that's usually a sign it's wrong.

Design systems drift toward special cases constantly. A slightly different button for one page. A one-off spacing value for one card. A new color because the existing ones were "almost right." Each exception seems harmless, but together they erode the system until nobody trusts it.

I try to apply the same economy:

• Before adding a new variant, check whether an existing rule covers the need.
• If the same exception appears three times, it's a signal to evolve the rule, not to keep patching.
• If a rule can't explain a common situation, revisit the rule.

The goal is a system small enough to understand and general enough to cover real work.

Separate what's fundamental from what's derived#

Physics distinguishes fundamental quantities from derived ones. You don't store velocity and position and acceleration independently; some are defined in terms of others.

Design tokens work best the same way. Primitive tokens hold raw values — the full color palette, the spacing scale. Semantic tokens derive from them and describe purpose — text primary, surface raised, border subtle. Component tokens, when needed, derive from semantic ones.

That structure means a single change at the fundamental level propagates correctly everywhere. Switching to dark mode, adjusting a brand color, or tightening density becomes a change of mapping, not a hunt through hundreds of screens.

Test against reality, not just the model#

Every physics student learns this the hard way: a model is only as good as its agreement with experiment. Elegant math that predicts the wrong result is still wrong.

Design systems need the same humility. A component can be perfectly specified and still fail real users. So the system has to be tested against reality:

• Usability tests that use real system components, not idealized mockups.
• Accessibility checks with actual assistive technology.
• Real data — long names, odd values, slow networks — loaded into components before they're published.
• Feedback loops from product teams who use the system every day.

When reality disagrees with the system, reality wins, and the system gets updated.

Systems thinking and craft#

Systems thinking doesn't replace craft. It just means the craft holds up outside the one perfect mockup you designed it in.

The visual details still matter enormously — type, spacing, color, motion. But when those details are anchored to invariants, defined across their full range, tested at their boundaries, and expressed through a small set of general rules, they stop being fragile. They work on the screen nobody designed yet, for the user nobody imagined, in the moment nobody planned for.

That's what physics taught me to look for long before I opened Figma: not the answer to one problem, but the rules that keep holding when the problem changes.