System design is not product design

We often hear that design systems are products. In some ways they are. They have customers, they have roadmaps, they have lifecycles, they have a perceived value that may differ from their actual value etc. There is some overlap. But there are also clear distinctions. A design system is an authority-backed service, one your consumers can't (or really should not) escape. That's not a traditional product.

In many companies, that product is also being built and maintained by the very same people who are consuming it.

But there are reasons why we usually don't build the products we use. Time, first. Even if you have the skills and the will to cook, you're likely not growing your own wheat / rice / vegetables etc. You go and buy flour, you order in from time to time. That's true for product designers too: even if they want to build the design system, they have other things to do than sift their own grain.

There's a second layer to us not building every product we use: we do not have the skills. You may know how to cook, yet there's a gap between boiling pasta water and a Michelin-star meal: same activity, different job. Some product designers are entirely capable of system design and vice versa. I've met some. But I've also met great product designers for whom system design was always painful. The skillsets are different.

System design is not product design

Product designers working with a system know that using library components is the right thing to do. They build their designs with them, composing screens with them. There is genuine skill in translating business and user needs through the lens of a system. But when it comes to building these components, things are different.

You're building the lens. You're making something that'll be used by every other designer, that must reflect a contract between your design tool and your various implementation platforms, that can evolve, that is rigid enough not to be abused but flexible enough not to be a pain...

To do that, you are going to use architecture skills you do not need for your feature mock-ups (although I would argue they do not hurt...). You might use software features you're not familiar with. And you can't cut corners. You must account for every state and edge-case.

Architecture

Scalable components are built around atomic architectures, with private primitives that let teams rapidly adapt, edit or create variants of their components. Although some teams have similar requirements for their feature mock-ups, most do not and reserve this high level of requirements for their components. A lot of product designers are therefore nearly never exposed to that skillset, yet can fulfil their mission all the same.

Software features

If you only consume components from the team's library, you may never learn to set up concepts like properties, variants, or nested instance inheritance. You know some of them through using them as a consumer, but building them is not always easy. When do you use a variant? When do you create a boolean? Why won't Figma let you create a boolean that serves as an "if / else"? Does Figma hate you? It's a different mindset, not one every product designer is willing to get into.

No cut corners

Not that feature design is about being lazy, mind you. But there's a large difference between designing a component that is a perennial source of truth for a given pattern and consuming it. When you use a design system button, questions of its states and rules have already been solved and documented. You don't need to make that effort; you focus on the constraints related only to the feature you are building. There is already so much that has been done behind the scenes.

Building a team

Accounting for this is critical at the organisation level. As an industry, we already acknowledge that engineers aren't all the same and that specialisation has its benefits. Even in frontend teams, complementary skillsets are appreciated: some are performance experts, some are CSS buffs, some are algorithm nuts. We expect them to be "T-shaped", to have depth in a speciality but an ability to dabble "horizontally" into other fields.

Designers are very much the same. When you get one, you don't get the entire spread of design ability made flesh. Most have the same "T-shape" mindset, but they need you to acknowledge that if you've hired them for product design, they need organisational support to achieve...the other kinds of design. If you have the budget to hire the team that will provide your product designer cooks with the high-quality ingredients they need: great! If not, manage your expectations accordingly.

• Try to test for system design during your hiring process. This lets you know how familiar candidates are with design architecture and Figma features. A simple task around building a small component set would be enough.
• Ideally, dedicate at least one full-time asset to your design system. Most experts recommend having a dedicated team, but a single asset can already help a lot to set guardrails.
• Enforce workflows that help your product designers set time aside for things they are less familiar with. If you expect them to be as fast and good with system design as they are with their other tasks, they'll be under such pressure they will be more likely to fail...or avoid doing the harder stuff altogether.

Treat system design as a specialist practice, not a side quest: hire for it, staff for it, and give product designers the support to contribute without carrying it alone.