Navigating the Engineering vs UCD Debate as a Delivery Leader

As a delivery leader, I often find myself at the centre of heated team debates. These moments can be difficult to navigate—especially when your role demands objectivity to guide teams toward the best possible decisions.

One debate comes up time and time again: Engineering vs User-Centred Design (UCD).

It’s a familiar tension.

On the one hand, UCD practitioners advocate prototyping and validating ideas with users before any engineering begins. On the other hand, engineering teams want to build quickly, get something into users’ hands, and iterate based on real feedback. Both perspectives are grounded in good intentions—and both are right, in their own way.

At its core, this is a trade-off:

• Investing in upfront design and research

• Moving quickly with iterative delivery

• Managing the cost of idle engineering capacity

This isn’t about cutting corners or avoiding user research. It’s about deciding when and how much research is needed before building starts.

In my experience, this debate shows up in almost every product delivery environment—especially in complex organisations like government.

Where the Real Disagreement Lies

At a high level, most teams agree on the principle: You can build a set of core requirements and refine them through user feedback.

But the real disagreement sits beneath that:

• What counts as “core”?

• How confident are we in the problem we’re solving?

• What is the cost of getting it wrong?

Even experienced teams struggle here.

You’ll often hear it framed like this:

Engineering: “Let’s build the core first and refine later."

”UCD: “If the foundation is wrong, iteration becomes expensive.”

Both are valid. The tension isn’t about process—it’s about risk and cost of change.

A More Context-Driven Approach

My view is simple: the right approach depends on how well the problem is understood.

• If the problem is well understood, lean towards a technical-led approach. Build early, iterate often. The cost of change is likely to be low.

• If the problem is ambiguous or complex, Prioritise UCD. Invest in research and validation upfront, because the cost of getting it wrong and fixing it later will be much higher. In some cases, it may not be fixable at all.

Collaboration Is Key

What’s often missed in this debate is that it shouldn’t be a handoff between UCD and engineering—it should be a partnership.

The strongest teams don’t wait for “perfect” designs or “complete” requirements. Instead, they work together continuously:

• Designers involve engineers early to sense-check feasibility

• Engineers engage with research to understand user needs firsthand

• Both disciplines align on what level of confidence is “enough” to move forward

This kind of collaboration reduces risk far more effectively than either approach in isolation.

It also prevents the dilemma of “design first” vs “build first”—because in reality, the best teams are doing both, just at different levels.

So, Is There a Right Answer?

Not really.

There’s no universal “right” or “wrong” approach here. What matters is that teams are collaborating, not competing.

The best outcomes happen when engineering and UCD work together to answer the same question:

How confident are we in what we’re building—and what’s the smartest way to reduce risk?

Ultimately, the path you take should be shaped by how well you understand the end goal.

Delivery is not about choosing sides—it’s about choosing the right approach for the context.