Why I Care About Design as Much as Code

There's a version of frontend engineering that stops at "does it work." The button clicks, the form submits, the data loads. Technically correct. Job done.

I've never been able to stop there.

I think it comes from the kind of problems I've been drawn to since I started building. A lot of what I work on isn't for people who live inside software all day. It's for people trying to run a business, register a company, get compliant, get paid. People who don't care about your component architecture. They care about whether the thing in front of them makes sense in the next ten seconds, or whether it makes them feel lost and stupid for not already knowing how it works.

That gap between "technically functional" and "actually usable" is where I spend most of my attention now.

I'll give you a real example, without naming names. I was working on a flow that involved a genuinely complex legal process, the kind of thing with real requirements, real steps, no way around any of them. The engineering side of that was straightforward enough: forms, validation, data moving where it needed to go. Nothing groundbreaking from a code perspective.

But watching how intimidating that flow felt to someone going through it for the first time taught me something. The problem wasn't the steps. The steps were necessary. The problem was that everything about how it was presented, the language, the pacing, the labels, made it feel harder than it actually was. Renaming one thing, breaking up dense information into smaller pieces, choosing words a non-technical person would actually understand, none of that touched the underlying logic, but all of it changed whether someone felt capable of finishing the process or gave up halfway through.

That's the part clean code alone doesn't solve. You can write the most elegant function in the world and still ship something that makes a real person feel small and confused using it.

I think a lot of engineers treat design as someone else's job. Hand it off, implement what's given, move on. And to be fair, I'm not a designer by training. I don't obsess over pixel-perfect spacing or typography theory. But I care deeply about the experience underneath the design, whether something feels clear, whether it respects the person using it, whether it assumes too much knowledge or too little patience.

Maybe that's the real distinction. Design, to me, isn't about making things pretty. It's about making things make sense. And that's not a separate skill from engineering. It's the same skill, aimed at a different question. Engineering asks "does this work." Design asks "does this work for the person in front of it." I don't think you can fully answer one without caring about the other.

So when I build something, I try to hold both questions at once. Not because I'm exceptional at either individually, but because I think the products that actually matter, the ones people trust, the ones that make hard things feel simple, come from someone who refused to separate the two in the first place.

That's the kind of builder I'm trying to be. Not just someone who writes code that runs. Someone who builds things that make sense to the person who needed them in the first place.

If you're building something and thinking hard about how it should feel, not just how it should work, I'd love to hear about it. Connect with me on LinkedIn or follow along on X as I keep writing about this stuff.

If you're building something and thinking hard about how it should feel, not just how it should work — I'd love to hear about it. Connect with me on LinkedIn or follow along on X as I keep writing about this stuff.