"The Truth of a Thing Is in the Feel of It, Not in the Think of It"

Since I heard this quote from Stanley Kubrick for the first time a few weeks ago, I couldn’t let go of it. It encapsulates a moment in design that makes me feel like a hack every time it happens.

I’m a stern believer that software design is a craft, not an art. There are artsy aspects to it, but for most of the time, rules can and should be followed. They’re flexible and complex, but not inexistent.

Another belief of mine is that designers have to be able to argue for their solutions. A working designer’s inner monologue should be the Socratic method that is being applied to every design decision, no matter how small.

Sometimes, truly not often, there are moments where this isn’t enough. You know what the correct solution would be, the one with the most arguments, the one that fits the rules, but it just doesn’t feel right.

There’s no way to explain this to those who don’t feel it. They just have to trust your instincts. Sometimes, designing something the wrong way creates the right solution.

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.

I’ve been programming for a bit over a year now and I’m far from giving substantial advice on how to write good code. What I actually do know a bit about is the right mindset for shipping products.

Perfectionism

Embrace the truth that wanting to ship something perfect is the same as not shipping anything. You’ll never(!) get to a point where everything is to your absolute liking. It’s impossible. It has nothing to do with how skilled you are either. You can be the very best designer and programmer ever, entropy doesn’t allow perfection. On the contrary: Entropy is perfection. Embrace the fact that “good enough” is a moving goalpost. It means that you don’t have to try to be perfect. How soothing is that!?

Imposter syndrome

You’ll never be as good as you think you should be. I feel like human existence is a binary state. Either you’re overconfident or suffer from imposter syndrome. Both are problematic but the latter is easier to manage, in my opinion. Acknowledge the fact that your being capable of shipping something in theory is good enough to do it in practice. Worst case: Nobody will care about your project. The good news: That’s already what’s happening. There’s no chance anyone will ever truly care about your unreleased project and pre-release hype is not real.

Maximalism

Ideas are cheap. You don’t want to be one of those people that are stuck in “Wouldn’t it be cool if…” land and never get around to actually confronting their ideas with reality. Or reality with their ideas. The common pitfall is to think that you only have to cram enough ideas (read: features) into your product for it to be the very best out there. The opposite is the case: You need to get rid of all the features that don’t reflect the essence of what you’re trying to do. There’s a reason why basically everything ever written by people who ship reiterates this point over and over: it’s true. Confronting your ideas with reality can’t happen fast enough.

The right goals

This might be the most important point: The product isn’t the destination. Shipping is. If you think that your current idea is the be-all and end-all, you’ll most likely make the aforementioned mistakes over and over again. Good ideas, loosely held. Shipping must be the motivation because only shipping creates the positive mental feedback-loop that is required to keep shipping. If you’re somebody who shipped something once, you can do it a second time and the third time is even easier. That’s the process. You build, you ship, you keep building. A project fails? You don’t care because you’re in it for the process of shipping and iterating.

The status quo is the worst case. Ship yourself out of the status quo, everything else will follow automatically.

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.