UI/UX vs Backend: Who Should Lead the Dance?

Author: Kelvin Anigboro | Backend Engineer

It wasn’t a direct question but a thought that popped into my head over Tea.

I was chatting with a product designer who recently joined our team. Nothing deep, just shooting the breeze about our project, but something clicked in my brain and I started wondering about something I’d never really put into words before...

Does UI/UX drive backend, or does backend drive UI/UX?

A pretty basic question, but I couldn’t shake it.

Two ways of looking at it

There are basically two camps on this, with loads of middle ground in between:

UI/UX First

Some people reckon the user experience should be the main priority. All the technical stuff, data structures, APIs, and server architecture are just there to make the user experience work. Their thinking goes:

1. Users couldn’t care less about your fancy database design

2. Technical limitations come and go; what users need stays pretty constant

3. Even the most powerful backend is useless if people hate using it

In its purest form, this means designing the perfect user experience first, then telling the engineers to figure out how to make it happen. It’s that “we’ll sort out the how later” attitude that’s behind some pretty revolutionary products.

Look at the original iPhone. Apple didn’t start by asking what was technically possible; they imagined how people should interact with mobile devices and then made the technology catch up.

Backend First

The opposite view says solid products need solid technical foundations. Interface design should work with what the system can actually do, not demand the impossible. The logic:

1. Technical reality wins in the end

2. Systems that are fast and reliable create better experiences anyway

3. Working within constraints often leads to more creative solutions

With this approach, the engineers establish what’s technically doable, efficient and scalable, then designers create the best experience within those boundaries.

Google’s search box is dead simple, but it’s designed around the realities of how their indexing and ranking algorithms actually work. The interface shows you what’s possible rather than driving what happens behind the scenes.

It’s not really either/or

After thinking about this for a while, I believe framing it as an either/or question misses the point.

The best products usually come from that constant back-and-forth between design and engineering - just real conversations, not power struggles. It’s not about who calls the shots, but about both sides pushing each other, asking tough questions, and figuring out better ways to solve the problem together.

In teams that really innovate:

• UX designers get technical constraints but know when to push back

• Engineers understand what users need and find clever ways to solve seemingly impossible design challenges

• Both sides know they’re ultimately serving the user, not winning internal arguments

It’s a dance, not a driver

Maybe a better way to think about it is like dancing. In ballroom, partners take turns leading and following, responding to each other’s movements. Neither is always in charge; the relationship shifts and adapts.

Good product teams work the same way. Sometimes UX leads with a bold vision that challenges technical assumptions. Other times, engineering leads with new capabilities that open up design possibilities nobody had thought of.

What matters isn’t who leads most often, but how well the partners work together and what they create.

What this means day-to-day

This way of thinking has real implications for how teams should work:

1. Start with problems, not solutions. Both designers and engineers should understand what users actually need before proposing interfaces or technical approaches.

2. Prototype together. Get engineers involved in early design, and designers involved in technical discussions.

3. Respect expertise but question assumptions. The best designer-engineer relationships involve mutual respect for each other’s knowledge, plus a willingness to challenge “the way things are done”.

4. Share the same goals. When both teams are measured against the same outcomes (user satisfaction, business impact), the artificial tension between UI and backend priorities starts to disappear.

5. Keep talking. Regular check-ins between design and engineering throughout development ensure both sides can adjust as new information comes up.

The nice thing about this topic is that it’s not binary at all. The relationship between interface design and technical implementation is on a spectrum, and different products or features might

For instance, if you’re building some crazy AR thing, you might need to push what’s technically possible to make it look cool. But for something like banking software? You better make sure that data is rock solid first. Most stuff we build needs a mix of approaches depending on what part you’re working on.

What matters is making these decisions consciously, knowing the trade-offs, rather than defaulting to one approach out of habit or office politics.

That tea chat with our product designer didn’t settle the question - nor should it have. The tension between interface vision and technical reality is actually a productive one that drives innovation when handled well.

But this chat got me thinking about something I’ve felt but never really put into words before. Maybe that’s the whole point: not finding a final answer, but asking better questions and building tech that actually helps people.

So, does UI/UX drive backend, or does backend drive UI/UX?

Yes. Both. Neither. It depends.

And that’s exactly how it should be.

Why stop here? Read our CEO's article on Protecting UK Data: Why Security and Sovereignty Matters Now More Than Ever