Somehow, I managed to build and release a new app this year. It’s called Unhinged, and while my opinion is obviously biased, I genuinely believe it’s the best mood-tracking app out there.

Unhinged checks in with you three times a day, asking how you’re feeling and what you’re doing. Over time, it gives you valuable insights into the factors that shape your mood.

I’ve been using Unhinged since March, and it’s fascinating to see how my mood shifted dramatically after finding a new apartment in Hamburg at the end of May. It’s also clear that the second half of the year has been one of the best ever.

There are plenty more insights hidden in the data. For example, my mood is almost always 'Very Good' in the morning block if I’ve gone for a run. I also added a feature to tag people in entries, which has helped me track how different people’s company influences my mood.

Now is the perfect time to start mood tracking. 2025 hasn’t started yet, and you could have a full year of data by the time I release the '2025 Mood in Review' feature. (No promises, though. It’s just something I’m hoping to work on.)

You can download UNHINGED for free on the App Store.

Gavin Nelson recently redesigned his portfolio and it's looking ✨crisp✨. I wondered how to get an iPadOS hover effect like that to work and with quite a bit of help of my friend Nils, a few discussions with ChatGPT and finally understanding LayoutGroups in Framer Motion, I present to you this solution. I'm sure it's far worse than Gavin's, so please don't think I know what I'm doing.

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.

After babbling about Products People Want to Use I started to work on a shopping list app. Not because I had a strong vision of what I wanted to build, no, only to have something to work on and not lose my momentum.

The app, called Zettel, reached an interesting stage I felt was worth sharing. It looks great, it is more or less feature complete and it works, I've used it for all of my recent grocery shopping trips.

There's only one catch: It doesn't feel right. Stanley Kubrick said "The truth of a thing is in the feel of it, not in the think of it." and this is one of those moments. Something about the gestures, the giant tap targets and how adding items works is not right. The vibe is off.

I still have a couple of ideas that will most likely result in a complete redesign of the whole app. Before that happens, I wanted to share the current state for archival purposes.

The other day, I realized why I’m not motivated to finish my current app project. It’s a gratitude journal that isn’t crammed full of esoteric features and inspirational mantras. It would fit perfectly into my existing product portfolio and is genuinely fun to use.

After forcing myself to work on it for a couple more weeks, while only making incremental improvements, I couldn’t pretend anymore and took a few days off. Then it finally hit me:

It’s yet another app people don’t want to use.

They think they want to use it. They know they should use it. But in the end, it’s one of those “I guess I should try to incorporate this habit into my life” apps. Just like my others:

• Henlo: “I guess I should start reaching out to friends more.”
• Stoins: “I guess I should walk more.”
• Peat: “I guess I should work on my habits more.”

I might be a bit biased, but all of those are great apps. They actually help people achieve their goals.

It’s just that I don’t have it in me to create another app like that right now.

Improving your social life, health, and habits takes weeks of work before you notice a difference. I’d like to work on something that provides value as soon as you download the app.

I decided that my next app will provide value in seconds. I put the gratitude journal app on ice and started working on a little app that solves one of the annoyances in my life.

Yay for not succumbing to the sunk cost fallacy.

It happened. The switch flipped and I‘m now one of those people who believe that it‘s far more productive to design in code than to move boxes and text in some design software.

I spent the last decade not wanting to believe the people who praised designers who code, but I‘m convinced now.

It‘s been about a year since I worked through 100 Days of SwiftUI. I built four iOS apps and about 4-5 web projects using React since then. I‘m obviously still a coding-baby but it‘s already very clear to me that being able to code made me a better designer.

AR interfaces are going to take this up a notch.

Three years ago, when I had an epiphany and realized that AR/VR interfaces are going to be the future of computing, I wondered how current design software would ever be able to allow me to do a good job designing AR interfaces.

I came to the conclusion that it wouldn‘t. It couldn’t.

If I would wait until the Figma of AR/VR interface design shows up, I‘d be behind the curve of what‘s going to be considered modern interfaces in the blink of an eye.

Fast forward to earlier this week, three years later.

I‘m downloading the visionOS SDK, after watching a couple of WWDC23 sessions about spatial computing and how to use SwiftUI and ARKit to create AR experiences for what has a good chance of becoming the AR platform of the future.

I was right.

You can‘t design AR experiences in Figma. Floaty 2D windows are only the baseline of what’ll be expected. The bare minimum.

True modern experiences will switch fluently between 2D windows and immersive experiences.

Designers need to be ready for it.

I spent the week playing around with visionOS, trying out interactions, building small apps and getting a literal grip on how to interact with 3D models in AR space and I‘m convinced that I‘d be utterly lost hadn‘t I spent the last couple of years working on what will be (is?) the required skillset for AR interface designers.

Designers need to understand 3D modeling, meshes, materials, textures, shaders, faces, vertices and edges. I knew nothing about any of this three years ago and it was already required knowledge in this very first week of AR interface experimentation.

Designers need to be able to code. 3D drag gestures, interactive 3D models, a blend of immersive experiences and 2D windows in real life environments can‘t be properly reproduced in some AR-Figma of the future. AR design is the climax of self-efficacy in interface design.

Designers need to adapt to be able to provide experiences that are as personal as spatial computing is going to be. They can’t be several degrees removed from what users are going to interact with anymore.

Being a designer who codes makes you a better designer in 2023.

Being a designer who doesn‘t code might make you a bad designer in 2024 and beyond.