The organisations I've worked with across banking, energy infrastructure, telecom, and government programmes all eventually produce the same story. A developer capable, well-intentioned, technically sharp starts filling a gap. There is no UX resource on the team, or the one that exists is too thin to cover the delivery pace. So the developer steps in. Makes the call. Picks the pattern. Decides the flow.

Nobody stops them. The project manager is focused on velocity. The product owner is focused on scope. The business stakeholder sees something on a screen that looks like a decision has been made and moves on.

Six months later, the support desk is fielding tickets about tasks users cannot complete. The adoption curve is flat. A regulator flags the interface for accessibility failures. And everyone is confused the design system was followed, the component library was used, the UI is technically consistent.

The design system is fine. The UX was never done.

CORE ARGUMENT

Familiarity with design tools is not UX expertise. When organisations allow role drift to substitute for research-grounded design particularly in regulated environments where user error carries operational and compliance consequences they are not saving money on UX. They are deferring an expensive failure. 

1. How Role Drift Actually Happens

In regulated industries, the drift rarely starts with ambition. It starts with a vacancy. A UX researcher goes on leave. The design resource is shared across three programmes. The sprint cannot wait. And a developer who has worked with design systems, attended design reviews, and built enough interfaces to have strong opinions fills the gap.

That is not a character flaw. It is a governance failure. The organisation has created conditions where role drift is the path of least resistance and then acts surprised when the outputs carry the fingerprints of engineering logic rather than user research.

The progression is consistent enough across organisations that it follows a recognisable pattern.

The critical juncture is Step 4. Once a developer's UX judgement has been accepted by the business without challenge, it becomes institutionalised. The next sprint, the same logic applies. The sprint after that, nobody questions it because they never questioned it before. By the time a UX professional enters the room, they are not being asked to do design they are being asked to justify why the design already built is wrong.

That is not a conversation most organisations are structurally equipped to have honestly.

2. The Design System Trap

The most common justification I encounter in enterprise environments is the design system defence.

"We followed the component library. The UI is consistent. What else is there?"

There is everything else. A design system provides consistency. It does not provide relevance. It ensures that buttons look the same across the product. It has no mechanism for determining whether the button is in the right place, labelled with the right language, or visible to a field operative working on a 5-inch screen in low-light conditions.

In banking and energy sector programmes, I have reviewed interfaces built entirely within a well-maintained design system that were functionally unusable for their intended audience. The components were correct. The user journey was not. Because the user journey was never actually designed it was assembled by engineers following the path of least implementation resistance.

The design system is a tool. Like any tool, its quality of output depends entirely on the quality of the thinking that directs its use. A hammer does not know whether you are building a bridge or breaking a window. A component library does not know whether the flow it is expressing matches how users understand their own tasks.

THE SYSTEM DEFENCE

"We used the design system" is not a UX methodology. It is a production shortcut. It answers the question 'Is this visually consistent?' It does not touch the questions that determine whether users can actually complete what they came to do. 

3. What UX Actually Asks and Why Developers Cannot Answer It Alone

This is the technical argument, not the territorial one. UX research is a discipline with its own methods, its own epistemology, and its own standards of evidence. It is not opinion. It is not aesthetics. It is not intuition about what users 'probably want.'

The questions that determine whether a product works for its users are specific and they require specific methods to answer.

In financial services and government platforms, the stakes attached to these questions is not abstract. An error message that confuses a banking operations user does not just create friction it can trigger a misprocessed transaction. An onboarding flow that does not match the mental model of a first-time pension claimant does not just reduce conversion it creates a support burden that costs money and erodes institutional trust.

The developer who built that flow may have tested it on themselves, on their team, or on a colleague who already understood the system. That is not user research. That is confirmation bias dressed up as due diligence.

4. UX Debt in Enterprise Programmes: How It Compounds

 Organisations that operate without enforced UX governance do not experience a single large failure. They experience a slow accumulation of small ones each individually dismissible, collectively catastrophic.

I call this UX debt. It behaves exactly like technical debt, with one significant difference: it is invisible on any dashboard that most programme boards look at. Technical debt shows up in build times, system performance, and engineer velocity. UX debt shows up in support ticket volumes, NPS scores, and adoption curves metrics that are routinely attributed to other causes.

The crisis point in Fig. 3 is particularly relevant in regulated environments. In banking, a usability audit failure can trigger a regulatory review. In government digital services, an accessibility failure can trigger legal exposure. In energy sector operations, a poorly designed field technician interface can contribute to safety incidents.

