Building a design system for a developer tool
Design systems are interesting problems. You're building infrastructure for your own team — tools that other designers and engineers will use to build the product. Get it wrong and you slow everyone down. Get it right and it becomes invisible.
Why developer tools are different
Most design systems are built for marketing sites or consumer apps. They prioritize visual appeal, brand expression, flexibility.
Developer tools have different constraints. Density matters — developers want more information on screen, not less. Monospace fonts are load-bearing, not decorative. Dark mode isn't optional. And everything needs to feel fast, because perceived performance is part of the product.
Our design system reflects these constraints from the ground up.
What's in Axon's design system
We have about 80 components. Most of them are boring: buttons, inputs, selects, tables, tooltips. The interesting ones are the code-specific components: diff viewers, inline suggestions, error highlights, the agent progress panel.
Each component exists to solve a specific problem. We don't add components speculatively. If something isn't used in at least two places, it doesn't belong in the system.
The hardest part
The hardest part of maintaining a design system isn't building components. It's deprecation.
Components accumulate. Patterns diverge. You end up with three slightly different ways to show an inline error, all of which made sense when they were built.
We do a quarterly audit where we identify redundancy and consolidate. It's not glamorous work. But it keeps the system usable.
What we're still figuring out
Animation is the area we've invested least in. Our components have sensible transitions but nothing particularly considered. As Axon's UI gets more interactive — particularly with agents — we're going to need a more thoughtful motion system.
That's the next thing on my list.