On being a product designer who builds

I have been in rooms where “Design Engineer” meant a designer who can prompt a prototype, and rooms where it meant someone who will debug the interface on a Tuesday afternoon. Those are not the same job. Pretending they are wastes everyone’s time.

Karl Koch wrote about this while hiring: the title has to match what you can take responsibility for today, including the engineering part. I agree. I will not put Design Engineer in the masthead and make you work backwards from a case study to find out whether I can ship.

What I will own is this: a product problem, through design, into production UI. That includes the system, not only the screen. It includes accessibility and performance. It includes looking at why something broke, and leaving a change that another person can maintain. I have done that with design systems in Figma and Storybook, with React and Next.js, with tokens that exist in code as well as in a file.

I still work as a Senior UX Designer. Housemark is the current role; Cytiva was the one before. The design judgement is not in question. The question for a Design Engineer hiring manager is whether I will take the implementation, not hand it over with a spec and a smile. I will. I have. Warp already called it UX Engineer. Dot Studio was design and build. The Feefo system was not finished when the Figma file was tidy — it was finished when engineering could use it.

AI can write a convincing prototype. That is useful. It is not evidence that I can take responsibility for what ships. I care whether I can explain the decisions, recognise the problems, and work through them in the real product.

If you are hiring for a Design Engineer — in-house or contract — and that is the work, say so in the spec and I will say so in the application. If you need a product designer who stays on the Figma side of the wall, I am the wrong person to spend three interviews on.

The relevant experience should be easy to find. That is the point of this site.