None of these outcomes appear in the sprint retrospective where the original design decisions was made. By the time they surface, the programme board is asking why UX was not involved earlier when the answer is that governance structures actively prevented earlier involvement.

5. The Ethical Dimension

There is an organisational argument here rework costs, adoption rates, regulatory exposure. But there is also an ethical argument that rarely gets named directly in enterprise programme conversations.

Users of complex financial systems, energy management platforms, and government services are not selecting these products from a competitive marketplace. A benefits claimant navigating a government portal does not have an alternative. A bank operations staff member processing a customer transaction is working within a system defined by their employer. They do not get to walk away.

When developers make UX decisions without research grounding, the harm does not fall on the organisation immediately it falls on those users first. It falls on the operations staff who spend an extra forty minutes per day navigating a workflow that was never actually designed for their task. It falls on the customer who abandons a transaction they needed to complete. It falls on the field technician who misreads an ambiguous status indicator.

UX practitioners exist, in part, as advocates for people who have no other representation in the room where product decisions are made. When that role is substituted by engineering convenience, those people lose their only voice in the process.

THE ETHICAL REALITY

In markets where users cannot opt out regulated financial services, public sector portals, utility platforms poor UX is not a competitive disadvantage. It is a harm. Governance structures that allow assumption-driven design to ship into these environments are not just making a business mistake. They are making an ethical one. 

6. What the Right Model Actually Looks Like

The solution is not separation UX teams locked in a room producing artefacts that developers then implement without dialogue. That model produces its own failures. The solution is structured collaboration with clear role boundaries and defined handoff points.

A developer who understands why a flow was designed the way it was because they attended the research readout, because the UX acceptance criteria were written into the story is a better implementer. Not because they are told what to do, but because they understand the intent well enough to raise a flag when the build diverges from it.

That is the model. Not developer-as-UX-proxy. Developer as informed implementer and active collaborator.

The column labelled 'Developer Role' in Fig. 4 is not passive. Developers in this model are active collaborators they surface technical constraints early, they participate in design reviews, they flag implementation deviations before they ship. What they do not do is unilaterally substitute their judgement for a user research finding because the finding is inconvenient for the build timeline.

That distinction active collaboration versus substitution is the line that most organisations fail to enforce.

7. Recovering from Role Drift: A Governance Response

If your programme is already exhibiting the symptoms rising support burden, stalled adoption, rework cycles that keep touching the same flows the response is not to commission more design work. It is to fix the governance conditions that produced the problem.

Design work commissioned on top of a broken governance model produces more artefacts. It does not produce better outcomes. You need both: the structural fix and the design investment.

Action 4- introducing UX acceptance criteria into the definition of done is the single highest-leverage intervention for teams that are already past the crisis point. It does not require a governance restructure or executive mandate. It requires a product owner willing to gate stories on user experience evidence, not just technical completion.

Most teams resist this initially because it slows velocity in the short term. Every team that has implemented it seriously has reported that it reduces rework cycles significantly enough to recover that time within two to three sprints.

8. Wearing the Right Hat and Knowing Why It Matters

The headline of this article has a point, but it is not about blame. Developers who drift into UX territory in the absence of governance structures are not the problem they are a symptom of the problem. The organisations that allow delivery pressure to override role integrity are the ones generating these outcomes.

The honest question for any programme director in a regulated industry is not "do we have a UX team?" It is "does our delivery model give that team the authority, access, and governance support to do the work that determines whether users can actually use what we build?"

If the answer to that second question is no, then the first question is irrelevant. You have UX practitioners producing research that will not influence decisions. You have a design system being applied by people who do not understand the research that should be directing it. And you have users paying the cost of that gap every time they interact with your product.

UX is not the team that makes things look good. It is the team that determines whether things work for the people who have to use them. When that team cannot do its job because governance has defaulted to the path of least engineering resistance, the product fails quietly, expensively, and sometimes in ways that carry consequences beyond the organisation itself.

Build the governance structure that gives UX its proper position in the delivery chain. Not above development. Not below it. Alongside it with clear boundaries, defined handoffs, and the authority to hold the line when delivery pressure pushes for shortcuts.

That is not a design argument. That is a programme management imperative.

CLOSING STATEMENT

The organisations that ship products users can actually use are not the ones with the most talented developers. They are the ones where UX research has a defined seat at the decision table before scope is locked, before architecture is committed, and before a single component is placed on a screen. 

About the Author

Chemsseddine SALEM is a Lead UX Designer and Researcher specialising in Enterprise SaaS, UX Governance, Finance, and Energy sectors. He is the founder of Chemss Labs and works with organisations navigating large-scale digital transformation in regulated environments.