DAS Design System
DASDS is the design system for NETZSCH's Digital and Automation Systems: a Figma-to-code pipeline built so eight product squads ship consistent UI without paying a coordination tax every sprint.
- 8+
- Product squads using DS
- 1.2k
- Figma variables
- 60+
- Components in production
Challenge
Each product line at NETZSCH had its own components, tokens, and conventions. Overlapping but incompatible. Every cross-team feature dragged because nobody owned the shared layer.
The brief was to build something the frontline teams would actually want to use, not a system they'd be forced into. Which meant the foundation had to solve real problems first: accessible color, typography that survives Portuguese-to-German translation, dense data tables, and form patterns that match the regulated nature of industrial software.
Approach
Tokens first. Variables in Figma map one-to-one to CSS custom properties via Style Dictionary, so a change in color or spacing flows from design to production with no manual translation. Components are owned in code, documented in Storybook, and demoed in Figma alongside the production build.
Governance is intentionally light. Any team can propose a new component via PR. The platform team reviews for consistency. Contributors keep authorship credit. Adoption per squad is the metric, not component count.
Outcome
Eight product squads consume the DS in production. New cross-team features ship without the old design-versus-engineering token negotiation. Accessibility reviews compressed from days to hours because the foundation is already AA.
The DS now seeds new lines (IRIS V3, the Customer Portal, internal tools) instead of each one rebuilding the same primitives.
Who I designed for
Two audiences with very different needs.
Frontend engineers in the squads are the people who actually consume the system. They wanted boring things: a Storybook page that loads fast, prop names that match what they expect, and components that don't fight their existing build. Anything fancy lost to anything dependable.
Product designers in the squads (usually one per product line, sometimes none) wanted Figma variables that mirror code variables, so they don't have to redo work the engineers already did. The 1:1 token mapping wasn't aesthetic. It was the contract that lets a designer hand off without translating.
The key decision: a single source of truth for tokens
Most DS projects fail at the same place: the design tokens in Figma drift from the CSS variables in code, and within six months everyone is back to copying hex codes by hand. I refused to ship anything until the pipeline was airtight.
Figma variables export to a JSON Style Dictionary spec. Style Dictionary builds the same tokens into CSS custom properties, Tailwind config, and a TypeScript types file. One source, three outputs, all generated. A designer renaming a color in Figma triggers a PR. An engineer adjusting a contrast ratio updates Figma at the same time.
The whole rest of the system (typography scale, spacing, radii, shadows, motion) sits on top of that pipeline. Without it, the DS is just a pile of components that look right today and wrong in two months.
What didn't go well
The hard part wasn't building the system. It was getting squads with working legacy code to adopt it. Solid components and clean docs weren't enough. Teams pushed back when a new pattern meant refactoring something that already shipped, and the first six months were mostly demos, pairing with squad leads, and rewriting docs to answer the same five questions.
The "light governance" model also showed its limits. Letting anyone propose components meant the queue filled up with single-use specials. I had to start saying no, which is uncomfortable when you're pitching the system as community-owned. Any DS needs an opinionated owner, and I was that owner whether the org chart said so or not.
Selected screens
" A DS lives or dies by adoption, not aesthetics. The wins came from the boring parts (token pipeline, accessibility floor, contribution flow) done before anyone got excited about the visual language. "
MyCT
→Citizen-facing portal. WCAG 2.1 AA, plain language, mobile-first.