Frontend Engineer vs Design Systems Engineer

You've probably heard about design systems and seen job posts for design systems engineers or for UX engineers, who often work on a design system.

First of all, what is a design systems engineer? It's an engineer working on a design system, who may have some interest or experience in design fundamentals like colors and typography. A design system is a set of reusable components along with usage guidelines which can be used to create all kinds of new layouts and pages. It can really speed design and development for product work, since designers and engineers will use the components as building blocks instead of starting from scratch.

Is this type of role for you? Today I'm going to highlight some of the differences between a frontend engineering role and a design systems engineering role.

Collaboration with designers is extra important

In a design systems engineering role, you'll spend a lot of time collaborating with designers. You'll review component designs and and work together with designers during new component builds. You may even prototype new component UIs during the development phase in order to get early feedback from design systems designers. Communication skills are important!

More planning before component development

In product work, frontend engineers often move straight into the development phase when building a new feature. This is quite different from design system engineering, when there is normally a lot of planning that takes place before any code is written.

During this planning phase, design system engineers will review the final component designs and decide on the best API to use for the component. The goal is to help ensure that the final component is easy for other frontend engineers to use, in addition to having all the needed functionality.

Other engineers are your customers

As an engineer on a design systems team, your customers are the consumers of your system -- other engineers. This contrasts with being an engineer on a product team, where your customers may be external users of the product. Being able to talk often with engineers using your design system in order to get their feedback is really important. Being in touch with your customers also helps to gauge any pain points that design systems users are encountering.

Testing is really important

Component tests are always good to have in place, but in a design system, where possibly hundreds or even thousands of engineers will be using your system, tests are critical. Having tooling in place for accessibility testing and UX regression testing also is very valuable for design systems teams.

Accessibility is a must-have

Accessibility is unfortunately often an afterthought when working as a frontend engineer on a product team. When working on a design system, building accessible components is a core foundation of the role. Most US-based design systems aim to follow WCGAG 2.1 Guidelines for components. As a new design systems engineer, you'll be ramping up on these guidelines and learn how to best implement them.

Documentation is core to the system

Because the success of a design system is measured based on adoption, documentation on components and how to use them is key. Teams often use Storybook or a similar tool to allow customers to see and interact with components. Documenting usage patterns for each component, along with any guidelines for ensuring accessibility, is also critical.

Support is part of the role

As a design systems engineer, helping engineers adopt and use the design system is a big part of the role. Engineers may discover component bugs that need to be addressed, or they may have ideas for ways to make components easier to use. Fielding questions on component usage and fixing component bugs are common activities for design systems team members.

Infrastructure and version management comes to the forefront

On a design systems team, engineers often work in a monorepo, where different aspects of the system, like components and icons, may be broken up into different npm packages with independent versioning. This makes adopting the system easier for users, as they can upgrade to new package versions on their own time frame. This also makes managing changes over time easier for design systems engineer.

Experience or interest in semantic versioning standards, tools like lerna, which is often use for automating package versioning, and tools for continuous integration is really valuable on a design systems team.

I hope this helps with anyone considering moving into design systems engineering! It's definitely a growing specialty. Do you have more thoughts on the differences between frontend engineering and design systems engineering? Leave a comment!