Remote design systems engineers build and maintain the shared component libraries, design tokens, documentation systems, and engineering tooling that allow product teams to build consistent, high-quality user interfaces without reinventing every UI pattern from scratch — creating the multiplier layer of the design and engineering organisation that makes both design consistency and development velocity compound across teams and products. The role sits at the intersection of software engineering and design systems thinking.
What they do
Design systems engineers architect and implement the component library — building accessible, composable, and well-documented React (or framework-appropriate) components that encode the design system's visual and interaction patterns into reusable code. They manage the design token infrastructure — the structured representation of design decisions (colour, typography, spacing, motion) in a form that can be consumed by design tools, code, and documentation simultaneously, ensuring that a token change propagates correctly through the entire component ecosystem. They build and maintain the documentation site — Storybook, Zeroheight, or a custom documentation system — that makes the component library discoverable, usable, and trustworthy for the product engineering teams that consume it. They own the versioning, release, and migration process for the design system — managing breaking changes, writing migration guides, and supporting consuming teams through API changes that affect their existing code. They collaborate with designers on the design-code handoff — reviewing Figma component libraries for implementation feasibility, providing engineering input on design decisions with performance or accessibility implications, and maintaining the design-code parity that prevents the design system from fragmenting into separate design and engineering artefacts.
Required skills
Strong frontend engineering skills — proficiency in React (and its component model, hooks, context, and render patterns), TypeScript, CSS (particularly CSS custom properties and the cascade behaviour that design tokens depend on), and the build and bundling tooling (Rollup, Webpack, Vite) for producing a distributable component library — are the primary technical requirements. Accessibility expertise — WCAG 2.1/2.2 compliance, ARIA patterns, keyboard navigation, screen reader testing — because a design system that encodes accessibility incorrectly replicates accessibility failures across every product that consumes it. Understanding of design systems architecture — token structures, component API design, composition patterns, theming, and the principles that determine whether a design system scales to support multiple brands, products, or platforms. Documentation-first mindset for building the component documentation, usage guidelines, and accessibility notes that make the library useful to teams who were not involved in building it.
Nice-to-have skills
Experience with cross-platform design systems — extending a web component library to React Native (mobile), or building a platform-agnostic token layer that feeds both web and native implementations — for companies with products across multiple platforms. Background with design tooling integration — Figma plugin development, Figma variables and the design token connection between design tools and code — for organisations building tight design-code workflows where tokens and components stay synchronised across the design and engineering layers. Experience with visual regression testing (Chromatic, Percy, Playwright screenshot testing) for design systems teams that need to catch unintended visual changes during component updates.
Remote work considerations
Design systems engineering is highly compatible with remote work — component development, documentation, API design, and release management are all async activities. The cross-team collaboration dimension — supporting consuming teams with component questions, reviewing consuming team implementations for design system compliance, and gathering feedback for design system evolution — requires deliberate async communication investment. Remote design systems engineers typically invest in excellent written documentation, detailed component usage guides, and responsive async support channels (dedicated Slack channels, GitHub discussions) that allow consuming teams to get the guidance they need without waiting for synchronous office hours. The design partnership — collaborating with product designers on component API design and design-code parity — is effectively managed through Figma, async design reviews, and structured design system working group cadences.
Salary
Remote design systems engineers earn $130,000–$200,000 USD at mid-to-senior level in the US market, with staff and principal design systems engineers at major technology companies reaching $220,000–$300,000+. European remote salaries range €80,000–€150,000. Large technology companies with multiple product teams building on a shared design system, design tool companies where the design system is a product capability, e-commerce companies with multi-brand component library requirements, and financial services companies with strict UI consistency and accessibility obligations pay at the upper end.
Career progression
Frontend engineers who develop deep interest in component architecture and design systems, design engineers with strong coding skills, and UX engineers who develop the component engineering depth to build production-quality libraries move into design systems engineering. From engineer, the path runs to senior design systems engineer, staff engineer, and principal engineer or design systems lead. Some design systems engineers move into broader frontend architecture roles, into design tooling product management, or into developer relations at design tool companies.
Industries
Large technology companies with multiple product teams that benefit from shared component infrastructure (Google, Meta, Salesforce, Atlassian — where design systems are significant internal investments), SaaS companies with design systems as a product feature (Figma, Storybook, Canva), e-commerce companies with multi-brand or multi-market component requirements, enterprise software companies with strict accessibility and consistency requirements, and design consultancies building component libraries for client organisations are the primary employers.
How to stand out
Contributing to or maintaining a public design system or component library — open-source contributions to Material UI, Radix UI, shadcn/ui, or a company's open-sourced design system — demonstrates design systems engineering skill in a form that hiring teams can evaluate directly. Being specific about the adoption metrics of the design system you built — how many product teams consume it, what percentage of the UI surface is covered, how the adoption rate has grown — positions design systems as an organisational investment with measured returns. Remote design systems engineers who demonstrate strong documentation and communication practices — comprehensive Storybook stories, detailed API documentation, migration guides, and async support channel records — show the written communication depth that cross-team design systems adoption requires.
FAQ
What is a design token and why are they foundational to design systems?
A design token is a named, platform-agnostic representation of a design decision — colour values, typography scales, spacing increments, border radii, shadow values, and animation durations expressed as named variables (e.g. --color-brand-primary: #0066FF) rather than hard-coded values in component code. Tokens are foundational to design systems because they enable three capabilities: consistency (all components reference the same token rather than each component author choosing their own interpretation of "primary blue"), theming (changing a token value propagates through every component that references it, enabling light/dark modes, brand variants, or seasonal themes with a single change), and design-code synchronisation (tools like Figma Variables and Style Dictionary allow tokens to be defined once and automatically exported to both design tools and code). A design system without tokens is a collection of components; a design system with a well-structured token architecture is a scalable design infrastructure.
How do you design a component API that scales well?
By applying three principles: composability over configuration (prefer props that accept child components over a proliferating list of configuration props — a Button that accepts leftIcon and rightIcon as children is more flexible than a Button with fifteen icon-related props); minimal footprint (expose only the configuration surface that consuming teams genuinely need, and add props conservatively — every prop added is a prop that must be maintained and documented through every future version); and semantic naming (name props after the design intent, not the visual output — variant="destructive" not variant="red", so that theming can change the visual interpretation without breaking the semantic meaning). Good component API design borrows from API design principles more broadly: breaking changes are expensive, consistency across components reduces cognitive load, and the simplest API that meets real consuming team needs is always preferable to the most flexible one imaginable.
How do you manage a design system across a large number of consuming teams? Through a tiered contribution and governance model. The design systems team owns the core library and all breaking changes. Contributing teams can propose new components or variants through a defined contribution process — a proposal document, a design review, an implementation review, and an integration phase before inclusion in the core library. Consuming teams use the library but do not modify it directly; customisation happens through the token and theme layer, not through forking components. A design system working group or steering committee — with representation from design systems, product design, and consuming engineering teams — governs the roadmap and resolves design system policy questions. The governance model is as important as the technical architecture: design systems that lack clear governance inevitably fragment as consuming teams accumulate local modifications that diverge from the canonical library.