A visual identity usually arrives as a PDF: logo, palette, two typefaces and a few mockups. It is a good starting point, but on screen it covers very little. A website has to decide what color a link is, what a disabled button looks like, how a form error appears, what happens when a heading is twice as long as planned, and how all of that looks in dark mode. When nobody makes those decisions up front, deadline pressure makes them, one page at a time.
This post is about that transition: from identity as a file to identity as a system. If you are just starting out, on a tight budget and without a settled logo, the post on visual identity for small businesses will be more useful right now.
Why the brand guide doesn't reach the screen on its own
A brand guide shows the brand under ideal conditions. An interface lives on variation: screens of different sizes, real content (long names, bad photos, empty lists) and interaction (hovering, focusing with the keyboard, waiting for something to load). Each of those situations calls for a visual decision.
The job of a system is to make those decisions once, give them names and reuse them everywhere.
Tokens: decisions with names
Tokens are the system's basic values, each with a name: colors, spacing, text sizes, border radii, shadows, animation durations. I usually split them into two layers:
- primitive, describing the value ("orange 500", "gray 900");
- semantic, describing the role ("accent color", "secondary text", "border", "error background").
Components only use the semantic ones. That way, adjusting the accent tone, or creating a dark theme, means changing one place instead of hunting for colors scattered across fifty files. In code they become CSS variables; in Figma, variables with the same names. When design and code speak the same language, most of the "it looked different in the mockup" goes away.
Typography: a scale, not just a typeface
Picking the typeface is the easy part. What supports reading is the scale: how many sizes exist (heading, subheading, body, caption, label), with what line height, and what maximum line length keeps long text comfortable. A few well-defined levels work better than a new size for every section.
There is also a technical side. Every font weight is one more file to download, so two families with a few weights each are usually enough. And a fallback font with similar proportions keeps text from "jumping" when the final font loads, something I cover in the post on site speed and Core Web Vitals.
Color: roles before shades
The brand palette is not the interface palette. An interface needs roles: background, surface, text, secondary text, border, accent, success, warning, error. The brand color fills some of those roles, not all of them.
This is where contrast comes in. The W3C accessibility guidelines ask for at least 4.5:1 between normal text and its background, and 3:1 for large text. Many brand colors, especially oranges and yellows, look great on large surfaces and fail as small text color.
On this site, for example, the orange accent has a text-only variant: darker in the light theme and lighter in the dark theme, because the same shade doesn't reach the required contrast on both backgrounds.
Components and their states
Button, form field, card, menu, alert. Every component needs all of its states designed, not just the default:
- rest, hover and pressed;
- visible focus for keyboard users;
- disabled and loading;
- error, success and empty.
Visible focus is not an aesthetic detail: it is what makes the site usable without a mouse. And states like "no results" or "something went wrong" are identity too. That is where the brand's tone of voice shows up when people need it most.
Dark mode is not inverted colors
A dark theme is a second set of values for the same semantic tokens. A few rules avoid the most common mistakes:
- surfaces get slightly lighter as they "rise" above the background;
- highly saturated colors need toning down so they don't vibrate against the dark;
- shadows lose their effect, and borders do a better job of separating things;
- logos and images with transparent backgrounds may need their own version.
The site can follow the operating system preference with prefers-color-scheme and also offer a manual switch. If the budget doesn't cover two well-made themes, I would rather deliver one careful theme than two half-finished ones.
Icons and illustration by the same hand
Icons from different libraries, with different stroke widths and corners, give away improvisation. It is worth choosing one family and fixing the rules: stroke width, grid, outline or fill.
The same logic applies to illustration: the style has to be a rule, not a one-off image. The identity of this site is based on a set of technical drawings. Each section opens with a numbered title block, like a sheet in a drawing set, and the isometric scenes share the same perspective, the same line and the same kind of annotation. That rule is what lets me draw a new scene without it looking like it came from another site.
How I handle this in a project
Since I do both the design and the code, tokens are defined once and used with the same name on both sides. Documentation is a simple page with tokens, components and states, not a hundred-page manual nobody opens. And everything stays in the client's name: design files, repository, domain and hosting. I explain how this fits into a website project on the websites page.
If your identity hasn't become a system on screen yet, you can tell me where it stands through the contact page.