The influence of Design systems and JavaScript frameworks in large-scale companies
Both have a similar influence on two different jobs, design and development, creating a new division of labor.
Design systems and the designer roles
Design systems are somewhat new. Even if everybody in the design sphere is talking about them right now, the consequences of their introduction in big companies are yet to be fully understood.
In my experience, one of those consequences is the separation of designers into two categories:
- System designers usually have a greater capacity to envision the entire system — potentially involving numerous brands, products, variants — to extract the common denominators or patterns between those components, products, or brands. They create rules and rationales around foundational elements like a color palette or border radii and deeply care about UI elements. Their users are internal: developers and other designers.
- Product designers usually have a deep understanding of one particular product, its users, and its overall context. They have to deal with the end users’ problems, which often translate into creating new features by composing with UI elements from the system.
Now, this doesn’t mean that someone can’t have both skill sets or move from one role to the other, but in larger organizations where you have a dedicated design system team, designers will rarely do both at the same time.
It also — hopefully — doesn’t mean that one camp is not talking to or informing the other. System designers should explain how to best use what’s in the toolbox; product designers should give some feedback if something is not working for their users or missing. You get the picture.
JavaScript frameworks and the developer roles
Whether you’re using React, Angular, Vue, Ember, or insert the hottest new tool here, if you’re building a Web application, you’re probably using a JavaScript framework. (Don’t get on my case about one or the other technically not being a framework, that’s not the point).
Fact is, pretty much like designers and design systems, this new methodology is influencing the way work is being done. And once again, in my experience, it tends to separate front-end developers into two categories:
- UX Engineers (or front-front-end developers, or design technologists, or…) build the CSS foundations and UI components, probably included in a component library, and hopefully integrated into a design system. They thrive on semantic HTML, accessibility, CSS, motion, localization, micro-interactions, SVGs…
- JavaScript Developers, on the other end, usually don’t care too much about the craft of building beautiful UI — and it’s okay. They tend to prefer focusing on the application shell, its logic, its routing, and creating new features, reusing the UI elements that they can find in the component library.
But not every company has integrated that model.
In my opinion, if you want an excellent product team, you need to integrate those two notions, and you need to integrate them quickly and effectively.
Here are a few points to consider.
System designers are not as common as you might think.
Systems thinking is a muscle that you need to flex. I often say that anything is learnable on the job, as long as you’re not working in nuclear fission or heart surgery, but you need to practice it to be successful. System designers also need to have a much deeper understanding of their media, whether it’s web browsers or mobile OS’s. Should they know how to code then? I already talked about that.
Be mindful of the feedback loop between system and product teams.
Nothing more quickly breaks trust in your design system than its ineptitude to solve its users’ problems. But it also needs to establish an easy process around how product teams — designers and developers alike — can contribute to and improve the system. The graduation process can’t be obscure, and as my former manager Bob Baxley once explained, you need to define a clear path to yes.
UX Engineers tend to prefer to work in the design team.
It might sound counter-intuitive, but they don’t belong in the Engineering organization. They’re much closer to the design team because they care as much as designers about how things look and the overall user experience.
It might be scary for the design leadership — maybe because they don’t know much about development — and it might be complex to create a career ladder for them, but those are necessary growing pains to build the best UI in the world and beat your competition.
UX Engineers are not as well regarded as Software Engineers.
Have a look at any pay range tool for UX Engineers or Front-end Developers: they’re paid less than their Software Engineers counter-parts.
Isn’t this arbitrary in the end? If the laws of supply and demand apply here, I’d argue that it’s much more difficult nowadays to find UX Engineers than Software Engineers.
UX Engineers need to know several languages (at least HTML, CSS, and JavaScript), plus many quirks from the less-than-perfect integration of those said languages in web browsers that make their work closer to craftsmanship than the cold logic of programming languages would suggest.
Ultimately, I think there are some subjectivity and social image at play here, and I’d like to see that pay gap shrink in the future.
In conclusion
If you’d like to learn more about the topics covered in this article, here’s a shortlist of potentially valuable resources:
Don’t hesitate to reach out to me too; I can talk about this kind of stuff all day!
