The Shift Design Created

October 22, 2025 · 1301 words · 7 min read

What changed in my work once I learned to see the structure of experiences.

I was out for drinks a few weeks ago with a couple of designer friends who say things like "spatial hierarchy" while reaching for the chips, and at some point the conversation turned to work. They were going back and forth about some layout problem and I found myself jumping in, holding my own, actually having opinions about type weight and visual flow and where attention falls on a screen. At some point someone asked me when I started caring about this stuff. I didn't have a quick answer. It happened gradually, over years, and I've never really tried to trace it. So I figured I'd try.

I spent a good two years at my last job convinced I understood the products I was working on. I could trace the logic of any system we built, read the code, follow the data, explain how every piece connected to every other piece. If the system made sense, I figured, the product made sense. That felt like a reasonable thing to believe. Nope, it wasn't.

The gap was in a place nobody was watching. We had this flow that was, by every internal measure, correct. The data moved where it should, the states were clean, the edge cases were handled. And people kept getting confused by it. Everything worked, nothing was broken, but the way the information was structured told a story we didn't intend. The system said one thing. The person reading it heard something else.

I remember sitting in a call with my manager, staring at the screen, and realizing I had absolutely no framework for understanding why. The engineering was fine! The logic was fine! Yet some unknown between the system and the human was misfiring, and I couldn't even describe the shape of the problem. That's a very specific kind of helplessness, where you can see the failure happening but you don't have the words for it. It can and should humble you.

I tried to logic my way through it for a while because that's what I knew how to do, stare intensely at the interface and try to deduce why this layout confused people, why that label sent them down the wrong path. Sometimes I'd get lucky and land on something that worked, but I could never explain why it worked. Next time I'd be just as lost. And the plans always made sense, the intentions were always right, but the experience kept behaving with a logic I couldn't follow. Foreign, somehow, even though I'd built the damn thing.

A friend outside of work changed that for me. They came from a design background and they had this way of looking at interfaces that I'd never encountered. We'd be talking about something I was stuck on and they'd ask these simple questions from an angle I'd never considered. What does this screen feel like the first time you see it? Where does the eye go, and is that where you want it to go? What's the emotional state of someone who lands here?

I had never thought about any of it. I'd been so deep in the system itself that I forgot there was a person on the other side of it, having an experience that had nothing to do with how clean the architecture was. That realization was embarrassing. Years of building products and I'd been looking at half the picture the whole time.

I kept coming back to them, though. I'd show them a screen I was working on and they'd rework it, same content, same data, completely different feeling. And I could see it was better immediately, every time, but I couldn't have gotten there myself. That gap drove me a little crazy. They started sending me things to read too, Don Norman, random blog posts, the occasional tweet thread that reframed something I thought I already understood. I'd read it on the way home or late at night after the missus had gone to sleep, and slowly the vocabulary started forming. Words for things I'd been bumping into for years without knowing what to call them.

The shift itself didn't happen in a single conversation, it built up over a few months of thinking differently about the same problems, of reading, of watching someone else look at my work and show me what I was missing. And the more I studied it, the more I saw that most products don't fail because the idea is bad or the engineering is weak. They fail because the interpretation drifts. Your team thinks the product says one thing while the user hears something completely different, and if you're only thinking in terms of systems, that drift is invisible. You can't see it. You don't even know to look for it!

Once you learn to look, though, you catch it everywhere. In your own work first, which is also deeply humbling.

The way I work changed after that, and the change surprised me because it was so quiet. When I stopped leading with "can we build this?" and started leading with "what will this feel like?", I also started noticing the places where confidence grows in a flow and the places where it drifts (sometimes in the same screen, which is maddening). I noticed how a slightly wrong label or a misplaced element can undo weeks of careful system work. Very often, the interface is the product, at least from the perspective of the person using it. I don't know why that took me so long to internalize, it seems obvious now.

That kind of awareness also carries a hidden cost! Once you understand how hard clarity really is, you stop tossing off quick opinions about what a screen should look like. In turn, slow down, leave more room for the work to breathe, a small structural change could take days to get right and you don't rush it, because now you understand why it takes that long. You also begin to question your own assumptions before anyone else's, which is uncomfortable. But you also get more patient, because the full surface is finally visible and you can see just how much of it there is.

People like to say design is simple. Talk to users, use common sense, don't overthink it. I get the appeal of that assumption, but common sense doesn't explain why two solutions that look almost identical can create completely different experiences, or why something that looks cleaner can feel heavier, or why fewer steps can somehow confuse more people. I used to think those were edge cases and weird contradictions you'd bump into occasionally and shrug off. They're structural! You only see them once you learn to look, and then you wonder how you ever built anything without seeing them.

What design gave me was a way of perceiving the work that I simply didn't have before. The ability to follow an idea from intent to impact without losing the thread, to spot where meaning might break long before a real person runs into it. I used to reserve that kind of rigor for the system, for the code, for the parts I could trace and verify, now I apply it to the experience too. The work is harder for it. It's also better! I've stopped trying to separate those two things.

If product work ever feels like flying, it comes from that clarity. The moment the surprises fade and the decisions start connecting from thought all the way through to execution, and you can see the whole shape at once. It's a genuinely great feeling! Fragile, though. You learn pretty fast that clarity is something you rebuild every single time, from scratch, on every project. Surprises are great at birthdays and terrible in UX. I've made my peace with that, mostly.