The Thesis
Every product is full of small, repetitive design decisions: which icon a warning dialog uses, how destructive actions are styled, in what order buttons appear. None of these decisions is hard. But made a hundred times by different people, they cost time and drift apart.
At UNEOS, we did not have the luxury of making them a hundred times. One design team, three products, several engineering teams. So we built Arc, a design system that made the easy decisions once, inside the system, so that anyone could assemble correct UI without asking design. This article is about the idea that made this work: semantic components.
Scope
UNEOS built an ecosystem of banking applications: Core Services, a Controlling product, and a Budgeting product that was still in design. Arc was the shared foundation underneath all of them, so every design decision had to hold across the whole ecosystem, including products that did not exist yet when the system was built.
The team ratio shaped Arc's direction: roughly one designer for every six engineers meant the system had to work without design becoming the bottleneck. The frontend ran on Vue.js, which influenced several architecture decisions. By the end, Arc covered more than 50 components in Figma, from atoms like buttons and inputs to organisms like data tables and multi-step forms.
The Semantic Layer
Most design systems stop at visual components: flexible, reusable, and completely undecided. Every use means deciding again. Which icon, which button style, which order, what happens on confirm. The components are reusable. The decisions are not.
Arc added a second layer on top: semantic components. Instead of generic building blocks, the system offered components that already knew what they meant, visually and logically. Styling, hierarchy, and behavior were decided once and wired into the component itself: which states it has, how it validates, what it triggers.
What It Changed
Building Arc was not free. The semantic layer cost real time upfront, on the design side and on the engineering side, and for the first features it felt like overhead. By the second feature, it had paid for itself.
The clearest change was where design time went. The repetitive decisions were gone, and with them the small inconsistencies they used to produce. Design work shifted to the problems that actually needed a designer: interaction concepts, complex workflows, the edge cases no component can decide for you. For a design team outnumbered six to one by engineers, that shift was not a nice-to-have. It was the only way to keep up.
The second change happened during feature conception. Product owners and domain experts could define large parts of a feature in system terms: which workflows apply, which review rules, which dialogs. Design entered the conversation where it mattered, not to assemble the standard parts.
But the strongest signal came from engineering. The engineers did not just adopt Arc, they pushed it forward, proposed components, and invested their own time in evolving the system. Nobody spends free capacity on tooling that slows them down. Adoption by pull, not push, was the honest metric that Arc worked.
Looking Back
Arc worked, and we overbuilt it. Both are true. We had the rare chance to build a system from scratch and wanted it to last, so we added depth we rarely needed: a component-token layer, detailed versioning, documentation deeper than any consumer of the system asked for. The semantic layer paid for itself within two features. The infrastructure around it took considerably longer, and some of it never did.
Starting again today, I would keep the idea and shrink the foundation: build on an existing base like shadcn/ui on Radix, put the product identity on top, and spend the saved effort where Arc actually earned its keep, one level up, where components stop being generic and start meaning something.
The lesson underneath is not about tokens. A design system earns its place by removing decisions, not by storing them. Arc removed the easy ones so we could afford the hard ones, and that is the part I would build exactly the same way again.