I've been coding for about two years now and it changed my relationship to my role as a run-of-the-mill product designer spending most of his day in some sort of design software.
It already began many, many years ago: Moving rectangles on a canvas started to feel like a crutch. Most of the time I already know what needs to happen and what lies between me and having done a good job is pushing stuff around in Figma until what I think should be visible is actually visible. It feels like a chore.
Even though my day job isn't a Swift/SwiftUI based project, I've started creating prototypes with SwiftUI just to scratch my itch to do something "real". The code is as throwaway as it can get but it feels better — and somehow more productive — to create an empty data state based on if an array is empty or not than to duplicate a frame, call it "FeatureName / Empty Data State" and consider my job done.
Enter: The Design Engineer
"Design Engineer" is not a new term. I've known about the concept for years but somehow only considered becoming one after reading Jim Nielsen's piece on Design Engineers the other day:
The problem of innumerable artifacts helps show why design engineers are worth their weight in gold. They can bridge the chasm of design to browser engineering, skipping the need for 60+ artifacts. How? They have an understanding of the constraints of the medium, so from sketches to wireframe to high fidelity mocks, they only have to produce one or two artifacts while simultaneously keeping a picture in their head of how the elements of those designs flex and flow and change across different sizes. They can imagine how it works, so they don’t have to articulate it for every iteration. There’s no need to explicitly design and document all possible states for whoever is downstream of the designs because they are the ones downstream of the designs.
That could be me! Most of it is me already, I only lack some of the skills (and currently also the environment) to produce code on a reliable basis.
In Jim's second post he shares an example of what a Design Engineer could bring to the table and I adore everything about this. This is the stuff I love spending hours and hours on to get right. For most of my career I was dependent on a developer who put up with me and my dEsIgN-eXcElLeNcY shenanigans. It's hard to find frontend devs with an appreciation for this kind of work and even if you find them, there's still an obvious translation layer that can be a barrier between vision and result.
Transforming Marcelf Transforming myself
So, what's next? Do I want to become a Design Engineer? Imposter Syndrome and fear of failure tell me that it's a safe bet to just stay in my lane, create my little PNG files and be happy with what I've got.
However, I doubt that this will be good enough for me in the medium term. I very much enjoy fiddling with code to get something working in a user-friendly and good looking way. I even believe that the future of computing requires designers to code. So there's really no choice, if I'm honest with Marcelf myself.
I'm on a good trajectory with Swift and SwiftUI. It's the iOS/iPad OS/VisionOS framework of the future and Apple's ecosystem is the playground of my choice.
My HTML and CSS skills aren't embarrassing but especially the latter has quite a few depths I haven't charted yet. I built one or two things in React and played around with Framer Motion. Both are fun.
I feel like this could be a solid foundation for a toolkit that helps me to morph from "just" being a designer who codes to becoming a design engineer. It's time I get the reps in, especially in terms of all things web development. I want to become very good at using Framer Motion.
All of this is of course only relevant if I can't come up with a solid project that catapults me into the indie dev league. At the same time becoming a design engineer is the best way of honing my coding skills to become an indie dev.
That's what I like to call a win-win situation.