Introduction
Most people make the mistake of thinking design is what it looks like…
Design is not just what it looks like and feels like. Design is how it works.
What is this?
This is the design system for my personal website: a consistent foundation of layout primitives, spacing, components, typography, and colours.
A design system is not just a visual theme. It is still software, and like any other well-built software, it needs useful abstractions, conventions, patterns, and practices. It is an opinionated set of building blocks that shapes how the site is built, not just how it looks.
That means defining how components are used and composed, the properties they accept, the constraints they enforce, and the decisions baked into their APIs. Every component has a deliberate surface, with invalid or unintended usage caught in the editor or at build time instead of being discovered at runtime.
On design systems
I have worked with many design systems. Some are well thought out, many are not; too flexible, lacking consistency or principles, built on unquestioned assumptions, undocumented decisions, and no coherent foundation.
Design is as much about what you say no to as what you say yes to. As a result, I have developed strong opinions about how a design system should work.
Many design systems…
- Suffer from too much designer and not enough engineer.
- Never get off the ground because of company politics.
- End up as a mood board with a component library bolted on.
- Accumulate components without establishing clear principles.
- Duplicate instead of compose, growing by addition rather than combination.
- Treat interactive states as an afterthought, if they are considered at all.
- Get built by whichever engineers were available, not whichever engineers were qualified, and it shows.
Some internal design systems at companies are doomed before the first component is written. Nobody owns it; either people have too many opinions or not enough, and the one person responsible cannot get a single engineering sprint approved because it is not tied to a business metric. If you thought the average software project was difficult enough, getting people who can barely operate their email client to care about something called “UI” is a special kind of exhausting.
Everyone is unhappy, and caring about software quality rules out three quarters of the room anyway. The engineers who care, like me, are miserable. The result is a system shaped by the politics and priorities of executives who have never written a line of code, have no opinion on UI worth listening to, and have never once used the product they are somehow in charge of.
Usage
Write about usage here.