I. The Promise
When I came up in this work, I believed the promise. Someone would hand me a file full of buttons and call it a system, and I took the naming at its word. I did not yet have the language for what was missing. I have the language now. I paid for it. Every designer pays for it eventually, in the currency of nights spent rebuilding a component that was supposed to already exist, in the slow accounting of a maintenance debt nobody remembers agreeing to carry.
Meta released their internal Design System called ‘Astryx’ out to the world as an open source. React, TypeScript, StyleX. More than a hundred and sixty components, themes, templates, dark mode, a CLI, and tooling built for people and for machines, both. It was developed quietly over some eight years inside the company and run across more than thirteen thousand applications before the rest of us were allowed to see it. The description reads like another library.
That is not the part that matters. What matters is what the thing reveals about how thin the ground was that all of us had been standing on.
II. Inventories
The word “system” got cheap. We call almost anything a system now. A Figma file with buttons is a system. A Storybook with twenty components is a system. A pile of colour tokens and spacing values and border radii, arranged and admired, is a system. A skin stretched over Material UI is somehow a system too. We call these things systems because the naming flatters us, and the truth costs more than the flattery.
They are inventories. They record what the components look like today and say nothing about why the components behave the way they do. The consistency lives on the surface. Underneath, the decisions that actually run the product sit scattered across design files and code and tickets and a Slack thread and the memory of whoever happened to be in the room six months ago. That memory leaves the company on a Friday afternoon and takes the system out the door with it.
I have seen this first-hand. You build a tokenised component library, align three teams around it, document the usage, get sign-off from engineering, and six months later someone new joins and starts a second button because they couldn’t find the first one. That is not a people problem. That is an architecture problem wearing a people’s costume.
III. The Prison and the Pile
There are two ways this plays out.
The first is the prison. The components hold, but they are welded so tightly to the identity of whoever built them that everything made with them looks like a weaker copy of that company. You change the colour. You round the corners. You swap the font. Still the original, wearing a borrowed coat. If you’ve ever tried to build a client’s brand inside a Material Design shell and wondered why it felt like dressing a Labrador in a tuxedo, you understand.
The second is the pile. A button lifted from one project. A dialogue from another. A table from whatever library was in fashion that season and some form controls from whichever starter kit was going around. Everything is customisable, they say, because the team owns the code. What the team owns is a debt. Every copied component becomes a private fork, and a private fork is a small plunder that compounds with interest. The accessibility fix that lands upstream never reaches you. Behaviour drifts. Documentation rots where it stands. Two components share a name and behave like strangers. Two that behave alike answer to different names. What began as a foundation becomes a dig site, and the team becomes a crew of archaeologists trying to date the layers of their own bad decisions.
And there is always a second building, kept in Figma, where a cleaner version of the same system is said to live. The Figma button has six variants. The shipped button has nine. One knows its focus state. The other knows its padding. The documentation shows a third that no one has touched since the redesign.
We call this a “single source of truth”, and we say it often, because saying it is easier than making it so.
IV. The Dream of Consistency
Here is the thing the industry decided not to know. A consistent mistake is still a mistake. A consistently inaccessible interaction locks the same people out every time, reliably, on schedule. A consistently overwrought API is still overwrought.
Consistency is not quality. It is quality’s costume.
We fell for it because uniformity photographs well. You can line up forty components on a page, set them on a grid, and present the arrangement as proof that the organisation has grown up. This is “the Dream”. The showroom. The polished floor where nothing is asked of the work except that it stand still and look finished.
Reality asks harder questions. Long content. Translation. A keyboard and no mouse. Validation that fails. Workflows nested inside workflows. Two hundred per cent zoom. Dense data. Reduced motion. A screen reader moving through the thing in the dark. A real person doing something the showcase never imagined. Most systems look immaculate in their own showroom and come apart the moment a product leans its full weight on them. The worth of a system was never the shine of its catalogue. The worth is how much difficult behaviour it can carry before it breaks.
I have built systems where the demo looked brilliant and the first production form blew through every assumption in the token set. That taught me more than any documentation sprint ever did.
V. What Astryx Holds
Astryx does one thing that should not be remarkable. It draws a hard line between how a component behaves and how it looks. The core owns structure, accessibility, interaction, and the technical spine. The theme owns colour, type, spacing, shape, motion, and the whole face of the thing. In most libraries these two are knotted together so completely that any real change means a wrapper, then a pile of increasingly desperate CSS overrides, then a specificity fight, then a fork. Astryx lets a team change the face without rebuilding the body. The client gets a product that looks like itself. The user gets behaviour that holds. The developer doesn’t have to choose between the two.
You’re thinking: “That’s been promised before.”
You’re right. It has. Every library since 2016 has claimed ‘themeability’. But most of them mean “You can change the primary colour and the border radius”. That is cosmetic surgery. ‘Astryx’ means ‘identity transplant’, where the skeletal structure stays intact.
And it admits the thing most systems refuse to say out loud, which is that sometimes the shared component is not enough. Instead of forcing every requirement through one abstraction until it screams, Astryx gives you a ladder. Start with tokens and themes. Move into component styling. Reach the lower primitives. And when you must, use its swizzle mechanism to pull the component’s source straight into the project and take it. That honesty matters. Most systems either lock you inside the abstraction or wave you towards copying everything and losing the centre entirely. Astryx names the boundary and lets you cross it on purpose, knowing exactly when you crossed.
That is governance, whether they call it that or not.
VI. A System That Can Speak
They call it “agent-ready“, and a phrase like that usually makes me reach for my wallet. Most products bolt the word ‘AI’ onto something old and pretend the architecture changed. Astryx seems to have done the harder thing. Its components, tokens, rules, and usage patterns can be read through tooling instead of buried in a documentation site nobody visits. An agent can inspect the system and work from what is actually there rather than guessing at what the library probably contains.
Here is the uncomfortable part. The agents are not why the systems are failing. The agents are revealing that the systems were never truly written down. A machine cannot use a system whose names contradict each other, whose rules live only in people’s heads, and whose examples argue with the implementation.
Neither can a person. The person is just better at hiding the failure. She asks someone. She searches the thread. She opens three files and copies the last thing that worked. We call that collaboration. It is closer to survival.
A real source of truth is not a page you are trusted to remember to check. It is a set of decisions that Figma and code and documentation and testing and the machine can all draw from at once. Astryx moves towards that. It is not nothing.
VII. The Work That Is Actually Mine
I do not care that Astryx has a lot of components. The world does not need another button. I care because it guards the things that should be standard without standardising the life out of the work. A client should not have to choose between being original and being reliable. Their product should inherit tested keyboard behaviour and accessible forms and predictable dialogues and coherent navigation without ending up as a Meta product wearing a new logo. That is the line almost everyone fails to hold. They keep consistency by flattening every product into the same face, or they keep freedom by walking away from the system the second the design gets interesting.
Astryx points at a third road. Keep the body. Change the face. Extend on purpose. Own the source only where the product truly demands it.
That road gives me back my actual work: the client’s reality. How dense should this interface be? How does the product say something is urgent? What happens when a person is about to make a mistake they cannot take back? What survives when the content is translated and runs long? What has to stay on screen while the task gets hard. What makes this organisation tick without making it harder to use?
Those are the questions. It is a solved thing we keep pretending is open. I have rebuilt dropdowns five times across three different employers, and every time, it was because nobody trusted the last one. Not because the last one was wrong. Because nobody could verify that it was right.
VIII. Three Layers
I would not start with the catalogue. Start with the catalogue, and design around whatever the library happens to contain instead of what the product needs. I would start with the client’s operating reality and map the behaviours that repeat. Navigation. Search. Entry. Validation. Filtering. Selection. Confirmation. Error. Status. Empty states. The dangerous actions most of all.
Then I would cut the system into three layers:
The first: the behavioural contract. What every interaction must do, whatever it happens to look like. A dialogue manages focus. A field exposes its name, its state, and its error. A destructive action makes the consequence plain before it lets you commit. A table stays usable through a keyboard and a screen reader and zoom. A loading state never leaves a person wondering whether the thing is broken. Not suggestions. Requirements. The face can change. The brand can grow. The behaviour stays defensible. This is the part I obsess over, and it is the part most “systems” skip entirely because it is invisible in a screenshot.
The second: the brand layer. The client’s real visual language. Type, colour relationships, spacing, density, shape, elevation, and motion. And then I would test it somewhere less kind than a marketing card. A dense records table. A multi-step form. An urgent warning. An empty dashboard. A mobile flow. A screen full of long, translated text. An identity that only survives on a pretty card is not a product system. It is a mood board with ambitions.
The third: the composition layer. Where the system becomes this client and no other. Flows, accounts, approvals, reporting, search results, records, dashboards, the whole administrative machinery. Astryx templates can give me structural ground, but they do not get to become the product by default. I would take their quality and bend it around these users, this content, and these business rules. And I would document not only what a component is but when to use it, when not to, what it assumes, and what happens when the requirement outgrows it. A system should not pretend to cover every situation. It should make its exceptions visible, deliberate, and expensive enough that people think hard before creating one.
That is three layers. Behaviour, brand, composition. From my count, if the behavioural layer is right, the other two have room to breathe. If the behavioural layer is weak, the other two are wallpaper.
IX. The One I Would Build
I have wanted to build my own system for years. Astryx clarified how I would go about it. Not from a logo and a palette and twelve beautiful button variants. Not a Figma library and a React package with matching names, declared finished. I would not sell flexibility while forcing every product through the same grammar, and I would not sell accessibility as a badge pinned to a component no matter how badly it is later themed and composed.
I would build it as infrastructure. Behavioural primitives first. Interaction contracts. Predictable APIs. Accessibility is written down, not implied. A theme architecture that can actually replace the visual identity, rather than a token layer wearing the costume of one. Abstractions strong enough to make consistency without making a cage. And it would explain itself so that Figma and code and docs and testing and the machine all draw from the same decisions instead of the same rumours.
Then I would stop testing it with screenshots of lonely components and start giving it hostile problems. An accessible form with conditional logic and real validation. A records table with filters and bulk actions and loading states and errors. Mobile navigation several levels deep. A dashboard that has to survive long content and a keyboard and two hundred per cent zoom and reduced motion and translation all at once. Then I would watch what breaks.
That is where the system actually begins. Not when the button looks done. When the thing survives contact with the world.
X. The Mirror
I am paying attention to Astryx, but I am not converted. It is interesting the way a mirror is interesting when it shows you something you had been managing not to see. It exposes how small the ambition was. We polished the gallery while the connection between design and code and accessibility and documentation and behaviour stayed fractured, and we told ourselves the gallery was the point.
Astryx does not hand us salvation. It hands us fewer excuses. A system can bend without losing its coherence. It can be accessible without dictating the brand. It can allow customisation without inviting chaos. It can serve human teams and machines from the same foundation. It can admit that exceptions exist without letting every project become one.
That should have been the standard already. It was not.
When I build mine, I do not want to add one more clean collection of components to a world already drowning in them. I want to build the thing that holds its ground when the designers and the developers and the products and the brands and the machines all begin pulling it apart at once.
A system. Not a showroom.