UI — the surface of UX.

UI and UX get used interchangeably by people who should know better, and the slippage costs teams real money. The user interface is the visible, touchable layer of the product: the buttons, the type, the spacing, the colour, the way components fit together into pages. User experience is the wider system the interface sits inside — including the interface, but also the architecture, the content, the flow, the error states, the moments where there is no interface at all. They are related, and they are not the same.

The distinction matters because most teams that say "we need to fix our UX" are looking at a UI problem. The fix is a different size, a different team, and a different conversation than "we need to rethink the user experience." Naming what you are actually looking at saves three months of wrong-shaped work. UI is the surface. The surface is where bad UX is visible first, and where good UX has to land. But the surface is not the system.

UI, distinguished from UX.

The cleanest way to hold the two apart: UI is what the user touches; UX is everything that decides whether the touch was worth it. A perfect UI on top of a broken information architecture is a beautifully painted door to the wrong room. A clunky UI on top of a great experience is a product users complain about but keep using, until a competitor ships the same experience with a better surface, and then they leave overnight.

UI is a sub-discipline of UX. A good UX practitioner can articulate the visual system. A good UI designer knows where the experience their surface serves comes from. The titles get blurred in job listings, but the disciplines are different shapes — UI is more graphic, more systematic, more concerned with consistency at the pixel level; UX is more research-driven, more architectural, more concerned with the user's whole journey. The same person can do both. Many designers prefer one. Treating them as identical hides the skill gap until you try to hire.

The five anatomy elements of a UI.

A UI is built from five element classes. Every interface decision lands in one of them. If you can't say which, you don't yet know what you're deciding.

• Typography. The typefaces, sizes, weights, and line-heights the product uses. Type is the most visible carrier of brand personality and the most under-considered. A type system with two typefaces, six weights, and a tight type scale will out-perform a system with five typefaces and forty inconsistent sizes.
• Colour. The palette, contrast ratios, and semantic uses. Colour communicates state (success, error, warning), hierarchy (primary action, secondary action, tertiary), and identity (the brand colour, used sparingly to mean something). Most product UIs collapse because the colour system isn't semantic — every screen invents its own greens and reds.
• Spacing. The grid, the spacing scale, the rhythm. The least visible element to a non-designer and the most felt. A UI on a 4px or 8px spacing scale feels coherent without anyone being able to say why. A UI on no scale at all feels noisy, even when the colour and type are fine.
• Layout. The composition rules. How content flows in a sidebar, a card, a modal, a page. Responsive breakpoints. Container widths. The hierarchy of information on a screen. Layout is where typography, colour, and spacing combine into something the user can read at a glance.
• Components. The reusable units: buttons, inputs, cards, modals, navigation, toasts. Components are the leverage layer: if your component library is sharp, every new screen is fast and consistent. If it isn't, every screen is bespoke, and the surface drifts.

A team can be good at any one of these and weak at the others. The hardest problem is not making each element good in isolation. The hardest problem is making them cohere — which is why design systems exist.

Why design systems exist.

If you treat the five anatomy elements as independent, with each designer making colour choices, each engineer picking spacing, each screen inventing its own button, you get a product where every page looks like a different application. The user notices, even if they can't name what they're noticing, and trust degrades. A design system codifies the elements once, so every team builds with the same vocabulary.

The most useful mental model is layered. Tokens at the bottom are the smallest units, like a specific shade of marigold or an 8px gap. Components in the middle are assembled from tokens: the button, the input, the card. Patterns above that — assembled from components, the form, the dialog, the toast. Pages at the top are assembled from patterns, the actual screens users see. Each layer compounds on the one below.

The "engineering-led UI" anti-pattern.

You see this often in B2B and developer tools: products with strong technical depth and weak surface. Engineers are good at composition and reuse, so they typically pick a library (Bootstrap, Material, Tailwind UI, a Chakra fork), wire the screens together, and ship. The product works. The information architecture might be excellent. But the UI feels like a default — because it is one, and the brand is invisible, the typography is the framework's, the colour is the framework's, the spacing is whatever the framework shipped with.

That is fine for an internal tool and a problem for a customer-facing one. The fix isn't more engineers. It's a designer (or design partner) with the brief to take ownership of the five anatomy elements, lay down the token layer, customise the components, and turn the framework into your framework. Done well, it is one to three months of focused work. Done not at all, it slowly capped the product's perceived quality forever.

The "design-led without engineering" anti-pattern.

The mirror. The team has a designer (or agency) producing beautiful Figma files. The screens are immaculate. The system is documented. Then it lands in code, and the engineers can't build it as designed — the components don't exist, the spacing is bespoke, the typography uses fonts that aren't licensed for web. Each screen takes three times as long as estimated. After two sprints of that, engineering quietly stops following the designs and ships approximations.

The cause is the missing seam between the design system as a Figma file and the design system as a component library in code. They have to be the same artefact, expressed at two fidelities. Token names match. Component names match. When a designer adds a variant in Figma, the engineer can find the matching prop in the library. When that seam doesn't exist, designers and engineers are working from different sources of truth, and the UI drifts.

The fix is institutional: design and engineering co-own the system. The token names are agreed between them. The component library in Figma and the component library in code are versioned together. Neither discipline ships a new pattern without the other.

The compound layers, in practice.

Building bottom-up is the only sequence that scales. Token first: your colour palette, type scale, spacing scale, all named, all versioned. Components next, every component drawn from token references, never from raw values. Patterns next, assembled from components. Pages last — assembled from patterns.

The order isn't aesthetic preference. It is the only order in which a design change at the bottom (rebrand, dark mode, density change, accessibility uplift) propagates upward automatically. Build top-down and your dark mode is a three-month rebuild. Build bottom-up and your dark mode is a token-swap and a regression pass, a fortnight, not a quarter.

Most teams I see have layers two and three (components, patterns) and skip layer one (tokens) entirely. Every component hardcodes its own colour and spacing values. The result is a component library that looks like a system and behaves like a pile of disconnected files. Every design change is global manual rework. The fix isn't to rebuild the components. It is to extract the tokens out of them, name them, and reference them. Boring three weeks. Pays back forever.

How we use this at Product Pieces.

When a partner team brings us a UI problem (drift, inconsistency, complaints about visual quality, designers and engineers blaming each other), the first thing we do is name the layer the gap is at. If the tokens don't exist, no amount of work at the page layer will produce coherence. If the tokens exist but the components don't reference them, the system is theatrical. If both exist but design and engineering aren't co-owning them, the seam is broken.

Most of the work is unglamorous: get the five anatomy elements down to one named version each, build a token layer, refactor the components against it, and put design and engineering on the same release cadence for the system. Six to ten weeks of that and the UI stops drifting. Not because the team got more careful — because the system finally rewards them when they are.

Next issue: N°10 — CX. The full arc, beyond the screen.