Simplicity by Design: why systems beat one-off decisions

There’s a common assumption that a more sophisticated product needs more decisions baked into it: more configuration, more edge cases handled explicitly, more one-off choices made along the way. In practice, the opposite tends to be true. The systems that hold up well over time usually aren’t the ones with the most decisions inside them: they’re the ones where a handful of decisions were made once, properly, and then reused everywhere else. Simplicity, in other words, isn’t the absence of effort, but it’s effort spent upfront, on the system, instead of spent repeatedly, on every individual case.
Some examples from very different parts of a product make the same point.

Structure: what atomic design gets right

Atomic design, Brad Frost’s now near-standard approach to building UI, is really just this principle applied to interface structure. Instead of designing every screen from scratch, teams define a small set of building blocks (atoms, molecules, organisms) once, and assemble everything else from them. The alternative, designing screen by screen without a shared structure, feels faster at first and becomes noticeably harder to maintain as a product grows, because every screen ends up as its own accumulation of small, undocumented decisions.

Colour: a system, not a shade picked per screen

The same logic applies to something as ordinary as colour. It’s tempting to choose a shade wherever it’s needed — a slightly different grey for this card, a slightly stronger blue for that button — and each individual choice can look perfectly reasonable in isolation. The problem shows up later: a colour that reads fine on a light background quietly fails contrast requirements on a darker one, or a palette that looked balanced in a mockup turns out to be genuinely hard to read for a meaningful share of users. WCAG’s contrast guidelines exist precisely because “it looks fine to me” isn’t a reliable test.
A more resilient approach treats colour the way atomic design treats components: define the contrast rule once — a minimum ratio between text and background, checked against every theme and breakpoint a colour will actually appear in — and let the palette be generated and validated against that rule, rather than picked case by case. It takes longer to set up. It’s considerably harder to accidentally ship an unreadable screen once it exists.

Where AI actually helps

This is also where AI earns its keep, and it’s a narrower job than it’s often given credit for. AI is genuinely good at running the repetitive checks a system like this requires at scale, flagging a colour pairing that fails contrast, spotting a component that has quietly drifted from the rest of the design system, catching inconsistencies before they ship. What it isn’t well placed to do is decide what the standard should be, or when an exception is actually worth making. That judgement — how strict a contrast rule needs to be for a specific audience, whether a component genuinely needs a new variant or should be merged with an existing one — still belongs to a person who understands the product. AI is a good enforcer of a system. It’s a poor author of one.

COMMpla: structure over complexity

When starting a new system, resist the urge to define every value upfront. Write down the two or three rules it must never break — a minimum contrast ratio, a fixed spacing scale, a small set of component states — and let everything else be derived from those rules rather than decided individually. A system with a handful of firm constraints stays simple. A system with a hundred upfront decisions is just complexity wearing a different outfit.

Whether it’s structuring an interface, building an accessible colour system, or deciding where automation genuinely helps a design or development process, the common thread is the same: simplicity has to be designed, not assumed. It’s a problem we work through regularly across COMMpla’s UX/UI and software development projects. If you’re looking to bring more structure — and less accidental complexity — into your next product, get in touch with our team or visit our website to find out more.

Marco Carollo | Full-stack Developer