Building a design system machines can read

Wallarm's platform had no shared design system. Every new screen started with days of archaeology before any design: going through the console screen by screen, looking for something consistent to stand on, and finding none.

• —No shared design system. Every page ran on its own rules.
• —New screens started with days of archaeology, not design.
• —Fast concepts came out inconsistent and low quality.
• —An AI-first company could not move AI-first. There were no consistent parts to build from.

What finally made the design system urgent was vibe-coding. Once PMs and engineers started shipping rough prototypes to explain ideas, the missing design system became the bottleneck. Everyone could suddenly prototype, but without shared, consistent parts the results came out rough and inconsistent.

• —Co-designed a new design system with our design lead: tokens, rules, and components tuned to Wallarm.
• —Wrote UI in the engineering codebase and merged my own work.
• —Wrote the design-system documentation: a spec per component, how they combine, and the do's and don'ts.

The design system starts with tokens: color, type, spacing, and elevation, tuned to a dense cybersecurity product where status and severity have to read at a glance.

A component library shows what exists. It doesn't say when to use a component, what to pair it with, or what to avoid. Our design lead and I wrote that down: a spec for every component, how components combine, the do's and don'ts, and a full guide to the filter field. Whoever builds a screen, a person or an agent, gets that judgment before they start.

• —Short. One or two sentences per component, because picking the best line matters more than adding lines.
• —True to the product. When the docs and the shipped component disagree, the component wins.
• —The designer decides. A rule we reject is removed, not softened.

The design system changed how the work happens. A feature used to move in a long line: research, weeks of mockups, a handoff to engineering, then a build. Now product often starts the concept, a PM brings a vibe-coded draft, and the same feature goes from idea to shipped noticeably faster than before. Here is how a feature moves now:

Whoever fits ships it: the designer, the PM, or the engineering team, depending on how complex the feature is.

What a designer does now depends on the work:

• —Settings and service pages: fast, often no designer needed. We approve at the end and fix the code when it is not clean.
• —Features from product: the PM's draft gets us most of the way. We turn it into a real concept and do the research around it.
• —Net-new features: iterate straight into the design system, test with users fast, ship without the old friction.

The designer who hands off pretty pictures is gone. I work on product's ground and engineering's now. Engineers still ship the code. Everyone speaks one language, and the friction drops. A design system used to be a library you referred to. Here it became part of the codebase every new feature starts from, something an agent builds with directly.

This is the design system the infrastructure-discovery work was built on, a parallel track with its own case study →