The Design-Developer Gap, and the Roles Growing in Between

Egor Kloos describes a familiar failure mode: a designer requests small visual changes to a component, a developer implements exactly what was asked—and the actual need, a bug fix plus a new component variation, goes unmet. The root cause is siloed skills, not a lack of effort on either side.

Designers move from idea to a wireframe, a prototype, a logo, or even just a drawing. Developers move from a problem or feature to a coded solution that is solved and released. Both are creative, both are in aid of the end-user. The Design Engineer role is also creative and authors code but systematically translates a design towards implementation in a structured way.

From Webmaster to Specialists—and Now "Glue" Roles

Design Engineering is gaining traction as a discipline, with coverage on ShopTalk featuring Natalya Shelburne and in a dedicated handbook. It reads as a sibling to "DesignOps," a term that Cameron Moll recently questioned on Twitter, drawing a range of instructive replies.

The trajectory of these roles is instructive. The original webmaster did everything. That monolithic role split into front-end and back-end development. Design, once loosely grouped under front-end, became its own clear discipline. Back-end work subdivided again, spawning DevOps. Front-end has fragmented the most—see the distinction between the "Front of the Front / Back of the Front"—and now contains specialists in areas like performance and accessibility.

The pattern is consistent: roles pull apart as the haystack of responsibility grows, then "glue" roles emerge to bridge the divides they created. Expect that cycle to continue.

There is even talk of hyper-specialized jobs—Dave Rupert and the author have speculated about roles wholly dedicated to handling images. Meanwhile, those who have spent careers on small teams often avoid the worst of the gap, simply because proximity and shared context push people to see across those silos.