When a design system stops being for designers

When I joined Monotype to build the design function again, my first question was whether there was a design system. The answer was yes, and that turned out to be the problem.

The previous team had built considered foundations in Sketch, but the system had not fully made the move to Figma. What survived was a set of elements rather than a set of rules. Components were not defined well enough to rely on. The type scale could not hold a product this dense. Colour had a primary and a secondary and not much of an opinion beyond that.

Every screen asked someone to re-derive decisions a system should have settled. I was about to bring in new designers, which meant those small re-derivations were about to multiply.

MyFonts had its own guidelines. Monotype Fonts had its own. Tidying each separately would have left us maintaining two systems, with every new product adding to that burden.

So we built one system carrying the DNA of the products, designed so each could branch from it rather than fork away. Shared foundations would hold the standard; deviations would be deliberate and traceable. Our team size shaped the architecture.

The name came from typography. Antiqua connected the system to the craft of the company, and we made restraint part of its brief. It gave us something to argue against: did an addition strengthen the structure, or simply decorate it?

It took six months to reach a foundation we trusted. During that time, existing surfaces and new work began moving onto it.

The part I would defend hardest is what we left undecided. We did not tokenise colour to a granular semantic level because the products had not yet shown us what those roles needed to mean. Defining them early would have made assumptions harder to change, just as more products came to depend on them.

The structure held while the semantic layer stayed open. We are only now reaching the point where the experiences are rich enough to tell us what those tokens should mean. As the products branch, the system gets more rigid on purpose.

The clearest signal that the foundation had worked was what design reviews stopped being about.

Before, reviews were spent on the interface. Is that the right weight? Is the hierarchy correct? Why does this button differ from the one two screens back? Reasonable questions, and all of them questions a system should have answered before anyone sat down.

By the end of those six months, the conversation had moved to journeys. Where does this workflow break? What does someone need to know at this step? Which path have we not designed for?

Each designer owned parts of the system alongside the products that used it, so they were arguing with their own decisions a few weeks later. Over nearly two years, search, WhatTheFont, and the Foundry platform kept testing those decisions. The system grew from typography foundations to components as involved as calendar widgets. Product work exposed what a tidy library example could conceal: awkward content, competing demands, and states nobody had designed yet.

The first version of Antiqua solved consistency. Handoff still left room for interpretation. Figma held the visual rules, while transitions, interruptions, and reduced-motion behaviour were described separately and rebuilt in engineering.

AI made working prototypes practical within our design process, so the system stopped ending at the Figma boundary. Interaction became part of the component definition: built and tested in code, connected back to Figma, and handed to engineering as a working asset. Questions that had stayed abstract in review became things we could feel.

Early internal results suggest engineering carries forward 80 to 90 percent of the code it receives. Builds that took five days have taken one, and new concepts can be reached in hours rather than days. These results are still being validated; they describe our experience so far, rather than a benchmark for every build.

One example shows why. We used a toggle to show whether a font family was active, inactive, or partially active, keeping activation separate from selection. The hard part was the third state. With one style active and a hundred inactive, a click that assumed "activate all" or "deactivate all" could start an operation someone never intended, then another to undo it. The state was clear; the intent was not.

My hypothesis was that where someone clicked could tell us what they wanted: either side of the toggle offering a destination, with hover feedback making it clear before they committed. In Figma, that was a drawing of three states. In code, it became a behaviour we could try, adjusting placement, feedback, and transition until the idea could be judged on how it felt.

The toggle has now shipped. How people actually use the partial state is what we learn next.

Contributing to Antiqua now sits in my designers' objectives as development. Owning a component gives them a small enough surface to practise judgement and get it wrong safely.

It asks for details a product deadline can push aside. Motion. Graphic craft. How a transition should feel and why. What happens when the content is too long, the network is slow, or someone changes their mind halfway through. Those become decisions the designer has to hold a position on.

That responsibility extends into engineering: the cost of building the component, the states it needs to support, and whether the pattern earns its place at all. A designer who can carry an idea through to something that runs can also discover where the original idea falls short.

Judgement is difficult to teach in review comments. Here, the designer defines a rule, sees it used in a product, and comes back to improve it. The system develops with the people responsible for it.

I would rather grow that capability inside the team than hire for it later.

For most of Monotype's history, a dedicated design systems team would have been difficult to justify. A library maintained alongside product work was proportionate, and I would have argued against the headcount myself.

I see a different case for that investment now. As AI systems generate interfaces from a design system, it becomes a specification they execute. Ambiguity in that specification can spread across the products built from it.

Defining what a dropdown looks like is no longer sufficient. Someone has to define how it behaves near a viewport edge, on a touch surface, under reduced motion, or when the data is empty or enormous. Many of those decisions have sat with engineers, made case by case. Leaving them unspecified asks the generating system to infer them each time.

A design systems function becomes the place where that interaction judgement is made explicit and kept current. Tokens and components carry rules about behaviour, including the awkward cases that rarely appear in a polished example.

That is where I would invest: in a system that lets someone without design training express an idea and have the standard carried on their behalf.

The direction now is from atomic elements through to templates, with enough of the system expressed in code that a product manager or an engineer can describe a journey and get something of shipped quality back. That is the ambition for the next version, and it depends on making the system's judgement as dependable as its visual rules.

A system that survives with or without me.