The Architect Who Never Was, Part Two

What changes when you design with an engineering mindset.

Design
Engineering
Career
Learning
Product
12 views

In the first part, I wrote about how an engineering path led me toward design. This is what happened next.

I studied construction engineering. Architecture was my favorite discipline within it — not the structural calculations, but the part that asked a different question: how do people experience space? Where do they pause? What makes them feel oriented, or lost?

Alongside that was descriptive geometry — learning to represent three-dimensional space through precise two-dimensional drawings. A discipline that trains you to hold complexity in your head and translate it into something others can build from.

I didn't know it at the time, but both of those skills would come back — just in a different medium.

Learning — differently this time

It started with books. Again.

And I made the same mistake. Again — picked up material written for practitioners, not learners. Too dense, too early.

But this time the recovery was faster. I already knew the pattern: step back, find a simpler entry point, build context before depth. The lesson from JavaScript didn't need to be relearned from scratch — just applied to a different domain.

What was genuinely different was where the useful perspectives came from. One resource that shaped how I approach user interviews had nothing to do with design at all. Sometimes the clearest lens comes from completely outside the field.

The other difference: structured courses existed now. When I was learning HTML, there was no defined path. Having an intentional sequence accelerated things — not because the material was easier, but because the order mattered.

Where the background helped

An architect knows materials before designing with them.

Not to lay bricks themselves — but to understand what bricks can and cannot do. What loads they handle. Where they fail. That knowledge doesn't slow design down. It changes what gets designed in the first place.

Starting design with that kind of foundation meant I could skip a certain kind of learning.

I already knew how interfaces are built — what happens after the handoff, where decisions break down, what constraints are real and which ones aren't. So instead of spending time on fundamentals, I could focus on something harder: people. Their problems, their context, the gap between what they say and what they actually need.

That shift mattered more than anything else that followed.

There was also the question of prototyping.

Design tools show how something looks. But appearance isn't what users experience — they experience behavior. How something responds to a tap. How a transition feels. What happens when data is missing or loading takes longer than expected. A static screen in Figma can look perfect and still hide all of that.

I wanted to test those things earlier than most tools allowed. My development background made that possible.

I discovered Framer  opens in a new tab — back when it was still a JavaScript library for building high-fidelity interactive prototypes. Real transitions, real gestures, real states. Not a mockup that looked like a product. Something that already behaved like one.

I followed Framer through its entire evolution — from a JS library to the tool it is today. That journey gave me something most design tools couldn't: the ability to think in behavior, not just layout.

Instead of asking how something should look, I started asking how it should respond.

The same was true of communication with developers.

An architect speaks the language of engineers — not to replace them, but to collaborate without friction. When you understand load, material, and construction sequence, conversations become about solving problems rather than translating intentions.

Working with developers felt the same way. Shared language meant less time explaining and more time deciding. You could discuss edge cases early, propose alternatives before they became blockers, and hand off work that was already grounded in implementation reality.

You stop translating. You start building together.

Telling web designers they don't need to worry about code is like telling architects they don't need to worry about steel, wood or physics. — Brad Frost, 2011  opens in a new tab

Where it gets in the way

The same background that helps can also create friction.

Design tools never felt quite right to me. I started with Sketch — a genuine breakthrough for the industry at the time. But it still felt like an abstraction from day one.

The problem isn't the tool itself. It's the gap between the medium and reality. In Figma you design pixels. In a browser, you design behavior, states, responsiveness, time. A screen in Figma is always perfect — the right data, the right size, the right moment. Real interfaces are never that. They have empty states, error states, loading states, unexpected content lengths, different screen sizes, different devices.

An architect who only works with drawings and never visits the construction site will miss things that only become visible when the building starts going up. The same gap exists between a design file and a shipped product.

That tension never fully resolved for me. But it made me more deliberate about what I put into design files — and more honest about what they can and cannot communicate.

And then there's the harder thing to admit.

You're not quite a developer anymore. But you're not quite just a designer either.

I remember sitting in design reviews where the conversation circled around visual details while I was thinking about loading states, edge cases, and what happens when the API returns nothing. We weren't solving the same problem — and that gap was sometimes difficult to bridge.

That in-between place can feel isolating. You see things others don't see yet. You also miss things they notice immediately.

It's not a disadvantage. But it takes time to learn how to use it well.

Product design — a different context

An architect doesn't disappear after handing over the drawings.

There's a concept called architectural supervision — being present during construction, seeing how decisions translate into reality, catching what doesn't survive contact with the actual material. The drawings were right. The building is different. That gap is where the real work happens.

My first design role was in outsourcing. And something about it never felt right.

Too many contexts. Too many industries. Too little continuity. You design something and move on. Someone else builds it, someone else evolves it. You rarely see whether it actually worked — whether the decisions held up, whether users found their way, whether the thing you made survived contact with reality.

I wanted to see the full lifecycle.

So I moved into product design.

And that turned out to be a fundamentally different kind of work — not because the craft changed, but because the relationship to it did.

In product, you're not producing outputs. You're shaping something that grows. You see what works and what breaks. You understand why certain decisions were made earlier and feel the weight of changing them. You're not a visitor to someone else's system. You're building your own.

And when something ships — you're still there. Watching how it's used. Seeing where it holds and where it doesn't.

That continuity changes everything. You stop optimizing for the handoff and start optimizing for what survives.

What this transition actually was

I didn't become an architect of physical structures.

But somewhere along the way — through engineering, through code, through years of designing products that had to survive real users and real conditions — I became something close to it. Just in a different medium.

The discipline is the same.

Understand your materials. Follow standards not because they exist, but because they matter. Work with engineers, not around them. Design not just for how something looks, but for how it holds up over time.

And stay present after the handoff. Because that's where you find out if the work was actually good.

That principle didn't stop applying just because the tools changed.

Even as a designer, I never stopped following how technology evolved. CSS grew into something I barely recognized from where it started — and that felt exciting, not overwhelming. New frameworks, new approaches, new tools. I kept learning, kept practicing, kept building things on the side. Not to stay employable, but because understanding how the medium evolves changes how you design for it.

That same principle now applies to working with AI. When you understand what's happening under the surface — even roughly — you can give it context, review its output, and catch where it went wrong. Without that, it's just magic. And magic works — right until something breaks and you have no idea why.

Looking back, the transition from development to design was never about changing what I do.

It was about finding the right medium for the way I already thought.

In the physical world, I never became an architect.

In the digital one, I learned to think like one.

Resources that shaped this part of the journey

These books, courses, and materials influenced me at different stages. Not all of them are beginner-friendly, but each became useful at the right moment.

Books

Courses

Choose resources based on your current level, not their reputation. The right material at the right time can shape how you think.