The Design Engineer Isn't New

The “design engineer” is having a moment right now. Vercel calls it a new role, but it’s really an old idea rediscovered: people who design interfaces and can build them.

It makes sense why. AI tools have made coding and prototyping more accessible than ever. Designers who never touched JavaScript can now prompt their way to working prototypes and engineers are experimenting more directly with design systems.

But the underlying idea is not new. Disney figured this out in the 1950s when they created Imagineering. The current wave of enthusiasm around “design engineering” feels fresh, but it’s really a rediscovery of something Disney built into its DNA seventy years ago—blending imagination with execution.

What Imagineering is

Walt Disney founded WED Enterprises in 1952 to design Disneyland, and the term “Imagineer” literally comes from imagination + engineering. They were building experiences, and the people creating them needed to understand both the creative vision and how to actually make it real.

Take Bob Gurr. He designed the Autopia cars, the Matterhorn Bobsleds, the Monorail, and the Haunted Mansion doom buggies. But he didn’t just sketch them and hand them off. He figured out how to actually build them. When he was assigned the Matterhorn, he had to teach himself trigonometry to get the angles right. He studied industrial design, not engineering, but learned what he needed to make his designs work.

Or Yale Gracey and Rolly Crump, who spent a year figuring out how to create ghosts for the Haunted Mansion. They studied stage illusions, built prototypes, and tested with massive sheets of glass. They designed the experience and engineered the illusion.

Even the more artistic Imagineers understood the technical side. Marc Davis, who designed scenes for Pirates of the Caribbean and Haunted Mansion, stayed closely involved as things were being built. He didn’t just draw pirates and say “good luck.”

Disney didn’t build teams of specialists who tossed work over walls. They built teams where everyone understood the full picture, from concept to construction. Some, like Gurr, could do both. Others, like Davis, collaborated deeply across disciplines. Either way, they eliminated the handoff.

How we got here

It’s easy to see how tech took a different path. As products scaled and systems grew complex, specialization made sense. Teams needed experts, and deep focus produced breakthroughs. But when that separation turns into a wall, things start to break down. Designs get created without understanding implementation complexity. Code gets written without the full design intent. Details get lost in translation, the back-and-forth burns time, and the experience suffers.

Disney Imagineering structured both their mindset and organization around avoiding those walls from the start. People weren’t just “staying in their lane.” The whole point was to blend creative imagination with technical know-how.

Why it’s gaining traction again

That’s why the current interest in design engineering feels more like a return than a revolution. There’s growing excitement across the design and engineering community, even if there’s still debate about what the role actually means. Some see it as a rebranding of front-end engineering, others as a hybrid craft that sits between design and development. What most agree on is that the gap between design intent and implementation is worth closing.

AI plays a part in this shift. Tools like GitHub Copilot, Vercel’s own design systems, and emerging prototyping assistants make it easier for designers to prototype in code, or for engineers to experiment visually. But it’s not just AI. Better component libraries, shared design tokens, and more collaborative workflows are all nudging us toward a more integrated way of working.

A personal lens

I’ve been working this way since the start of my career, back in my WordPress days. I never wanted to just design something in Photoshop and hand it off. I wanted to get into the CSS, the JavaScript, and the PHP to actually build what I was designing and feel how it behaved. You can’t truly design something static. The real decisions happen once it moves, interacts, and lives.

That’s why the old debate “should designers code?” feels like the wrong question. It’s not about whether designers should write production code. It’s about whether they should understand how things actually work. Whether you’re designing a theme park ride or a web app, you need to get your hands into the mechanics of it. That’s what design is.

Working across both design and code has made me better at both. Understanding implementation makes me a better designer. Understanding design intent makes me write better code. Bob Gurr’s grasp of design made him a sought-after engineer. His engineering knowledge made his designs buildable. The mindset of empathy and curiosity across boundaries is exactly what made the Imagineers so valuable, and it’s what design engineering is rediscovering now.

The label “design engineer” is fine. If it helps companies hire people who think this way, great. If it gives designers permission to code, or engineers permission to care about design, even better. And if AI makes this mindset accessible to more people, that’s progress too.

But let’s not pretend it’s brand new. Disney showed decades ago that the best experiences come from people who bridge imagination and execution; whether that’s one person doing both or a team that truly collaborates.