I’m teaching a few classes which is how many of these posts begin. Preparing to teach forces me to pull decisions out of muscle memory and explain why I make them. The students get a lesson, and I get a clearer system, plus something useful to refer to when future me forgets why past me made a perfectly sensible decision.
Typography is one of those subjects that can look simple. Choose a typeface, establish a few sizes and call it a system. But a good type system has architecture. Every style has a job, every name has to travel clearly between design and code, and the whole thing has to work consistently across websites, tools and AI.
I recently wrote about why I built five Design Guidelines at once. Working across five systems at the same time made it much easier to see which structural decisions should remain consistent and which ones need to respond to the individual brand. Colour revealed the pattern, but typography exposed the architecture. It showed me where consistency creates clarity and where specificity protects the character of the work.
A type scale is not a typography system
A list of fonts and sizes is not a system. It is a list of fonts and sizes. A working typography system explains what each style is for, how it behaves and how it connects to the website underneath it.
A large heading is not simply “the 72-pixel one.” It might be the primary page title, an editorial statement or the giant thing at the top of the homepage. Those are different jobs, even if they occasionally look similar, which is why I name type styles by their purpose rather than their appearance.
Every system I build has a stable set of roles: titles, headings, body styles, labels, buttons and annotations. The fonts and visual treatments change with the client, but the underlying jobs stay understandable. The structure remains consistent without forcing every brand to look the same, because I have no interest in creating a system that irons all the personality out of the work.
I design typography for the web first
Typography is often established inside a design file and translated into a website later. I work in the opposite direction because I want to know what happens when the headline wraps, how it behaves on a phone and whether the body copy still feels comfortable halfway down a long page. I also want to know whether the font weights I specified actually exist in the files being loaded.
The website is not where the typography gets reproduced; it is where the typography proves that it works. Large display type may need to move between desktop and mobile, while reading text usually benefits from staying more stable. A label, button and paragraph may all use the same font family while doing completely different jobs.
Those decisions belong in the system from the beginning. They should not be discovered later by a developer or invented with great confidence by an AI tool.
I have a lot of opinions about naming things
Naming conventions sound like internal housekeeping, but a name determines whether a decision can travel accurately from one person or tool to another. Names such as “big heading,” “small text” and “Inter bold” describe what something looks like at one moment. They stop making sense as soon as the font changes or the design evolves.
Then someone adds “small heading 2,” followed eventually by “small heading final.” AI does not know that “small heading final” was the result of a difficult afternoon. It assumes this is the system.
I use names that describe responsibility instead. “Regular body text” is clear to a person reading the guidelines, while the same style has a stable system name that can be used in tokens, code and AI instructions. The website can then connect that role to whatever class or naming convention it already uses.
One role therefore has a clear client-facing label, a consistent design-system name and an implementation name for the website. They all point back to the same decision. That connection keeps the system from quietly splitting into three slightly different versions of itself.
The system should reduce interpretation
Traditional brand guidelines were designed to be interpreted. Someone read the document, studied the examples and decided how to apply them. That already introduced variation because two capable people could read the same guidelines and produce two different results.
Now the work moves constantly between tools. A project might begin in Figma, move into Canva, land in Google Docs or Slides, and then be picked up by a website builder or an AI tool. Some platforms handle structured design information better than others. Google Docs and Slides, I am looking at you. Regardless of what each tool can do, they all need to be reading from the same system.
Every handoff creates another opportunity for the system to splinter. If Figma has one set of styles, Canva has another and a slide deck contains something vaguely similar, the brand gradually becomes a collection of approximations. AI makes that ambiguity more obvious because it does not stop to ask whether two nearly identical styles were probably meant to be one. It uses both confidently and at scale.
This is why I keep the system in one place and give it one URL. The design system does not belong to Figma, Canva, Google or whichever AI platform is useful this week. Those are tools for applying the system, not the system itself. The tools can change without forcing the organization to rebuild or reinterpret its brand every time.
The goal is not to make every platform behave identically. It is to give people and machines one reliable source of truth, with clear names, defined roles and decisions that can travel. A good system reduces interpretation where consistency matters while leaving room for judgment where it actually improves the work.
Similar is not the same
Styles that look similar are not necessarily doing the same job. Buttons and small labels are a good example: they may use the same family, weight and capitalization, but one asks someone to do something while the other organizes information. I keep them as separate roles because their responsibilities are different, even when their current values happen to match.
The same is true of headings. In my system, one heading introduces a major section, another identifies a group inside that section and another names an individual item. Without those distinctions, everything below the page title eventually becomes “small heading.”
That works until it doesn’t, usually halfway through a complicated page when nobody can remember which small heading is supposed to be smaller. The system is not only controlling size; it is protecting the hierarchy.
Beautiful for humans and precise for machines
My Design Guidelines have two audiences now. Clients, designers and developers need something inviting, understandable and genuinely useful. They need to see the typography working, not decode a spreadsheet wearing a logo.
The second audience is machines. The same system needs stable names, structured values and clear relationships that can be read by websites, tools and AI. Those outputs do not need to be beautiful, but they do need to be exact.
I do not want a polished guideline for people and a separate technical system being maintained somewhere else, because that is how things drift. Both versions come from the same source: people see real type, explanations and examples; the website receives usable tokens; and AI receives structured guidance about what each role means and which information takes priority. The presentation changes for the audience, but the decisions do not.
This is part of brand leadership now
A brand system used to move between a fairly small group of people: the client, the designer, an agency and perhaps a developer. Now it may also be read by a website builder, a content platform, an image generator, a presentation tool and several AI systems, all before lunch.
That changes the responsibility of the person creating it. It is no longer enough to make a strong visual decision. I have to make that decision portable by naming it properly, connecting it to its purpose and making sure it survives being moved between tools.
Typography is a good example because it sits directly between brand and infrastructure. It carries personality, but it also organizes information, so it needs sensitivity and precision at the same time. The goal is not to make design more mechanical; it is to stop the thinking behind the design from disappearing whenever the work changes hands.
That is why I make the guidelines beautiful for humans and exact underneath. One helps people understand and trust the idea, while the other stops the machines from getting creative with it.
