Nate Baldwin
natebaldwin.bsky.social
Nate Baldwin
@natebaldwin.bsky.social
Design Systems @Intuit, previously @Adobe || Creator of LeonardoColor.io ColorAndContrast.com and Proportio.app
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”) 🤔
January 31, 2025 at 10:56 PM
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.
January 31, 2025 at 10:56 PM
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.
January 31, 2025 at 10:56 PM
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”…
January 31, 2025 at 10:56 PM
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…
January 31, 2025 at 10:56 PM
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.
January 13, 2025 at 8:22 PM
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…
January 13, 2025 at 8:22 PM
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
January 3, 2025 at 4:25 PM
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.
January 3, 2025 at 4:20 PM