On Design Entropy

Lately I keep coming back to the idea of design entropy, because it describes something I run into in almost every design system I work on.

In physics and information theory, entropy is the tendency of a system to drift toward disorder, toward more and more possible states. The fewer constraints on where a system can go, the less predictable it becomes. Design systems behave the same way.

A system usually starts clean. The type scale is defined, spacing follows a rhythm, components feel related, colors have clear roles. There’s enough structure that decisions feel intentional. Then variation creeps in. A local override to solve one screen. A component duplicated and tweaked. A new section with its own spacing. Type that diverges in small ways.

None of these feel like a problem on their own, and most are perfectly reasonable in the moment. The trouble shows up later, when the system has quietly lost its coherence. Components still look familiar but behave differently. Patterns stop being interchangeable. New decisions take longer because the existing ones no longer guide you. The system is still there, it’s just harder to read and harder to trust. That slow slide away from coherence is what I think of as design entropy.

How design entropy creeps in

Design entropy almost never comes from one big mistake. It accumulates over time through small practical decisions that most of the times are made under pressure. A project grows, pages get added, deadlines tighten. You adjust a component locally because it’s faster than fixing it at the source. You hardcode a spacing value to handle an edge case. You introduce a one-off that never makes it back into the shared language. Every step is defensible. The sum is a system carrying more uncertainty than it should.

It helps to be specific about what pushes a system in each direction.

What raises entropy

• Inline styles and local overrides. Every hardcoded value lives outside the shared system logic. It works today and quietly becomes an exception nobody can see tomorrow. Enough of those overrides and the system slowly stops being the source of truth.
• Clients editing the live site. Well-meaning edits from people who don’t hold the system in their heads introduce one-offs fast. The site keeps working, but the coherence erodes underneath it over time.
• AI agents without guardrails or skills. A model with no constraints generates across a nearly infinite space. It produces something that looks right and relates to nothing around it. Speed without context is just faster entropy.
• Deadline pressure. Shortcuts are entropy on credit. Each one is reasonable in the moment and compounds later, usually when someone else inherits the file.
• Too many hands, no shared vocabulary. More contributors without shared conventions means more independent interpretations of the same pattern, all slightly different.

What lowers it

• A documented design system. A single source of truth means most decisions are already made. People compose from what exists instead of re-deriving the same choices, and the documentation keeps the reasoning from living in one person’s head.
• Curated, pre-selected material. A library of vetted patterns lowers entropy far more than generating each screen from scratch. You assemble from a known, finite set instead of inventing from an open one. Fewer possible states, more coherence. This is also why a model handed good patterns behaves better than one asked to improvise.
• Design discipline. The system only works if people actually use it. The restraint to reach for the token, the pattern, the existing component instead of the quick one-off is what keeps entropy from creeping back. Do not route around your system.
• Semantic abstraction. Naming things by intent rather than by raw value means a change propagates predictably and nothing is pinned to a magic number.
• Constrained tooling. Tools that expose a sensible set of choices instead of every possible one keep people on the rails by default, without anyone having to think about it.

Designing for low entropy

Our tools accelerate entropy as easily as they reduce it: page builders and generative AI can both spin up a system fast, but speed without constraints just produces a faster mess. Structure is what absorbs that complexity. A design system is less documentation than an operating environment, narrowing the decisions you make from scratch while leaving room for useful variation. That matters most with AI in the loop, where a well-structured set of tokens and patterns gives a model somewhere coherent to compose inside instead of inventing from nothing. The output improves not because the model got smarter, but because the environment around it did.

Constraints don’t kill creativity

None of this means stripping out expression. In most disciplines, whether architecture, music, writing, or design, creativity depends on constraints. The boundaries are what make variation mean something. A design system works the same way. Its purpose isn’t to flatten how you design. It’s to remove the unnecessary chaos so the meaningful choices stand out.

And maybe that’s why the idea feels so relevant lately. As our tools get faster and more generative, coherence becomes one of the most valuable things a system can hold onto.

Hope you found this useful. Ping me on X if you’ve got thoughts.