I keep seeing developers draw hard lines between front-end, back-end, and “UX” as if they are separate worlds. A front-end colleague will say they do UI design when what they really mean is that they craft the styles. A back-end colleague will say they don’t touch UX because they never go near the interface. Both lines bother me because they shrink the work and miss the point.
The “I” in UI stands for interaction, not ornament. An app can be visually plain and still feel great to use. It can also be beautiful and still feel broken. What matters is what happens between the person and the system: the next step should make sense, the feedback should arrive fast enough, and the whole thing should feel trustworthy. If we are not thinking about that interaction, we are not designing the UI. We are just decorating it.
That responsibility does not stop at the API boundary. Back-end developers make choices that land directly on the user, even if the user never sees the code. A query that takes too long, an endpoint that returns more data than it should, a missing index that turns a quick action into a spinning wheel. These are experience problems. The user feels them as frustration, as hesitation, as the small push that makes them wonder whether the tool is worth the trouble.
I want the back-end developer who optimized a query to know the story behind it. Not just “this is 150% faster,” but “this keeps someone from giving up while they wait.” Speed for its own sake is a vanity metric. Speed that protects someone’s attention and momentum is the point. And sometimes the best way to speed things up is not a better query at all. It might be caching the data that everyone asks for the same way, or splitting work so the screen can show something useful while the rest finishes. The solution lives in the experience, not in the database alone.
The same thing shows up in code reviews. I have watched a front-end change get praised for looking polished while the interaction it supports still makes people guess. I have also seen a back-end fix celebrated for raw performance when no one asked whether it actually solved the slowness a user was feeling. We reward the part we can see or measure, and we skip the harder question: what is it like to use this?
I am not suggesting every developer become a designer. But every developer should understand the basics of user experience because every decision we make sends a message to the person on the other side of the screen. The database engineer, the CSS specialist, the full-stack generalist, the infrastructure person keeping things running. All of us shape what the user feels.
What I am learning is that the best teams stop asking “whose job is UX?” and start asking “what will the person using this experience?” That question belongs to everyone.
Leave a Reply