UI Design Built as a System, Not a Set of Screens

What is a design system and do we need one?

A design system is a set of shared foundations and components with rules for using them — not just a component library, but the decisions about type, spacing, color and behavior that everything else inherits from.

You need one if more than one person will make design decisions, or if the product will keep growing. Below that threshold — a small brochure site designed once by one person — a system is overhead you may not recover.

The signal that you needed one and did not build it is recognizable: four button styles, three shades of the same gray, spacing that varies by a few pixels between similar sections, and nobody able to say which version is correct.

Why do designs look different once built?

Almost always because states and edge cases were not designed, so the developer made reasonable guesses. A design file typically shows the ideal case: perfect content length, no errors, nothing loading, nothing empty.

Real interfaces spend a lot of time in the other states. A button being pressed, a form field in error, a list with nothing in it, a name three times longer than the placeholder. If those were not designed, they were decided in code.

The other cause is values rather than states. A design with spacing that varies arbitrarily gives a developer nothing to implement, so they build to a grid — and the result is close to the design without matching it. Tokens fix that by making the values explicit.

How does UI design affect conversion?

Through clarity and speed rather than through beauty. Interfaces convert better when the next action is obvious, the form is short enough to be worth completing, and nothing about the page makes the reader hesitate.

The specific levers are practical: visual hierarchy that makes the primary action unmistakable, contrast high enough to read on a phone outdoors, tap targets big enough to hit reliably, and error handling that tells someone how to fix the problem rather than that one occurred.

It is worth being honest about the limits. UI improves the conversion of traffic that already wanted the thing. If the offer is wrong or the UX structure makes the task confusing, a better-looking interface does not fix it.

Should UI design come with the code?

Not necessarily, but the handoff has to be specific enough that the code can match it without negotiation. A flat mockup and a color picker is not a specification.

What makes handoff work is named tokens rather than raw values, every component state designed, responsive behavior stated per component, and documentation covering when to use what. With those, any competent front-end team can implement the system faithfully.

Where design and build sit with the same team there is less to lose in translation, which is why we brief our own development work from the same tokens. But a well-specified system should survive being handed to someone else entirely — that is the test of whether it is a system or just a set of pictures.

What makes a design system worth building?

Repetition. A system is an investment that pays back through reuse, so the question is whether there will be enough of it.

For a five-page site that will not change, formal tokens and a component library are overhead. For a product that will gain features for years, or a site where a marketing team builds pages weekly, the same work saves more than it costs within months.

The value shows up in two places. In build, because a component is implemented once rather than approximated repeatedly. And in consistency, because the decisions are made once by a designer rather than each time by whoever is under deadline.

What makes systems fail is scope. Teams try to design every component before building anything, and the system becomes a project of its own that never quite finishes. Starting with the components the current work needs, and growing it from real use, is the version that survives.

Why do built interfaces drift from the design?

Because the design specified a subset of reality and the build had to cover all of it.

The most common gap is states. A design shows a button; the build needs default, hover, focus, active, disabled and loading. If only one is specified, five are invented, usually inconsistently and usually under time pressure.

The second is content variance. A card designed with a two-line title meets a six-line one on the third page. A list designed with four items meets forty. These are not edge cases; they are Tuesday, and they are what makes a built site look less considered than its design.

The third is tokens. When values are measured from a mockup rather than named, they drift. Two blues that differ by a shade, three spacing values where one was intended. Individually invisible, collectively the reason a site looks slightly off without anyone identifying why.

How should typography be decided?

As a small scale applied consistently, rather than a size chosen per element. The consistency is what reads as quality; the specific sizes matter far less than people expect.

A workable scale is a handful of sizes with defined weights and line heights, each with a role — page title, section heading, subheading, body, small print. When something needs emphasis, it moves to an existing step rather than getting a new value.

Line length is the most neglected decision and one of the most consequential. Text that runs the full width of a wide screen is measurably harder to read, and constraining the measure improves comprehension at no cost.

Web font loading is where typography meets performance. Every additional weight is a download, and a page that shifts as fonts arrive is a layout stability problem. Choosing fewer weights, and specifying a fallback with matching metrics, is part of the type decision rather than a build detail.

What does good handoff look like?

A named set of values, every state of every component, rules for responsive behavior, and someone available while it is built.

Named values first. A developer should never measure a spacing gap or sample a color from a mockup, because measured values drift and sampled colors multiply.

States next, all of them, including the ones nobody enjoys designing. Empty states in particular — what a list looks like with nothing in it is a real screen that real people see, most often on their first visit.

Responsive rules expressed as intent rather than as fixed screenshots. "These cards wrap when they would be narrower than 260 pixels" is implementable at any width. Three static layouts leave everything between them undefined, and that is where most of a visitor's time is spent.

How does interface design affect performance?

More than most design conversations acknowledge. Several decisions made in a design file have direct, measurable costs at load time.

Images are the largest. A design specifying full-width photography at every section commits the build to shipping that weight, and no amount of optimization makes a large image small. Deciding which images earn their place is a design decision with a performance consequence.

Fonts are next. Each family and weight is a request and a potential layout shift. A design using four weights of two families has made a performance decision, whether or not it was discussed as one.

Then layout stability. Designs that do not reserve space for images, embeds or content that loads late produce visible shifting, which Google measures as Cumulative Layout Shift. Specifying dimensions at design time prevents an entire category of problem — which is why we treat it as part of the design rather than as a technical SEO fix afterwards.

How do you design empty and error states?

As real screens with a job to do, because they are what people see at the two moments that decide most about the experience.

The empty state is the first thing a new user sees, and treating it as an absence wastes the most attentive moment you will ever have. A screen that explains what will appear here and how to get the first item is doing onboarding without a tour.

There is more than one kind. Nothing yet, nothing found, and nothing left are different situations needing different responses, and designs that use one message for all three confuse the person who filtered too narrowly with the person who has not started.

Error states need to say what happened and what to do, in that order, without blaming the person. "That email address is already registered — sign in instead?" is useful; "invalid input" is not.

And the work has to survive. An error that clears a form someone spent minutes filling is the single most reliable way to lose them, and it is a design decision rather than a technical inevitability.