I've been trying to position myself as a Design Engineer lately.

The funny thing is that I've been doing some version of this for most of my career. I just didn't have a name for it.

I studied Systems Engineering first, back in the early 2000s. While I was building things, I started noticing that I cared a lot about how people actually interacted with them. The interfaces weren't good enough. I wanted to understand that part too, so I studied Graphic Design.

Even then, I was always attracted to the digital side of design. I wasn't particularly interested in the physical or manual parts of it. I wanted to make things on a screen. Digital print, animation, Flash, websites. Things that moved and did something.

So I started my career doing both. Designing and developing.

At some point around 2010, my career became more clearly Product Design. But I never really stopped coding.

And I think that's part of why I've never felt completely like a designer.

It's not that I don't care about design. Obviously I do. I've spent most of my career doing it. But there are parts of the way we practice design that don't come naturally to me.

I tend to want to get to the point.

Recently, during a design critique, I was trying to validate an entire flow. I was thinking about whether the product idea worked and whether the experience made sense as a whole. The conversation started moving toward individual pieces of UI and how we could improve them.

There was nothing wrong with that conversation. Those details matter.

But I remember thinking: that's not the question I'm trying to answer yet.

I'd rather get something working, try it, put it under some stress and learn from what happens. I like iteration, but my idea of iteration is increasingly less about producing another artifact and more about changing the actual thing.

That's probably where I start feeling some distance from other designers.

I'm not very interested in creating ten different explorations just because we're supposed to explore. I don't want another document unless the document helps us make a decision. And when something can be tested as a real thing, I'd rather do that.

Then I sit with engineers and almost the opposite happens.

I actually feel very comfortable with the way many engineers approach problems. What are the constraints? What can we build? What is actually happening? How do we solve it?

And then the conversation gets deep enough technically and suddenly I feel like the stupidest person in the room.

I can follow a lot of it. Sometimes I can't. I ask questions. I try to keep up.

And sometimes I feel like I need to prove that I know enough technically before my opinion carries the same weight. Occasionally I even feel that people are being a little condescending because I'm "the designer." Maybe they are. Maybe that's just my own insecurity. I honestly don't know.

That's the strange part of being somewhere in the middle.

Around designers, I can feel like I'm not enough of a designer.

Around engineers, I can feel like I'm pretending to be an engineer.

But when I'm actually building something, a lot of that disappears.

And by building I don't just mean designing directly in the browser.

I like understanding what happens to an idea after the screen is designed. How it gets implemented. How it integrates with everything else. What happens when I commit it. What happens in CI. What checks run before it can go to production. What breaks and why.

Sometimes that means creating my own tools around the process. I've built things like Lint UI because I wanted a way to catch UI problems as part of the same workflow we already use to catch problems in code.

That instinct probably comes from engineering more than anything else.

When I studied engineering, the point was to build something useful that solved a problem. I don't think I ever really lost that.

It's also why working on something real feels completely different to me than finishing it in Figma.

I can see the real pixels. I can resize the window. I can see what breaks. I can try it on another device. I can experience the responsive behavior instead of describing it. But I can also see what happens around the interface: the code, the integrations, the checks, the deployment and all the small decisions required to turn an idea into something that actually works.

Most importantly, it feels like I'm working on the thing itself.

Figma is incredibly useful, and I use it every day. But a finished set of Figma screens still feels like a representation of a product to me.

The product is everything that happens after that representation too.

Maybe that's why I've kept coming back to code for twenty years.

Today there's finally a title that seems closer to describing this kind of work: Design Engineer.

I've been trying to position myself that way.

But even that creates another problem in my head.

If somebody changed my title tomorrow from Product Designer to Design Engineer, would I suddenly feel like I belong?

Maybe.

And then I'd probably start worrying that I'm a bad Design Engineer.

I'd look at engineers who understand parts of the stack much more deeply than I do. I'd find another gap. Another thing I should know. Another reason why maybe I don't quite deserve the title yet.

I've spent enough time doing this to recognize the pattern.

The titles have changed much more than the way I like to work.

I like solving problems. I like making things. I like understanding enough of the business, the user, the interface and the technology to connect them. And I like shipping something and seeing what happens when it meets reality.

After almost twenty years, I'm still not sure which side I'm supposed to belong to.

But I've realized that working somewhere between the two is exactly what I enjoy.

CONTINUE THE CONVERSATION

How is your team connecting design decisions to what ships?

Share your experience