Design is not decoration
What three years of working with designers taught me about what design actually is.
I used to think design was what things looked like. After three years working alongside people who actually know design, I understand that’s like saying surgery is what scalpels look like.
Design is decisions. It’s the process of deciding what a thing should do, for whom, and in what order. Aesthetics are downstream of those decisions. A beautiful interface built on bad decisions is still a bad interface — it just takes longer to notice.
The critique that changed how I think
Early in my second year, I presented a component I was proud of. Smooth animations, good spacing, clean code. The lead designer looked at it for about ten seconds and said: “What does a user do if this fails?”
I hadn’t thought about it. The happy path was polished. The error state didn’t exist.
She wasn’t being harsh. She was pointing at the gap between making something that looks done and making something that’s ready. Most of what I thought was “design work” at that point was surface — colors, spacing, motion. The actual design work — what happens when things go wrong, how the user recovers, what feedback the system gives at each step — I had been leaving to someone else.
Interface development is design
This is something I’ve come to believe firmly: if you’re building interfaces, you’re doing design. You’re making decisions that shape the user’s experience, even if you’re not the one who did the initial wireframes.
Recognizing that made me a much better developer. I stopped treating the spec as a literal instruction set and started asking the same questions a designer would ask: why this? for whom? what happens next?
The people who build the best interfaces I know of are the ones who can’t separate the two disciplines. They think in design while they write code.