Nate Baldwin

Anyway, curious if this resonates with anyone else, or how you’ve helped gain a better understanding of systems theory and design (but again, that does not mean “component/token design”) 🤔

This is just my opinion, and I hope to do more for myself and my own teams by learning more about these foundations. But it also clarifies why “design-engineers” are invaluable to a DS team: understanding code is a way to understand hard systems, which can apply to many other areas of a DS.

We’re so caught up in “designing components”, “naming tokens”, “fostering adoption”, and many other elements that we’re missing the connective underlying foundation: actual systems design/thinking.

I believe this is why we continue struggling with making a design system stand the test of time.

Primarily, that “design systems design” roles lack any requirement for a foundational understanding of systems theory and systems-thinking. 🤔

I found this interesting but not all that surprising. Even for seasoned designers like myself, there’s ambiguity around actual “systems design”…

Which included game systems design, computer systems design, mathematics, and a few others.

Aside from the obvious differences, a few things stuck out to me…

Recently I fed the job descriptions for 18 different companies hiring design systems designers into AI and compared the common roles, responsibilities, and core competencies with other fields of “systems design”…

So updating your dependency could change the “display name” in your existing code editor (eg “myToken” to “newToken”) because it’s just a UI in and of itself.

Exactly, so this approach could offer automated migration guidelines and backwards compatibility. However, future tooling could hide all that behind a UI layer, even with code editors. You see and type a name but it’s a UID being actually referenced…

The thing missing from a lot of DS needs is someone who can create tools for system design (for designers). Not “components” but systems with variables and constraints. The person doing this shouldn’t be focused on making storybooks and unit tests. They’re typically more like designers

IMO not enough clarity and alignment on the title. Design systems need design-centric engineers and engineering-centric designers. From what I’ve seen, any time “engineer” is in the title, the role slowly becomes synonymous with “front end product engineer” which is a shame. I avoid it for that.

Super excited for this!

This is a wonderful article! What @Lea.Verou.me defines here is what I consider platform design, which I think sits one level below UI systems design. Ie:

Product design
⬇️
Systems design (UI)
⬇️
Platform design

Although the Eigensolution and composability approach to design is relevant to each.