In a recent conversation a peer asked me, “How does your company define Design Engineering?” The thing is, we don’t, formally—and I think a lot of companies do not either, yet. They’re all waiting to see how it1 shakes out. While the needs and skillsets have always existed in our industry (I see you, o.g. “web designers”), the role of a more formal design/engineering hybrid individual is still a newer trend at companies.
In this modern incarnation, I’m seeing 2 tracks emerge—and while they’re not necessarily incompatible at all, they’re very different.
The first: the frontend engineer under design leadership
This group’s day-to-day might not look all that different from someone with a Frontend Engineer (or UI/UX Engineer) title. They’re not doing product design work, per se. They’re working in code to build product UIs; they’re responsible for fit-and-finish, accessibility, and ensuring the experience for customers matches what has been designed by the company’s product designers. Maybe they work formally on the code components of a design system, or maybe they work at a company with a culture that can take early prototypes into the production pipeline. But the core difference between them and a Frontend Engineer is that they report to design/product leadership and not engineering leadership.
This group’s day-to-day might not look all that different from someone with a Frontend Engineer (or UI/UX Engineer) title
This track can develop for a lot of reasons—company politics around who should “own” the top experience layer, how a company and its leadership defines engineering (“only backend is real engineering”), and sometimes (but too rarely) a strong design leadership that believes their work doesn’t stop in Figma and embodies the user experience mission all the way through the product, at a technical level.
The second track: the hybrid skillset working in support of design and product, but not on the product
This group often falls into place because of design/product tooling needs that the company’s formal engineering group is either unaffected by (gaps in Figma and other design tooling) or simply under-resourced (or even uninterested) in handling.
Teams in this track primarily build tools. They prove the value of their work by helping designers and PMs move faster while reducing the effort and back-and-forth it takes for an engineer in the Engineering Org™ to understand a designer’s work and execute on it. But these design engineers generally don’t help build the work product they support. In some organizations, they might help prototype it, providing a fidelity the typical design tooling cannot communicate, but that’s as close as it comes.
These design engineers generally don’t help build the work product they support. In some organizations, they might help prototype it… but that’s as close as it comes
A converged track: the Design Engineer
What I’d love to see is more companies embrace a third track: it’s somewhere in the middle. There are opportunities within the work under a Design Engineer title to take both paths. Perhaps they move between each path regularly, or perhaps they’re niched between one or the other, but only on a project-by-project basis.
From a company culture and leadership level, the idea is to enable more people with a hybrid skillet to contribute to designing the product, while also building the product—and when warranted—supporting the first two in process and tooling.
Why would a company want to support this third track? It sounds messy.
A lot of change is on the horizon in product development. I don’t yet have any strong theories on how it all looks when (if?) the dust settles, but I am pretty sure of one thing: the connection between the discipline of product design and the user interfaces that our customers touch will only become tighter—less abstract with more direct inputs providing production-level outputs.
The connection between the discipline of product design and the user interfaces that our customers touch will only become tighter
Design Engineers are well-positioned to step into that gap as it currently exists and help close it from both sides. We know product design, we understand engineering—often with an emphasis on frontend/UI—and we’re uniquely-positioned to fulfill current engineering and design needs while working on tooling to pull the two closer together over time.
-
AI? AI interfaces? A/R interfaces? The metaverse? The next glorious JS framework to end all JS frameworks? The general vibes? We shall see… ⏎
A version of this piece was originally published on LinkedIn.