Why I stopped calling myself a Frontend Engineer
I never had a single moment where the title stopped fitting. It was a slow accumulation of evidence that I was doing something the label didn't quite cover.
I am still in the middle of this shift. I haven't changed my title at my current company. I haven't rewritten every profile. But something clicked a while back, and I haven't been able to unsee it.
For most of my career, "Frontend Engineer" fit well enough. It got me hired. It described the layer I lived in: the browser, the component, the interaction. But over the last two or three years, I kept finding myself doing work the label didn't cover.
I was opening Figma before the handoff arrived. I was flagging things that wouldn't survive contact with a real browser before anyone had written a spec. I was building prototypes to make a point in a design conversation, not to hand off to someone else. I was doing design work. I just wasn't calling it that.
A designer I worked with closely saw it before I did. She noticed I was thinking about the design before touching the code, that I'd show up to conversations already having worked through ideas in Figma. We were building things together, not in sequence. She didn't use the title "Design Engineer" specifically, but what she described was exactly that.
Hearing it reflected back made something land.
What actually changes
The shift isn't about knowing Figma. It's about when you show up in the process and what you feel responsible for.
A Frontend Engineer receives a design and builds it faithfully. A Design Engineer asks whether the design should exist in that form before building it. Those are different jobs, even when the output looks the same.
In practice it means: catching the focus trap before it ships, not after. Noticing that the animation spec will drop frames on a mid-range device. Asking whether the component pattern being established now will cause problems in six months. Caring about perceived performance as a design concern, not a backend problem.
It also means more friction, at least at first. Designers don't always love it when an engineer shows up with opinions about the design. But the friction was almost never about the work itself. It was about trust, and trust builds over time when you come with alternatives instead of just objections.
Why I'm writing this now
The role is starting to get named more explicitly. Companies are posting for Design Engineers specifically, not frontend engineers with design skills, not UX engineers, not UI developers. The language is getting more precise, and that precision matters because it points at something real.
It also means the bar is getting clearer. Having opinions about design is not enough. Knowing Figma is not enough. The expectation is that you can look at a design and see the component lifecycle behind it, feel the performance constraint before it ships, and make the right call in code without waiting for someone to spec it out for you.
That is a specific skill. It takes years to develop. And for a long time there wasn't a clean word for it.
Where I'm going
I want to work at the level where design and engineering are one continuous decision, not two handoffs. Where I'm responsible for whether the right thing gets built, not just whether it gets built correctly.
That's what Design Engineering means to me. Not a title upgrade, not a rebrand. A clearer description of the work I actually want to do.
I'm figuring out what that looks like in public. This is the first post.
If this resonated, follow along. I'll keep writing about design systems, UI craft, performance, animation, and the space between design and engineering where most of the interesting decisions live.