Design System Engineer — Jack of All Trades

Recently, Yangshun Tay described five front-end archetypes: Product Engineer, UX Engineer, Design Engineer, UI Infrastructure Engineer, and Tooling Infrastructure Engineer. When I came across this breakdown, I started to reflect on who I am within this paradigm. For the past decade, I've been developing and managing design systems, even before the term was widely adopted. In a single day, I can jump from product road-mapping to accessibility audits to an unexpected TypeScript rabbit hole and then to polishing CI/CD pipelines. So, I would say there are "jacks of all trades" in our industry—and they are Design System Engineers!

Before we walk through what this actually looks like in practice, I'll briefly introduce the archetypes as they were presented by Yangshun Tay:

1. Product Engineer – shapes features to meet real user needs and business goals.

2. UX Engineer – prototypes and perfects delightful, accessible interactions.

3. Design Engineer – translates pixels and design tokens into working code.

4. UI Infrastructure Engineer – crafts the reusable foundations that keep teams shipping fast.

5. Tooling Infrastructure Engineer – builds the pipelines, CLIs, and plugins that make the rest of us look productive.

I claim again that Design System Engineers fit all the categories. Here is how:

🎯 Product Engineer: Your Component Library is the Product

Design System Engineers are often product managers for their own internal products. And this product comes with a twist: it is internal, and its customers have direct Slack access.

In many organizations, this product serves hundreds of developers and designers. If the scale is smaller, ... well, it doesn't change much.

Design System Engineers manage roadmaps that would make any PM proud (and equally anxious), run "user interviews" with frontend developers who aren't shy about feedback, and A/B test different API designs for components. There is usually a lot of market research at play. Even though many don't realize that this is what they are actually doing when auditing other companies' design systems on GitHub at 2 AM.

Last few years, I proudly observed how the most popular design systems are not just products but data-driven products. We track adoption rates, developer satisfaction scores, and reduced design-to-development handoff time—and the elusive “no one forked the library this quarter”!

🎨 UX Engineer: Guardian of Delight (and WCAG)

Design System Engineers don't just build components; they build the experience of those components. Every interaction, every animation, every accessibility feature matters.

While building components, Design System Engineers become obsessed with how those components are experienced. They dive deep into accessibility rabbit holes, test everything with screen readers and keyboard navigation, and spend hours perfecting focus rings that most users will never notice. They prototype complex interactions.Often that ends up in building more animation demos than a Pixar intern. And they think carefully about how developers will discover, understand, and implement components.

Design System Engineers speak both Designer and Developer fluently. They participate in user research, validate that components solve real problems, and ensure that the final user experience doesn't suffer because of implementation constraints.

🎭 Design Engineer: The Pixel-Perfect Translator

Design System Engineers live at the intersection of design tools and development reality. They're the bridge between the abstract world of Figma and the concrete world of code.

They catch rogue 1-pixel shifts, translate design intentions into code, and often spot design inconsistencies before they make it to production. But the superpower isn’t this ability; it's the deep understanding of why it is so important from the design perspective.

A personal story here! On one project, our lead designer got sick the day before a Figma workshop for new team members. I stepped in to cover the essentials (component libraries, design tokens, prototyping, and collaboration features). Maybe, I couldn't replicate their entire workflow at 100%, but I knew enough to make it work. The newcomers were impressed that an engineer could navigate Figma so fluently. The designer later joked that I was "stealing their job," but really, it just showed how deeply integrated our roles have become.

🏗️ UI Infrastructure Engineer: The Foundation Builder

This is the most obvious part of the job, but also the most technically complex. Design System Engineers build the foundations that empower hundreds of other engineers.

In design systems, we design APIs for components that need to work for hundreds of different use cases, worry about bundle size like it's our BMI, and think about how this button will work in 5 different frameworks and 10 different themes. We create abstractions that work across multiple product teams.

Refactoring the Grid component while 30 teams are still actively shipping is a pretty normal day for a Design System Engineer. It’s a bit like performing heart surgery on a marathon runner.

⚙️ Tooling Infrastructure Engineer: The Developer Experience Wizard

Besides building components, Design System Engineers build the tools to manage and use those components. They're the Gandalf of the developer workflow.

In fact, in design systems, we need the entire ecosystem. So, the engineers create CLI tools for scaffolding new components, develop Figma plugins, and maintain documentation websites that somehow update themselves. They build CI/CD pipelines that run visual regression testing, accessibility testing, and performance testing automatically.

I find special joy in this aspect. I'm fundamentally lazy, so automating everything feels natural—and manual processes don't scale when you're supporting 47 different projects.

---

As jacks of all trades, Design System Engineers understand the entire product development lifecycle because they participate in all of it. They can communicate effectively with designers, developers, PMs, and executives. They can approach challenges from multiple angles because they have multiple toolsets.

That naturally brings us to the idea that Design System Engineers serve as translators and bridge-builders. They reduce silos, accelerate adoption, and elevate quality across entire organizations. They don't just build components—they shape how entire teams build products.

The design systems provide the foundation that empowers entire organizations to build better products faster. So, the Design System Engineers are the Swiss Army knife of the frontend world, and that's exactly what modern product development needs.

What hat are you wearing most this week? Share your best tips for managing the beautiful chaos of being a Design System Engineer!